My LOD Bible

Originally created November 16, 2009

From HelL, Oh Dear!...  To HelLO, Dy-no-mite!

Automatic Polygon Reduction Tools may promise quick results, yet often the visual outcomes are less than heavenly. Avoid hellish results by following these simple guidelines listed below:


1. In The Beginning
The ideal LOD swapping system crossfades the higher LOD mesh to the lower LOD mesh. Both meshes fade reciprocally, from 100% to zero visibility on one mesh, and from zero to 100% on the other. The blending of meshes appears smooth. Such a system is processor heavy and framerate suffers horribly.

Fortuante teams will not have LOD blending removed completely, but will retain half of the process. Lets look at how single direction LOD blending works, and how artists can make the most of the process.

2. Thy Cup is Half Full

In the single direction blending system, at the instance an LOD swap begins both meshes have 100% visibility. If the lower LOD was created properly, no visible change should be seen at this point. As the blending progresses, the higher LOD's visibility gradually decreases to reveal the lower LOD inside. Every vertices of the lower LOD must be completely contained within its higher sibling. No points may extend past the shell of the higher. If any points poke beyond the shell of the higher, "popping" or flickering will occur.

3. Rule of Russian Dolls
Collapsing edges and deleting points in a haphazard fashion will guarantee you a slow painful death on top of an eternal suffering in hell. Proper care must be taken so that your polygon reduction work does not cause any piece of your lower mesh to poke through its higher sibling. The best LODs fit wholly and completely within its higher sibling.

Collapsing edges can greatly change the silhouette that define the shape of the original mesh.












Viewing both meshes together show the lower mesh poking out beyond its higher sibling. This must be avoided.

The lower LOD eclipsing the higher completely negates the blending process.

Deleting edges is the preferred method to reduce points.

Here is the 3rd LOD that strictly follows the Russian Doll Rule.

Deleting another edgeloop would be the most ideal. We attempt to do this by first scaling out the top vertices so that edges running  vertically on our cylinder change position as little as possible.

When checked with the previous LOD we notice that we've broken the Russian Doll Rule.

Because polygon reduction is our top priority we choose to keep LOD 3, and we fudge the shape of LOD 2 to keep in line with our rule.

We snap the top vertices of LOD 2 to match LOD 3.

We do the same with LOD 1.

Viewing all 3 together we see a very good set of LODs that will blend nicely.










4. Concave Shapes


When reducing points on a concave shape you must take care to change edge positions as little as possible. Deleting edges alone will not always work in every case.

Deleting these edges causes the hole to shrink and our new mesh breaks the Russian Doll Rule.











Moving the edges to match the position of the original edges is the way to go.




  






But we are not quite done yet. When viewing our meshes together we notice flickering of polygons, even though no portions of LOD 2 poke out beyond LOD 1.

This flickering is caused by a soft/hard edge conflict between our 2 meshes.

The flickering is fixed by marking the edges of LOD 1 <hard> to match the shading of LOD 2.











We check our work again by viewing the 2 meshes together. Everything looks swell.

 5. Jagged Shapes


Lets apply what we've learned thus far to a mesh that is both concave and convex.











Here is a bad attempt at deleting edges.












No Russian Doll here.



 

 






This reduction is ok.












And it abides by the Russian Doll Rule just fine.

But something tells me we have it in us to do better.

The deletion of these edges looks very efficient. Optimization is our focus here.












Except we've broken the our golden rule.












We fix this by going back to LOD 1 and adjusting the vertices there.











 That is one righteous LOD set!














6. Book of Tesselations

Do you continue to have flickering and polygon fighting even when your faces share the same plane? Is there any end to this sibling rivalry, you say? There is an end, and it lies in the book of tesselations.

Here is our original mesh.












We know from previous lessons that this reduction of points is wrong.











And this is the right path.

Yet we continue to see flickering when blending LODs.

Upon inspection we see that the tesselation of our faces don't quite match between our 2 meshes.








We flip our edges so that LOD 1 is as close to LOD 2 as possible.

With matching tesselation, coplanar polygons no longer fight.

7. In Summary
The one requirement often given to artists for the blending to work properly is that the lower LOD mesh must be smaller that the higher LOD. While this rule is entirely accurate, it fails to convey many important details about the mesh that are often overlooked. Vertex positioning, hard/soft edges, and tesselation are factors that can make or break your LODs. 

Automatic polygon reduction tools and the process of collapsing edges are often the quickest way to reduce points, but they nearly always lead to results that completely nullify the blending effect. Take care to reduce points strategically. Careful work will save you from future pain and suffering.

Widespread Demolition

Target the support columns near the
base and rest comes tumbling down.

The assignment was to create a completely destructible environment in an open world game. A lofty goal for sure. Physics were already routinely used for small inconsequential objects in the world like crates and barrels, and for sparsely positioned landmark objectives (e.g. gates, walls, and other player impediments). We were planning to add physics to where it mattered during game play... and in an open world game, game play is EVERYWHERE. Whole city blocks would need to be leveled to advance objectives and the player would be provided with wildly creative ways to do so.

The entire city would need to have the capacity to be flattened by the player. No structure would be able to withstand any substantial blast, be it from mortal shells, rocket fire, missile launches by a gunship circling overhead, or even by the gunship itself, should it be shot down and crash into a building.  Every building would be destructible.

Such a task is daunting for a "normal" level, but how do we find a solution for an open world game? Nearly impossible right? Well, nearly...

The biggest problem was frame rate. Buildings are large objects, which when destroyed, break apart into millions of pieces. The bigger the building, the more pieces on screen requiring physics, the more calculations needed to be performed. All attempts to make a structure break apart in believable fashion, with dozens if not hundreds of chunks of debris, would give the engine a heart attack. The small quantity of physics objects the engine could handle was paltry and the destruction of large structures looked horribly cheap. The only option available from our old engine was to have the entire building, as a whole sink, into the ground. No amount of smoke and dust effects could make a building 'slide' into the earth and not look absolutely ridiculous.

We needed the buildings to break apart like buildings should. Walls needed to be blown away to expose interior space, chunks had to break off and fall to the ground and explode to even more chunks. Buildings needed to tilt and topple over, and whole floors whose support columns have been compromised needed to be flattened in succession like pancakes.

We needed a LOT of physics. We didn't have a lot of room for physics.

The breakthrough came with a proprietary debris system that split the difference between effects and physics. If debris pieces could be stripped to their bare minimum in terms of physics, (i.e. contain very simple collision), they would not cost much more than effects. The system enabled us to load up our screen with hundreds of 3D meshes showering down upon the player and colliding with each other and the ground, but costing little more than regular 2D effects. This debris combined with smoke effects allowed us to cheat the number of real Havok chunks needed to mimic a destroyed building. We finally had the impossible look we were after.

With the technology now available, the challenge became developing the production pipeline to build such a level in a reasonable time frame. And the assets needed to be effiicient and streamlined to fit within engine limitations.

The environment artist was challenged with devising a system of creating buildings that used generics wall pieces specially designed for easy implementation of Havok destruction, but such that the buildings appeared unique and distinctive so that the level would not look repetitive. 

Modulation was key. All textures needed to adhere to strict guidelines. Every building would be designed from a template to maximize reusibility. Building size and floor heights had to be standardized. Shaders needed to be organized and components such as textures, alphas, grime maps, needed to be shared and be as interchangeable as often as possible. We partnered with technical artists to develop robust shaders that would open the path for environments to be built with flexibility and efficiency.

The system was built and our road map was laid out, but the project was put on hold. It remains buried somewhere under a mound of rubble... waiting to be resurrected.