LL3DLGLD – 8 – Become a real engine

OK, I am done playing around! I think I have gathered enough knowledge and working snippets of code to put them all together. Here is what we get:

Time to take these random pieces of code that I have been tinkering on for a week and that can be considered a solid starting of point and create a real engine.

The first step is to optimize the creation of vertices based on the logical strips. The new system is less flexible, but faster and a lot easier to use.

The second step is to greatly optimize the actual strip creation. The new method is roughly as fast as the previous one, but a lot shorter. How short is it? Well, it is SHOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOORT! Combining these two methods the engine has lost 300 lines of code and now the terrain supports elevation. Elevation still uses a random and quite poor terrain generator, but next time I’ll plug in the real terrain generator from the 2D engine to get some better results.

I also added the ability to switch on and off the use of low LOD grass and trees. Needless to say, each time you turn off one of these optimizations framerate drops. Grass with or without LOD looks almost the same and I’ll leave it off for strategic and first person camera because you will barely be able to tell the difference, especially with elevation. Trees on the other hand have a larger visual impact. For trees the lowest LOD is just to skip them and here it becomes very clear that not having billboards yet greatly reduces visual quality. I also restructured the engine, using good class structure and design.

Here is video with the engine in its current state (while tomorrow I’ll add the smart terrain generator from classical DwarvesH to see how it works):

Let’s talk a little about this engine. The first thing to notice is that it is ugly. And I am not talking about the placeholder cube trees. Generally speaking. And I also have a contrast problem like I did in the 2D one. Even after I add lighting and shadows, I’m afraid I’ll need the help of a professional artist to make it less ugly.

The current level of optimizations is not enough. It works fine right now, but I expect it to work less good when the real terrain is introduced. The general strip conversion is not perfect yet. Top surface conversion is good enough but sides are horribly unoptimized. And since normally you’ll have a floor on top of a wall in natural environments at every elevation change, I am actually using double the needed polygons in these cases. I removed bottoms for now.

And I couldn’t care less! Normally, I would take a couple of weeks and optimize the hell out of it. But it runs just fine for now. I spent a lot of time creating the perfect 2D engine only to discard it once I reached the limits of 2D. Instead of actively optimizing stuff until it is near perfect, I’ll do it passively. Whenever I have nothing else to do and am in a mood to optimize stuff, I’ll do a short optimization session. Over the time, the gains will add up. So performance is not going to be great in two weeks, but it will be in four months (random example periods). If I maintain the old workflow, I’ll finish the game in 10 years. I would like to get something out a little bit sooner.

Bug fixing I’ll still do in the old rhythm. And there is no use to optimize stuff right now since I have a huge glaring flaw in my LOD algorithms: I am using a distance based approach, not a frustum based approach. You are in the middle of multiple spheres and LOD is computed based on the radius of the spheres and object intersecting them. So that’s right: unless you are high up and looking straight down, you are rendering roughly twice as much as you should: the sections in front of you and the sections behind you. Once I figure out a frustum based optimization that can hide sections that are not on screen, I expect my framerate to almost double.