Crowbar - an open-source editor

[Forty-Two]

Will this project be taking advantage of qt's crossplatform capabilities? Atm, there are no source editors for linux or osx that I know of (yes, QuARK in wine, but that's not native). I'd love to help get those implemented if you want. Also: the repo has no commits. Is that because you're waiting to finish designing before you finish or because the source has moved elsewhere?

 

[NoodleCollie]

Yes, the editor will be cross-platform (hence the choice of Qt). Everything in the repo is on the "workbench" branch, you're probably looking at the master.

I've been thinking around the VBO problem a little bit and I've had some ideas. The recommended size per VBO is 1-4MB which means, storing position, colour and normals for each vertex, we could store roughly 100,000 vertices in a VBO (or ~35,000 polygons). I'm thinking of having separate VBOs for geometry (brushes), prop meshes, etc., and for the brushes specifically I was thinking of having a maximum number of vertices, and for the entire map a maximum number of brushes. This way I could allocate enough space in the VBO for (max vertices * max brushes) and give each brush an ID which corresponds to its offset from the beginning of the VBO, easily allowing for partial updates of the buffer. If a vertex is 40 bytes (double precision position vector, float precision normal, 4 byte colour/alpha) then the address in the VBO of an object with ID 5 would be 5 * (40 * max_vertex_limit).

 

[SpAM_CAN]

Hows it coming along? I've got some rough icons done.

 

[NoodleCollie]

The latest I've done is implement vertices/edges/faces/solids. They don't render yet (I haven't built the rendering system yet) but I'm working on implementing a debug console system first.

 

[yoghurt]

wauw i really like where this is going
Btw i don't really like how the compiler works in hammer so i usually compile with the valve batch compiler tool
Maybe you could include it in crowbar or code something similar?

 

[diddutz]

@x6herbius
About your concerns, it seems like you already found out that you can easily modify Buffer-Objects with the glBufferSubData and *glMapBuffer functions.
Also in your calculation of how many Bytes you need per Vertex, i am missing texture coordinates. Is there a specific reason for that, that i am missing?

 

[stegarootbeer]

If I may request a feature, make it check if an solid is valid when you edit it instead of the next time the map is loaded. I hate it when I load a map and it tells me solids were deleted and then I have to go find where solids used to be and now aren't.

 

[Fruity Snacks]

If I may request a feature, make it check if an solid is valid when you edit it instead of the next time the map is loaded. I hate it when I load a map and it tells me solids were deleted and then I have to go find where solids used to be and now aren't.

You can check that at any time using alt+p, but having a pop up warning would be ideal.

 

[SpAM_CAN]

Highlight invalid solids in red or something.

 

[NoodleCollie]

@didd: Yeah, that list I specified was incomplete. I've implemented texcoords but am thinking of dropping the normal - we'll rendering by face which will eliminate the need for vertex duplication, and while doing so will ensure that each vertex's normal is the same as the normal for the face, eliminating the need to store the normal in the VBO. I was also thinking of implementing the "shaded textured" mode by shading each face in the fragment shader according to the dot product of the face's normal with the direction of the global light (which could even be changed by the user from within the application).

 

[Pocket]

Highlight invalid solids in red or something.

Speaking of red, I'd like to see it be able to detect the type of invalid texture data that in-game shows up as bright red faces for whatever reason. You know, how sometimes too much noodling around with Alt+mouse2 will create a face or two where the textures are registered as aligned perpendicularly to the face somehow, and the compiler goes "The heck? ... Screw it, you're bright red and glowing."

 

[NoodleCollie]

To be honest I'd quite like to try and avoid that kind of texture data altogether by implementing the vertex edit a bit better.

 

[henke37]

@didd: Yeah, that list I specified was incomplete. I've implemented texcoords but am thinking of dropping the normal - we'll rendering by face which will eliminate the need for vertex duplication, and while doing so will ensure that each vertex's normal is the same as the normal for the face, eliminating the need to store the normal in the VBO. I was also thinking of implementing the "shaded textured" mode by shading each face in the fragment shader according to the dot product of the face's normal with the direction of the global light (which could even be changed by the user from within the application).

Did anyone else hear the woosh sound as that flew over their heads?

 

[NoodleCollie]

Haha, I can explain again:

I don't think we need to store each vertex's normal in the graphics memory (which will save us some space). Vertex normals are used when the polygons are lit to make the lighting seem smooth (eg. on a sphere) or faceted (on things with sharper edges). When rendering smooth surfaces each vertex's normal is an average of all the faces surrounding it, which means that it's a good idea to store the normal along with the vertex data and update (average) it whenever you add a new face that the vertex is part of. When rendering faceted surfaces, however, you "duplicate" the vertex for each different face, giving it different normals for different faces so that the lighting is not smoothed out over the geometry's edges. Because the lighting in Hammer is always faceted (in fact, it's not really lighting at all, just the darkening of faces in relation to which way they're pointing), we can do away with storing a normal value per vertex - when we render a brush, we can take the normal value that is stored with each face and pass that in along with each vertex we render. We can compare this (using a vector dot product) with the direction of the global "lighting" - if the face normal is in the opposite direction to the lighting (ie. pointing towards the light) then no shadowing occurrs; if the face normal is in the same direction as the lighting then it should be fully shadowed, and anything in-between is interpolated appropriately.

 

[nightwatch]

Who needs school when you've got xherbius to teach you 3d graphics?

 

[NoodleCollie]

Haha, I'd thank the internet rather than me.

 

[LeChris]

source 2 is in the works. we will sure get new tools and they might (should) have source 1 support.

 

[NoodleCollie]

source 2 is in the works. we will sure get new tools and they might (should) have source 1 support.

True, but we won't have access to the source code when Valve decides to do an update and it breaks the SDK for a couple of weeks.

 

[Pocket]

I'm all but certain they won't bother backporting their tools to their older games. Consider that they couldn't even be bothered to make a unified launcher for post-2007 games, nor make the newer engine branches available to modders. If the new engine is anywhere near as big of a leap forward as people hope it is, the creation tools will be completely incompatible.

 

[NoodleCollie]

Update: I've been trying to continue on the console system on the trains to/from work but because it's been so fragmented it's taken a while. I also realised lately that I'd been sticking references to abstract classes everywhere (the programmers amongst you will know why that's never a good idea, mainly because you'll have a difficult time getting that to compile), so I'm having to go over some stuff again.

Apart from that, a little messing around with the Far Cry 3 editor this weekend has helped me hone my vision a bit more on what I want to work towards with the Crowbar editor. My intuition right now is that the more immersive the editor is, the easier it's going to be to craft higher-quality worlds as the leap of imagination from pre- to post-compile is less drastic. I've thought of a couple more additions I'd like to implement when the time comes:

- WYSIWYG skyboxes - the editor draws the skybox you choose for the map in the background in the same way that the game does. When the times comes to seal the map with physical skybox brushes, you can turn the skybox display off so that you can see where to put them. If an env_sun is present, this is drawn too.

- Directional shading depending on the lighting angles from your light_environment. Like Hammer's shaded textured mode, brush faces can be shaded depending on what direction they're pointing in, but you can change the fake lighting direction and tint to match that of your light_environment, as a cheap, semi-preview of global lighting.

- The option to render displacement faces double-sided so that you can manipulate them from behind when you need to, as well as the option to only allow the editing of displacement vertices that you can see part of the face for (for when you're doing bulk editing and don't want to catch the faces that are facing away from you).

- Some sort of "map sketch" mode. The details on this are still hazy as it's part pipe dream, but I've always found mocking up TF2 maps, where the layout, arena width, etc. is important, to be tiresome because of having to create and manage all the surrounding brushes. What I had in mind was some kind of lines-and-points implementation, where points could be positioned and connecting lines drawn between them. The lines would be quickly and dirtily made into routes (with things like width and height specifiable) and the points into arenas which you can set the size of. Don't like the position of some route, or need more height difference? Just move the points around and the geometry (generated fully on compile but with a translucent block-preview while editing) will change.

- Novint Falcon support for things like displacement sculpting (the pipiest of pipe dreams).