Progressive Detail Levels
by Duncan Gray · in Torque Game Engine · 12/27/2004 (6:51 pm) · 1 replies
Progressive Detail Levels
There are some advantages to not having to create detail levels for your mesh artwork, but to rather have the engine take care of it for you. The idea being that you create the high detail version for when the mesh-shape is close to the camera and the engine gradually displays less triangles as the camera gets further away.
There are some rocket-science formulas for doing just that but the engine performance could suffer as a result. I'd like to put forward a simpler approach.
If we have a pre-determined scale of distance/vertex-percentage values such as at distance 20m we use 90% of the shapes vertices, at distance 30 we use 85% etc. then we can set up a table as shown below:
| index | v-co-ordinates | max distance / 32 |
| U32 | Point3F | U32 |
| 0 | x, y, z | d0,d1,d2,d3 - d31 |
We use each each bit of the distance field to signify a distance from camera which can be calculated as max distance / 32. The vertices are indexed, so we can, when the dts is loaded, calculate that to display 90% of a 3000 vertex shape, we need to NOT display every 30th vertex etc. and then flag that vertexes distance column d0 to tell the engine to not display that vertex when the camera is at distance d0 from the shape.
At distance d20 we might already be skipping every 5th vertex etc.
The above design does not significantly increase the memory requirement of the shape, yet it contains 32 detail levels.
Now I understand that skipping a vertex will break a triangle and maybe leave a black hole where the triangle was. I don't know TGE well enough to know what it will display. This is where TGE community comes to the rescue. Some of you have the required experience to solve this. Perhaps find the two connecting vertices of that triangle and set their co-ordinates the same as the one being skipped which should ?close the hole? so too speak. What do you experts think of the concept?
There are some advantages to not having to create detail levels for your mesh artwork, but to rather have the engine take care of it for you. The idea being that you create the high detail version for when the mesh-shape is close to the camera and the engine gradually displays less triangles as the camera gets further away.
There are some rocket-science formulas for doing just that but the engine performance could suffer as a result. I'd like to put forward a simpler approach.
If we have a pre-determined scale of distance/vertex-percentage values such as at distance 20m we use 90% of the shapes vertices, at distance 30 we use 85% etc. then we can set up a table as shown below:
| index | v-co-ordinates | max distance / 32 |
| U32 | Point3F | U32 |
| 0 | x, y, z | d0,d1,d2,d3 - d31 |
We use each each bit of the distance field to signify a distance from camera which can be calculated as max distance / 32. The vertices are indexed, so we can, when the dts is loaded, calculate that to display 90% of a 3000 vertex shape, we need to NOT display every 30th vertex etc. and then flag that vertexes distance column d0 to tell the engine to not display that vertex when the camera is at distance d0 from the shape.
At distance d20 we might already be skipping every 5th vertex etc.
The above design does not significantly increase the memory requirement of the shape, yet it contains 32 detail levels.
Now I understand that skipping a vertex will break a triangle and maybe leave a black hole where the triangle was. I don't know TGE well enough to know what it will display. This is where TGE community comes to the rescue. Some of you have the required experience to solve this. Perhaps find the two connecting vertices of that triangle and set their co-ordinates the same as the one being skipped which should ?close the hole? so too speak. What do you experts think of the concept?
About the author
Torque Owner Jarrod Roberson
the issue is, ALL this can be pre-calculated and saved once, and that is where it should happen, pre being the important part as in before loading, as in during SAVING of the .dts shape.
that is unless there is some special gameplay mechanic that deforms/decimates the meshes in real-time so that pre-calculation is not possible, this has only been a problem for certain scientific simulations I have read about.
the problem is usually more about texturing and uv coordinates once the mesh becomes decimated.
if done during the export phase the uv map might be able to be recalculated and a new uv map for the new decimated mesh save, or the decimation process might exclude the vertexs that are mapped from being removed.
it is lots of work and will probably not be correct a majortiy of the time, the hand tweaking will probably start climbing back to parity on more complex models.