Crowbar - an open-source editor

[NoodleCollie]

The problem with octrees is that they don't do occlusion filtering. And given how much level geometry can be inside the viewing frustum but occluded by closer geometry...

Also, there is no rule saying that the size of each octree level has to be fixed. You can dynamically divide as desired. This allows you to merge leaf nodes when only one of them has something in it.

Fair enough. I don't think Hammer bothers with occlusion filtering, though (a guess, simply because the rendering system is so simple), as the far clip plane/model render distance seem to do most of the optimisation. There's also the consideration that you can place your camera inside the 3D objects, so it's unclear whether occlusion filtering would be useful in that case - if you wanted to texture faces that were flush with neighbouring faces (for example, triggers/nodraw/etc.), occluding the faces might be more of a hindrance than a help. Since the scene is inherently dynamic, trying for more aggressive occlusion might end up being more of a performance drain than otherwise; the advantage of BSP is that a whole load of the processing is done before the map reaches the game, so the engine has direct access to information on what's visible and what's not, whereas in a world where a wall can be present one minute and deleted the next there'd be a lot of re-calculations to do.

 

[henke37]

Indeed, hammer doesn't do occlusion culling. No wonder why the framerate is so bad.

 

[NoodleCollie]

A small update.

I've been working on implementing an octree that doesn't end up grinding my computer to a halt - the previous implementation I had ended up creating 17 million hash tables at once in the worst case, which essentially reduced my computer to page swapping and needless to say fell far below the acceptable performance levels.

 

[NoodleCollie]

Something a little more interesting:

After a fair amount of grief, thanks to an odd coding anomaly in the Qt3D library, I managed to get a render test going for the octree. The objects (blue-green boxes) are added at the beginning and the octree then recursively divides itself into node volumes, depending on whether enough objects are present within and whether the node volume is large enough to subdivide.

 

[diddutz]

I do have a question about rendering with the octree implementation you suggested. If Objects can be stored in multiple nodes of the octree, how do you plan on rendering all objects in a given node? If you just render every object in the given node and it's children recursively you would render objects that are referenced in multiple octree nodes multiple times, which is unwanted.

 

[NoodleCollie]

The way I had thought about doing it was using an extra hash table when rendering - if an object is in the hash table (which allows you to check for existence of elements in constant time) then it is not rendered, and if it's not then it is rendered and then put into the hash table afterwards. The multiple render checks are a common problem with octrees, but some get around it by tweaking the size of the nodes so that they fully enclose a given object. That wasn't really an option in this case simply because of the dynamic nature of what a level editor does (you'll be changing geometry all the time, which would mean the octree structure would also be changing all the time too).

In other news, this project will probably end up being my university project next year, which will mean that it gets much more attention that it's currently getting. It also means I'll have experts to call on to help me with the bits I'm not so sure about.

 

[diddutz]

Ok, that makes sense.
When I was was thinking about the render problem i was just thinking about using a list to store the rendered objects, which could've been a performance problem. Don't know why i didn't realized that you could also use a hash table there.

 

[NoodleCollie]

Update: I got mouse-look working. It's smooooooth.

 

[Gnurfos]

Hi, I'm very intersted in this. What's the project status ? There's not much activity on github, but lots of messages here. Is the project going on somewhat privately ?
Cheers.

 

[NoodleCollie]

Most of the stuff I've been messing about with lately has been going here: https://github.com/x6herbius/opengl-experiments

 

[Gnurfos]

Does this mean the project is still active, but we can't use it yet, nor contribute ?

 

[NoodleCollie]

Well I'm going to be doing the project as my final year project at university, so it will get worked on. Right now I've just been experimenting with rendering things, but by all means jump in if you want to.

 

[Gnurfos]

I don't know yet if I want to dedicate time to making maps, or contributing to the editor, but I love the idea.
In case you need help on some particular aspects, don't hesitate to ask for it, and maybe it will match my (or someone else's) skills and motivation.
Good luck for your project, this sounds ambitious.

 

[NoodleCollie]

Well the one thing that's doing my head in right now is the following: if you compile and run the opengl-experiments code, press P to enter mouse look mode and look down on the cube, sometimes the camera flicks the yaw 180 degrees and I can't seem to find much rhyme or reason to it, so if anyone can spot why it might be happening let me know. I'm a bit fatigued with coding right now, having been doing other bits and pieces all week at work, so I think I'm gonna take a break for a few days myself.

The method I'm using for the camera right now is that setting the view angles in the same way as you would Hammer (ie. pitch/yaw/roll) decomposes into setting the camera centre (the point the camera orbits around, like the "view target" in SFM) to lie in the direction of the angles from the camera. The angles are converted to a unit vector, the current distance between the camera eye and its centre is calculated and the centre is set to (angleVector) * (currentDistance) to point the camera view in the correct direction while attempting to keep the distance between the eye and the centre as close as possible to how it was before (floating point imprecision notwithstanding). When you get the camera view angles, they're just calculated by taking the directional vector of the centre from the eye and converting this to a p/y/r angle, because this way the "view angle" and the "view vector" will always remain synchronised, as opposed to keeping a local copy of the angles which might not get updated if the vector-based QGLCamera functions are used.

 

[NoodleCollie]

Update - looks like the editor's been accepted as my final year project at university, so there should be a basic, functional implementation by February when I'm required to submit my progress report.

My current thinking (which will go down in my specification document that I have to submit in three weeks) is that the design philosophy of the editor should be to help facilitate iterative map development. This basically means that in the build-test-revise-test-revise-... cycle that we all go through, the editor should allow the user to spend less time developing each revision of the map (or spend an equivalent amount of time making larger, more complicated changes) so that tests can happen more frequently and feedback be more easily incorporated, bringing the overall development time of the map down and allowing more content to be released more frequently. The problem I've found with Hammer is that it's very manual, especially within the TF2 map-making environment - if you want to change the position of a doorway, or change the shape of an arena, or add/delete a route, you have to faff about with changing the dimensions on a lot of brushes and props and this can take a long time, taking the focus away from the high-level overview of routes, arena sizes, distances, spawn times, cover and so on. If the editor were to automate these low-level changes, this would allow users to remain focused on the important aspects of a map and would also allow changes to be made in response to feedback much more quickly. Imagine, instead of having to shift all your brushes and props sideways to change the flow of a route, you just had to move a node on a graph; or if you could have a map tested, load up the annotations file as physical pop-ups within the 3D view of the editor, deal with all the feedback points and then have your map ready to re-test, custom content included, later that same day.

The other important thing I think needs to be included is the ability to take care of the general admin that's required when you develop a map. I'd like to be able to load up a standard PNG/TGA/whatever from within the editor to use as a texture and have the editor write an appropriate VMT/VTF, make it available immediately, file/tag it as custom content being used with this specific map file and have it automatically package the texture in the BSP when the map is compiled. This would take manual VTFEdit/BSPZip editing out of the equation completely, as well as helping to ensure that I don't accidentally use the texture in other maps while thinking it's a standard TF2 texture.

Of course, along with all this there are the benefits of open source (we don't have to wait on Valve for a fix if something goes wrong, provided we have people who are able to investigate and fix independently as updates come out) and, potentially, custom plugins for extra bits and pieces.

If anyone has other helpful features in the same vein that they think would make mapping life easier, I'd be very interested to hear them at this early stage.

 

[NoodleCollie]

Not sure how much I'm able to reveal considering the FYP is supposed to be all my own work (I'll have to ask my supervisor), but I'll paraphrase the objectives I've come up with for the proposal:

• Free and open source - Makes the editor as accessible as possible, and gives the community complete control over it.
• Cross-platform - Run wherever the game runs.
• Multi-game - It'd be nice if the editor were flexible enough to be used for not just Source games but pretty much anything that runs 3D levels.
• Accelerate development speeds - Quicker development speeds = quicker revisions = more testing = more bugs identified = quicker to fix bugs = quicker release = more playtime = more fun. Do this by abstracting and automating (you deal with the conceptual view, the editor generates the geometry for you) and also by making intelligent tools, eg. adding a spectator camera by using the co-ordinates and orientation of the camera in the 3D view.
• Flexible editing tools - As well as abstract operations, let me change details with absolute precision if I need to. Everything in the map needs to have some way to let me manually do this.
• Cater to entire mapping process - For example: import new texture as a PNG, have editor generate VMT and VTF and log the texture as custom. After compile, have editor run bspzip and embed the custom texture into the BSP. No work required from me.

 

[NoodleCollie]

This, ladies and gentlemen, is a brush. It's not a very exciting brush but it's my brush.

The short GIF demonstrates switching between OpenGL and Hammer co-ordinate systems without modifying the camera orientation (awkwardly, the Y and Z axes are different when rendering with OpenGL than when creating geometry in Hammer), rendering with points only, rendering in wireframe and rendering solid colours. Given the amount of other coursework I've been continually drowning in (seriously, studying in Hong Kong for a year is hardcore academia), I'm proud of having got this working so nicely.

 

[NoodleCollie]

Small update - not much to show right now, mainly because going to university in Hong Kong is really bloody hard work and I've had no free time for the past few weeks. However, I did hear today in our computer graphics lecture that architects usually draw a floor plan in 3D software and then extrude the walls up from the 2D plane, which I thought could be a pretty quick and intuitive way to make basic structures in a map. I'll keep it in mind for later bits and pieces.

 

[henke37]

Of course, that assumes sane, simple, designs with floors that stick to one level and such. Boring designs that are less likely to be found in video game maps.

 

[wareya]

Walling a floorplan and extruding it is already excruciatingly easy in hammer. If you're at least going to have the previous selected brush size and multi-selection resize stuff, I don't see how you would need a special system.