My life just kind of imploded during the last two weeks. I had to take a few days off. Afterwards, I dug into a task which required my full attention, as a way of getting my mind off of any other issues…
So what did I work on, then? Merging coplanar triangles on terrain geometry.
Those of you who are familiar with 3D graphics will already know that all geometry in games is made from triangles of varying sizes and orientations (at least currently, there are approaches using mathematical boundary functions to define volumes of theoretically infinite precision). Triangles consist of three vertices, which hold some more information than just a three-dimensional position. One of the many bottlenecks in real-time graphical rendering is the amount of vertices which an application needs to display at any moment. Therefore, any approach which can reduce vertices at loading time will yield better performance at run time. It is best explained with an image:
In the image above you will recognize the fine-grained mesh on the left from one of my earlier posts when I explained how the terrain is built using pre-defined building blocks. This mesh contains lots of triangles which lie on the same plane and whose vertices hold exactly the same information as their neighbors, save for their position. On the right, only the minimally necessary amount of vertices and triangles are retained. No geometry detail was lost, but it is no longer possible to smooth normals around >=90° angles as before. Normals are shared along much further distances and the visual effect is rather unpleasant if I were to smooth them out.
The experts among you will wonder how I solved the problem of UV coordinates, since terrain is usually textured using a texture atlas and UVs would just get mangled and invalid during vertex merges. I completely avoided the issue by ignoring UVs altogether. Instead, the terrain shader now uses full tri-planar mapping based on world coordinates, which is totally fine for static geometry like terrain. The texture atlas tile index is simply encoded into the vertex colors, which the shader can interpret and apply.
Because I have not done a single thing I set out to do, please see the last post for my next tasks: http://incharge.ctool.ch/2016/07/22/week-16-recap/
Thanks for reading!