Questions about game engine LOD use.
Author
Hello,
I have a few questions about usage of LODs in game engines.
I have a solid game programming background but have not implemented LODs before and am hoping to get some info on the subject.
Ok, so I understand how to use progressive meshes for my models using DirectX, but....it is my understanding the progressive meshes in DirectX do NOT update texture coordinates...so...that route seems pointless in a DirectX game engine.
Are progressive meshes the way to go for object level LODs?
The only other object level LOD strategy I know of is to use several variants of a model with different triangle counts and then just use the most appropriate version based on distance to the viewer.
The variant version seems a little haphazard in that the objects will pop in and out of triangle counts and could get ugly.
For terrain, I am aware of the ROAM algorithm but people seem to criticize that a lot for being slow. So....my only other knowledge of the topic as it applies to terrain use is to use either different terrain patches with different triangle counts, or to use the DirectX N-path or otherwise curvature patterns (nurbs, b-splines etc) with different tesselation counts based on distance to the viewer. The curvature seems to work well as you can increase or decrease tesselation counts based on distance. I would say the DirectX N-patch/curvature route would be the best but am no way 100% sure of this.
One problem with the N-patch/curvature route is.... if I have a DirectX N-patch or curvature stored, I will need to acquire the actual vertices of the patches in order to integrate with the physics/collision detection engine (namely ODE) that requires vertex arrays of all meshes.
Ok...enough rambling...Ok...so I guess in summary, my questions are:
1) What is the best way to implement object level LODs for mid-sized FPS game? If it is progressive meshes, how do you update the texture coordinates of the new triangles in DirectX? If it is different models with different triangle counts, how do you prevent popping? If it is something else, please leave any details possible so that I can do some research.
2) What is the best way to implement terrain level LODs for a mid-sized FPS game? If it is ROAM, please explain why this is the best. If it is different models with different triangle counts, again...how do you prevent popping? If it is N-patches/curvatures, how do you acquire the vertices of the highest level of tesselation using DirectX to pass to the Physics engine?
If it is something else, please leave any details possible so that I can do some research.
Thank you again, obviously...feel free to ramble and say any and/or all information you have on the LOD subject as I am still somewhat trying to grasp the best ways to use it.
Thank you again,
Jeremy
In general, any procedural technique has a very difficult time being GPU friendly as you typically have to completely respecify vertices and/or indices every frame. There are some ideas towards fixing this in the incomplete ROAM 2 (http://www.cognigraph.com/ROAM_homepage/ROAM2/) algorithm. Other issues are with spending so much CPU time computing the newly-refined mesh when there are other components of the engine competing for this time. Essentially low CPU use and high GPU friendliness (low number of batches of large amounts of data) algorithms are most desirable; you get to optimize what high/low mean to your game and its set of goals.
The way the engine I work on operates is to use different models that are artist generated with an view distance as a property of the mesh. So a model "looks" the same as the highest detail mesh when viewed from that distance and beyond. This technique is extremely simple to implement, but the downside is having more data to load (especially with skinned skeletal animations).
The current top of the line terrain rendering technique is geoclipmaps (see: http://www.gamedev.net/community/forums/topic.asp?topic_id=421892 and the originator of the technique http://research.microsoft.com/~hoppe/). This technique works well for static and dynamically generated terrain data of massive scale, however it requires an alternate render path if your users do not have a video card that supports vertex texture lookup (Shader Model 3.0). Collision may not be as simple because there is no saved mesh, instead it is just a set of dense heightfields (texture) of different scales, though many physics engines directly support this. John Carmack has a version of this idea that he independently created labeled "megatextures"; I believe he integrates some artist-assisted texture coordinate fix-ups to give additional detail (to slopes, lines on roads) without increasing the base image size. It took myself and another coder a few months to get this working, so an easier solution would probably be desired if you're just trying to get an engine up to speed for yourself.
Our previous terrain implementation was a basic "chunked LOD"; a quadtree of N x N meshes with differing scales created from the height data. The biggest issue with this was creating a low detail mesh requires either long precompute time or scattered reads of the height data. Another advantage of this technique and the precomputed LOD-ed models is that they are nearly identical and can have a lot of common code whereas the geoclipmaps are entirely different.
Things we are still trying to get a grasp on are physics and AI LOD; we're just not at the point where we have a lot of time to spare. Physics LOD shouldn't be too far of a reach as some simple things to do would be collision mesh LOD, and skeleton and joint constraint simplification (Ex: Model goes from lots of bones to few to a single transform to just a translation). Simple things in common to both would be update frequency reduction.
The way the engine I work on operates is to use different models that are artist generated with an view distance as a property of the mesh. So a model "looks" the same as the highest detail mesh when viewed from that distance and beyond. This technique is extremely simple to implement, but the downside is having more data to load (especially with skinned skeletal animations).
The current top of the line terrain rendering technique is geoclipmaps (see: http://www.gamedev.net/community/forums/topic.asp?topic_id=421892 and the originator of the technique http://research.microsoft.com/~hoppe/). This technique works well for static and dynamically generated terrain data of massive scale, however it requires an alternate render path if your users do not have a video card that supports vertex texture lookup (Shader Model 3.0). Collision may not be as simple because there is no saved mesh, instead it is just a set of dense heightfields (texture) of different scales, though many physics engines directly support this. John Carmack has a version of this idea that he independently created labeled "megatextures"; I believe he integrates some artist-assisted texture coordinate fix-ups to give additional detail (to slopes, lines on roads) without increasing the base image size. It took myself and another coder a few months to get this working, so an easier solution would probably be desired if you're just trying to get an engine up to speed for yourself.
Our previous terrain implementation was a basic "chunked LOD"; a quadtree of N x N meshes with differing scales created from the height data. The biggest issue with this was creating a low detail mesh requires either long precompute time or scattered reads of the height data. Another advantage of this technique and the precomputed LOD-ed models is that they are nearly identical and can have a lot of common code whereas the geoclipmaps are entirely different.
Things we are still trying to get a grasp on are physics and AI LOD; we're just not at the point where we have a lot of time to spare. Physics LOD shouldn't be too far of a reach as some simple things to do would be collision mesh LOD, and skeleton and joint constraint simplification (Ex: Model goes from lots of bones to few to a single transform to just a translation). Simple things in common to both would be update frequency reduction.
Author
Hello ebnf,
Thank you very much for your help. That was extremely helpful. I will definately look into the details. Thank you once again.
If there is anyone else with some more insight or information on the subject I would love to hear it.
Thank you,
Jeremy (grill8)
Thank you very much for your help. That was extremely helpful. I will definately look into the details. Thank you once again.
If there is anyone else with some more insight or information on the subject I would love to hear it.
Thank you,
Jeremy (grill8)
It should be noted that modern games are often CPU-bound. LOD techniques trade GPU time for CPU time (and vice versa). On modern hardware, you are better off just rendering the extra stuff.
For example, many older engines have dynamic level of detail terrain because every triangle rendered was expensive on the GPU. The Unreal engine simply brute force renders the terrain and culls obstructed terrain tiles because collapsing triangles is expensive on the CPU.
I suggest you optimize later. Build your game now, and add LOD as needed. Profile, determine what is bounding your performance, and add LOD makes appropriate tradeoffs.
For example, many older engines have dynamic level of detail terrain because every triangle rendered was expensive on the GPU. The Unreal engine simply brute force renders the terrain and culls obstructed terrain tiles because collapsing triangles is expensive on the CPU.
I suggest you optimize later. Build your game now, and add LOD as needed. Profile, determine what is bounding your performance, and add LOD makes appropriate tradeoffs.
Author
Hello snprBob86,
That is good advice. Also good info. Thank you.
I will likley do just that....optimize later.
I believe I will use an object level octree/frustum cull for culling offscreen terrain tiles (and objects) and add LOD later as needed.
Thank you once again,
Jeremy
That is good advice. Also good info. Thank you.
I will likley do just that....optimize later.
I believe I will use an object level octree/frustum cull for culling offscreen terrain tiles (and objects) and add LOD later as needed.
Thank you once again,
Jeremy
Since nobody touched the subject yet, I will show 2 techniques to fight the popping effect when using multiple simplified models.
1. Alpha blending transitions
Quite simple, instead of just swapping the model to the next detail level, gradually fade out the old and fade in the new.
Given 0 is the highest LOD, let's say
100 yard from cam: LOD0 100% LOD1 0%
110 yard from cam: LOD0 50% LOD1 50%
120 yard from cam: LOD0 0% LOD1 100%
Pro:
Possibly the best effect, almost zero popping.
Con:
Can be slow. For a time, you render both models, plus alpha blending is costly anyway.
I would use it only if you have few important main object in the focus. Prolly would do more harm then good if used on a lot of objects. But this depends on models and hardware, testing required.
2. LOD switch delay
This won't reduce popping, just eliminates a "fixed pop border" making it less noticeable.
100 yard from cam: LOD0
105 yard from cam: still LOD0
110 yard from cam: LOD0 dies, LOD1 pops in
105 yard from cam: still LOD1! (no switching at 110 boundary to LOD0)
100 yard from cam: LOD1 dies, LOD0 pops in
Pro:
Cheap, easy to implement.
Can be applied to almost any LOD chance.
1. Alpha blending transitions
Quite simple, instead of just swapping the model to the next detail level, gradually fade out the old and fade in the new.
Given 0 is the highest LOD, let's say
100 yard from cam: LOD0 100% LOD1 0%
110 yard from cam: LOD0 50% LOD1 50%
120 yard from cam: LOD0 0% LOD1 100%
Pro:
Possibly the best effect, almost zero popping.
Con:
Can be slow. For a time, you render both models, plus alpha blending is costly anyway.
I would use it only if you have few important main object in the focus. Prolly would do more harm then good if used on a lot of objects. But this depends on models and hardware, testing required.
2. LOD switch delay
This won't reduce popping, just eliminates a "fixed pop border" making it less noticeable.
100 yard from cam: LOD0
105 yard from cam: still LOD0
110 yard from cam: LOD0 dies, LOD1 pops in
105 yard from cam: still LOD1! (no switching at 110 boundary to LOD0)
100 yard from cam: LOD1 dies, LOD0 pops in
Pro:
Cheap, easy to implement.
Can be applied to almost any LOD chance.
also on the popping effect:
How often do you really watch an object travel into the distance or from the distance into the frame? I'm willing to bet not often outside of large outdoor scenes when you are travelling quickly, like in a plane.
My suggestion?
Only change the LOD when the player isnt looking or when going from low-to-high detail. Switch from low to high detail as early as early if the player is looking (make the pop happen further than where you can see it).
How often do you really watch an object travel into the distance or from the distance into the frame? I'm willing to bet not often outside of large outdoor scenes when you are travelling quickly, like in a plane.
My suggestion?
Only change the LOD when the player isnt looking or when going from low-to-high detail. Switch from low to high detail as early as early if the player is looking (make the pop happen further than where you can see it).
Author
Thanks again all. That is all good information. I will definately investigate into these matters to find the most efficient and applicable LOD strategy. Thank you.
Any more information is absolutely welcome.
Jeremy (grill8)
Any more information is absolutely welcome.
Jeremy (grill8)
http://lodbook.com/
Probably the best (or only) book in this section. It's really well made.
Probably the best (or only) book in this section. It's really well made.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
