56 – 3D Week 1 in review

Today I am going to talk about the state of the engine after one week of development. First I am going to talk about the good parts, then about the bad parts.

The biggest good point is that the engine is fairly stable and can be easily extended to handle a lot of stuff. Performance woes are always towering over me like a huge gassy floating giant monster cow, but it is under control. Performance may not be extraordinarily good compared to the graphics quality, but it is very consistent, running with comparable FPS on different machines. Using this engine it was easy to add real terrain elevation and current level highlighting:

I also did just a little bit of optimization. Check out the south wall of the map in wireframe:

We have a lot of extra unnecessary polygons. I fixed this:

Of course, I wrote the optimization in such a way that it can handle LOD, so I can swap between the lowpoly and highpoly meshes based on distance, but I disabled this. The only problem is that the low poly models create very muddy textures:

There is no way to fix this without sacrificing performance and adding a lot of algorithmic complexity, but it can be improved a little by better texture work. On the other hand, these textures are only visible on the sides and look so ugly only when they are too long, so normally you won’t notice this.

But the thing I am most excited about is the new forests. I grew tired of the clone forest, so now every single tree is unique:

The trees still look ugly as hell, but it is a nice step up from the old trees that were two cubes.

And now comes the bad.

I think I tracked down the visual artifacts I get to Z-buffer fighting. This game uses a very long viewing distance and we do have some very close surfaces that could cause these problems. I will try increasing the Z buffers to 24 bit.

This issue is not helped at all by the way I am doing collisions. I create an extra polygonal plane and cast a ray from the camera position to the mouse cursor. Where it intersects this “hidden” plane is the position my in game 3D cursor should be. Now this work very well and I am very happy with the precision of the cursor. The only problem is that that surface is not hidden. Collision does not work for hidden objects. So I have one extra surface fighting for the Z buffer right beneath the real surface of the terrain. I tried for hours casting the same ray and intersecting it with a false plane, one that is not made out of polygons, but I failed. I worked fine for short distances, but as distances grow so does precision decrease. So for now I have a hack: I reversed the normals for the surface, making it face away from the camera. Collision still works and Z buffer fighting does not occur unless you are looking at the map from underneath. I also made the surface green, as my maps tend to be green, thus lessening the impact of it. At least you can’t accuse me of not giving creative solutions to problems!

But the biggest problem is the camera. I worked for hours trying to achieve a camera angle similar to the 2D one. Programming the camera is a lot harder than the rest of the engine. I was almost ready to give up and only go with a top down but tiltable camera and a first person fly by camera. Then I managed to get some fairly decent results, so I am confident that I can get at least a workable if not optimal camera angle on the scene in an “isometric” fashion.

As for using a real orthographic camera, using that in Irrlicht gives very weird results. Culling is a lot more aggressive making parts of the scene disappear and setting camera position does not work as expected. SO I’ll continue and investigate the camera with perspective.