Screens of the day 37 – G(h)e(tt)o-mipmapping

Now, after adequate testing, I can tell that Snapshot 10 is quite buggy. Mostly the grass. Let me explain why.

This is all due to my pseudo geo-mipmapping. While it is not active in the code-base by default, I am doing a dual mode implementation so you can switch between normal inefficient rendering and the LOD solution on the fly. This means that some changes from the LOD solution will affect the normal one. Like the chunk size. I mentioned before that my chunk size of 127 units was inappropriate for LOD because of its odd size. Meanwhile I have added a third LOD level, and the new size of 126 was no longer good, because it is not divisible by 4. So now my chunk size is 124 units. In Snapshot 10 in beyond. But I forgot to adjust the grass, so grass chunks no longer align with terrain chunks, causing visual bugs.

I won't show the results of the 3 LOD level based terrain yet, because we  must talk about seams. For seam testing I'll use a very tight LOD margin so that seams are very apparent and not hidden by distance. Here is a problematic area:

To fix this, first I write code to determine LOD boundaries and compute which edge has a seam. Then I determine which points from that edge are causing the problem. To test that my detection is correct, I apply a very visible and unique pattern to the problematic vertices:

Those points are the ones that need to be fixed. Here is what we get with a proper fixing algorithm:

Once more, this time with wireframe:

This is of course only one edge. Slightly different code is needed to fix the other kinds of edges.

So now I have three LOD levels and full edge seam fixing, but only from level 2 to level 1. I still need to fix the seams form level 1 to level 0. After that the first version of the LOD system is done. I tested it and it seems mostly bug free. On the other hand, it is far from optimal. It can be optimized a ton and it will slowly get better and better.

So let's see the results. I will test the same scene in a problematic area without LOD and then with LOD. To make sure that the data is relevant, the switching from LOD to non-LOD and in reverse clears all pools and caches, calls GC.Collect to clear up the C# garbage collector and re-streams in all the data from disk.

The before shot:

We get 2.798 million triangles rendered at 27 FPS. The data uses 148.6 MiB and a further 64.91 MiB for physics. The physics memory use is constant because I'm not doing LOD on physics. So let's see the after shot:

We get 0.676 million triangles, so we only use 24% of the original triangle count. We now get a FPS of 45, up from 27. Not quite double. While the polygon count is way down, the draw calls and the fill area remain the same. Still, 45 FPS is pretty good. In the past on a Intel on-board you would really struggle to get 30 FPS at 720p and low setting. But now, from my limited testing, I can say that you get between 40 and 52 FPS consistently, based on the complexity of terrain. On a better system I have measured an improvement of up to 80 FPS.

And finally, let's not forget the RAM use. Unfortunately, .NET RAM reporting is completely useless and inconsistent. It reports values I can't make sense of and have little relation to what the Windows Task Manager reports. And it gets completely lost on resources that are on the GPU. So I will consider only the RAM use as reported by my engine.

The original scene used 148.6 MiB and the new one with LOD uses 27.95, which is 18% of the original. This is strange, I was expecting it to be closer to 24%, like the polygon count. Anyway, it eats up at least 100 MiB less RAM and the Task Manager also reports this.

Lol, I might be able to run the engine on a XBox eventually without problems :)).

Anyway, great improvement. I manged to implement this in a couple of days, so not bad. But it was difficult. And fixing seams is no fun. So what is there left to do?

• Fix the seam from level 1 to level 0, like I did form 2 to 1. See if you can spot the seams in the above screenshot.
• Create and awesome video showing off the new performance and view distance possibilities.
• Enhance the system to make it easy to add more levels. I think if I go from 3 levels to 6, I could have an acceptable view distance. The number of levels should be dynamic and changeable on the fly.
• Rebalance the margins. After I finish my comparison video, I will have to rebalance all the margins and frustum constrains and create a new render profile that is optimized for the LOD system. This will means above double default view distance at the same performance. The new normal will have the same view distance as high, and the new high will be a lot bigger.

So Snapshot 11 is on track to have the first version of the LOD system turned on by default. I will probably have to add a LOD aggression option. The above screenshot uses a sensible default that compromises quality for speed. This is the high option:

This uses more RAM and has a higher poly count, but even without the finished seam fixing you can't notice seams because of the higher high quality render distance.

I'll probably add an "ultra" option too. Those people with dual Titans need to use the available power :).