Thursday, November 10, 2011

67 – Frosting Culling

If you don't want to read this post but are interested in Tech Demo 1 then check out the end of the post. Or just read though it!

Check out this screenshot:

We only get 37 FPS. But it is a full map view, with 5,507,481 vertices and 10,040,364 triangles (assuming I did not make a mistake in the code that computes these values). That is 371,493,468 triangles a second. My GPU is working really hard trying to pump out this volume of triangles and it is understandable that performance is low. Now let's get a little bit closer:

What! We now have 46 FPS! A little bit closer:

What? 64! What is happening? What!! Even closer:

Uuuuuu! What? 159? Ooooo! What? What is happening? Must get closer:

Ooooo! Uuuuuu! What is happening? What? What is happening? Uuuuuuuuu! 318? Ooooo! What? What is happening? What is happening? Uuuuuu!

I wish you were here besides me because I am making the most obnoxious and annoying "u" and "o" sounds humanly possible. And a Stifler face.

You may have guessed what is happening: then engine now supports frustum culling. When all the scene components are in view you have no choice but to render them. But as they get out of view they are eliminated and rendering performance increases. Actually, they are only hidden. The buffers still take up resources. Frustum culling is dependent only on camera position and direction and camera movement can be very twitchy. Imagine a first person shooter when you can swipe your mouse around very fast. Doing a few axis aligned bounding box frustum collisions is doable. Building and destroying buffers on the other hand is not because it would make your mouse less responsive. So the bottom line is better performance, same resource use.

Normally I would do a LL3DLGLD on frustum culling, but most of the job I did with the capabilities provided by Irrlicht. Irrlicht automatically culls, but it uses a computationally very fast but not very effective in getting nodes out of the rending pipeline approach by default. I suspected for long that culling was on by default because every time I messed up bounding box creation some nodes started disappearing randomly. Changing the culling criteria to box vs. frustum insides generated the above results. I only wish that Irrlicht would remember the results of its previous frustum check so I can use it latter, but I can repeat the check manually if I need it at another time for some other things, like not switching LOD for nodes that are out of view.

Frustum culling scales well with almost all camera modes and should give you and extra substantial boost in performance. It even makes the game run on poor Intel integrated chips that would have no busyness rendering millions of polygons. As long as you keep the camera very close to the action.

Only a first person view is not ideally served by frustum culling. I will need to add an additional camera distance check.

I can't wait to see the performance data after LOD switching is working as intended. As explained last time, LOD switching is fully implemented, but I do not have low poly models yet for most objects, so the low LOD mesh points to the high LOD mesh, making LOD switching generate a constant level of detail.

But still, I just can help it and feel that the view in the screenshot bellow is just epic with the sheer amount of objects visible:

Frustum culling was a worthy addition to the engine and to the feature set of Tech Demo 1. Useful LOD switching and some better camera movement will also make it into the first version.

And here is my question to you, my loyal readers: what else would you like to see in Tech Demo 1/the engine as a whole. Keep in mind that Tech Demo is designed to test if the engine runs on the targeted spec and provide information on how to make it run better. It is all about the engine. So Tech Demo 1 will not have any of the following (and more): GUI, dwarves, actions, property inspectors, time compression, path finding, etc. It is going to be a pure engine test, so it will have rendering of one or more random levels, different densities of objects, level switching, camera modes, camera movement, etc. And of course all the technology behind it, like buffer lifetime management, frustum culling, lighting, LOD switching, etc.

So keeping the above constrains in mind, what else would you like to see in TD1?

PS: This is not for TD1, but I have an idea that would assure that a future TD would be tried by a lot of people: making the tech demo able to load DF and/or Minecraft maps. It won't be the primary or secondary function of it, but it would work at a satisfactory level. This is a task I think I will need help on :).


  1. I'd like to see underground areas and/or overhangs, along with the lighting for those areas. That's really the last big step that I can see for the engine.

  2. This isn't what you want to hear, but honestly, I'm not excited about the tech demo. I don't care about 3d. I don't care about camera angles. I don't care about zooming. I don't care about rotation.

    I want to see the dwarves. I want to see them do stuff. I want to see towns or monsters or crafting or livestock or whatever you dream up. I want to see gameplay. A top-down tileset would be fine with me. :)

    I know, you'll get there eventually. I just keep hoping it's sooner rather than later :)

  3. To Sgaterboy:

    That would be interesting. I think it would make more sense when I have a less cubic world, but even with cubes it could be done. But lighting is going to be quite difficult to pull off.

    To Amit:

    Fair enough. And I doubt anybody would get excited over a tech demo. But a tech demo would have come even for the 2D isometric engine. There needs to be s step where I expose the engine to thousands of people and hope that I get a few dozen of results back, either positive or negative. I need to know if the engine will run before I can put out the game.

    Having gameplay would be just too distracting. Instead of people telling me how well it runs (if it does), we could get discussions about balance, how DF is better, how this is clone, how this is not a clone, how it can improved, how I am going to get sued by Toady :), etc.

    I plan to have 4-6 tech demos actually. But this can be done in parallel with the next big step after 3D: fully implemented workshops. And the next step after that: combat.