Crowbar - an open-source editor

I understand your point, but I think I'll be sticking with Qt widgets for a few reasons:

A. The code's already there, complete with signals/slots/events that I'd probably have to re-code if I did everything in OpenGL. It seems stupid not to use it just to save a few megabytes on executable size, plus re-coding would be a very large task.

B. I'm not sure it would fit with the tabbed UI people have been wanting. With the Qt controls, I can stick an OpenGL window into a tabbed window and let Qt deal with the docking, whereas otherwise I'd have to write up a whole tabbing mechanism to work within OpenGL as well.

C. I'm intending to make it easy to extend the editor with plugins, and Qt already has its own plugin system and extensive documentation.

Note: Apologies for taking fucking ages on the pull requests on GitHub, I've been on holiday and our internet went out for 3 days because of a storm...

A small update:

OpenGL is rendering.


In other news, I've managed to hash something together out of Qt's dock widgets - they're pretty much perfect for the dockable window kind of thing but are usually only allowed to go around the outside of a window and not in the centre. If you set the central widget of a window to null then they can fill it all but the interface is still a bit clunky. I've uploaded a compile here for people to test out if they want to and tell me what they think.

EDIT: Another thing I've been wondering (since we're about at the right stage for me to be thinking about the architecture for it) is what the best way programatically would be for allowing a plugin interface. Ideally I'd like every tool to be a plugin, starting from the very basic things like select, create brush, etc., but I'm unsure about the best way to go about structuring this. From what I've done with SourceMod everything there is very event-driven: something is fired from TF2 like a round start notification, and the plugins hook into this signal and run their custom code when it happens. This seems like a good direction to go in but again, I'm not sure of the nature in which it would relate to an editing program rather than a game which already has all these situations in place to hook into.

I'm probably not explaining myself very well, but if anyone has any input I'd gladly hear it.

Should I be packaging the VCR DLLs or expecting people to download them? I guess if I left it to a download that would ensure they were up-to-date instead of relying on whichever one came with the editor.

So far with regards to plugins I'd thought of something where a plugin can expose its unique identifier string, name/description/version and such to be registered into the editor when it starts. Then maybe have different callbacks for object selected, mouse clicked in viewport, etc?

The compile kit I used was a VS one (because I already has VS2012 installed). I think you can use MinGW so I might start doing so.

An update on where I'm at right now - as always, to anyone with 3D rendering experience I'd love to have your input.

I've been looking into the way Hammer renders objects and it looks like every frame the vertex info is passed over to a mesh builder class in the material render system, which builds the mesh for a given brush and renders it. This seems to be a similar way to the way OpenGL used to render objects prior to the newest versions - every frame, you would provide both a list of vertices and a list of indices to the GPU (the indices specifying the elements of the vertex array to render in order) and the GPU would render them. In newer OpenGL versions (3.3 and upwards IIRC) you can specify a vertex buffer object (VBO) which basically means the vertex info is stored physically on the GPU in the high-performance video memory. The good news is that it looks as though with the new OpenGL version we'll be able to get a performance increase by storing the vertex data in VBOs instead of passing it every frame, so hopefully we'll be able to render more and render it faster than in Hammer. The problem is that out of all the material I've been reading on VBOs the vertex data being drawn is unchanging (ie. they've hard-coded a triangle or a cube for demonstration purposes) and so I'm not sure how one might go about creating and managing the VBOs when we're going to have brushes being created and modified left, right and centre. The Qt example creates a VBO when the viewport class is initialised so that may be one way to go about it, but I need to find out more information about how I should be doing it - I can see creating one VBO for the scene might be an option but I don't know how I'd deal with when that memory overflows.