Better LOD?
by Erik Madison · in Torque Game Engine · 02/23/2004 (7:46 am) · 10 replies
A problem I have with LOD, is determing the proper values, and at what position that value would come into play.
Take a ball and a tree for example; The ball is using 128/64/32 for lod values. At around 50% viewing distance the ball is approx 40 pixels and thus would use lod_32. At its closest, its only around 100 pixels, and therefore never uses lod_128, which is its highest resolution.
A tree with the same values; At 50% viewing distance, its still around 130 pixels and is therefore using lod_128 showing _much_ to much detail for that far away.
So... with TGE's lod method, builders and modelers must constantly tweak values until everything works right. They have very little control over which distance uses which lod.
After reading resource www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=3920, I got to thinking about a strict distance based lod. I would ignore the actual lod values builders use, and instead rely on the number of values + 1. So, the ball and tree would maintain their highest lod for 25% of viewing distance, and change lods each 25% increment. If I had given them 4 levels of lod, they would be changing at 20%. This method would also allow greater control of blank details. Many items should never be rendered at certain distances, say a pile of trash on the floor (modeled). If it had valid details of 128 and 64, and blank details of 32 and 16 (any numbers work with this method), then at about 50% viewing distance, it would disappear completely.
Anyone see a reason this would not work better? Is checking camera/object distance any more intensive than checking pixel sizes?
Take a ball and a tree for example; The ball is using 128/64/32 for lod values. At around 50% viewing distance the ball is approx 40 pixels and thus would use lod_32. At its closest, its only around 100 pixels, and therefore never uses lod_128, which is its highest resolution.
A tree with the same values; At 50% viewing distance, its still around 130 pixels and is therefore using lod_128 showing _much_ to much detail for that far away.
So... with TGE's lod method, builders and modelers must constantly tweak values until everything works right. They have very little control over which distance uses which lod.
After reading resource www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=3920, I got to thinking about a strict distance based lod. I would ignore the actual lod values builders use, and instead rely on the number of values + 1. So, the ball and tree would maintain their highest lod for 25% of viewing distance, and change lods each 25% increment. If I had given them 4 levels of lod, they would be changing at 20%. This method would also allow greater control of blank details. Many items should never be rendered at certain distances, say a pile of trash on the floor (modeled). If it had valid details of 128 and 64, and blank details of 32 and 16 (any numbers work with this method), then at about 50% viewing distance, it would disappear completely.
Anyone see a reason this would not work better? Is checking camera/object distance any more intensive than checking pixel sizes?
About the author
#2
The question still remains though; What did I forget to consider? When an idiot like me has an idea, its usually wrong for some reason or another :)
02/23/2004 (10:19 am)
This method would allow any numbering scheme to be used. So, older meshes could retain their 128,64 etc, while your new models could be numbered 100 (100%), 50 (50% detail), etc.The question still remains though; What did I forget to consider? When an idiot like me has an idea, its usually wrong for some reason or another :)
#3
02/23/2004 (4:25 pm)
*bump*
#4
02/23/2004 (5:00 pm)
This is incorrect. You can use any number you want for levels of detail. Make your tree have lower detail at 128, and higher at 256, 350, 413, whatever. Just name your detail markers and meshes with according numbers.
#5
Also, people with higher resolutions are likely to be using better graphics cards, and thus can handle more poly's on the screen at once. Therefore, if you model your details well, they will be invisible to the user when they change, regardless of their screen resolution.
02/23/2004 (5:07 pm)
The reason you check pixel height instead of camera distance is because on a high res screen, you want things to remain at a high enough detail level that they both look good, and don't visibly "pop" when changing detail levels.Also, people with higher resolutions are likely to be using better graphics cards, and thus can handle more poly's on the screen at once. Therefore, if you model your details well, they will be invisible to the user when they change, regardless of their screen resolution.
#6
Might seem like a pain in the butt, but this method gives you the most control when adjusting detail levels. There is no way around it, if you are trying to make ti look good and run fast, you need to take the time to tweak, and this method offers (in my opinion) the most control with the least headache.
02/23/2004 (6:00 pm)
The way to check detail levels is to just pop into the game, check for popping and framerate, pop back into the shell, reset screen resolution, check again. Might seem like a pain in the butt, but this method gives you the most control when adjusting detail levels. There is no way around it, if you are trying to make ti look good and run fast, you need to take the time to tweak, and this method offers (in my opinion) the most control with the least headache.
#7
@Alex - Differing screen res's would make sense, except the code bases everything off a 640x480 screen. Everyone pops details at the same distance.
I'm not looking to shortcut the model building process, and I think my detail levels are working quite well right now. Its the problem of knowing what numbers are ideal for each sized object. max detail of 256 works great for characters and vehicles, but it doesn't work for healthkits. I can take a guess, load it, guess again, load it, etc. Or I can say 'this object needs to hold this detail for at least this far'
02/23/2004 (6:37 pm)
@Alex - How can you use any numbers? Only the proper scheme works. I know this from a smaller object I created. Its highest detail was 256, next was 128. It never showed detail 256 in game, due to the object never occupying that much screen space. Once I bumped each level down a notch, it worked fine.@Alex - Differing screen res's would make sense, except the code bases everything off a 640x480 screen. Everyone pops details at the same distance.
I'm not looking to shortcut the model building process, and I think my detail levels are working quite well right now. Its the problem of knowing what numbers are ideal for each sized object. max detail of 256 works great for characters and vehicles, but it doesn't work for healthkits. I can take a guess, load it, guess again, load it, etc. Or I can say 'this object needs to hold this detail for at least this far'
#8
you can leave empty details, and you can switch out objects if you want (a billboard for instance)...
There is no 'ideal' number for the detail levels. It is totally game and performance dependent. Players will forgive detail popping but will not forgive a drop in frame rate.
Best is to test on a shape by shape basis to get the performance/look you desire. And yes, you do have to take into account that all the shapes are different sizes. Some shapes will never need a detail level over 100.
a contradiction... you are trying to shortcut the process. the ideal numbers are found by testing and experience, and again, are particular to the project you are working on.
02/23/2004 (7:09 pm)
The detail numbers are not fixed. They can be anything. you can have them set at 90, 80, 70, 60, etc.. , and it can be different for every object.you can leave empty details, and you can switch out objects if you want (a billboard for instance)...
There is no 'ideal' number for the detail levels. It is totally game and performance dependent. Players will forgive detail popping but will not forgive a drop in frame rate.
Best is to test on a shape by shape basis to get the performance/look you desire. And yes, you do have to take into account that all the shapes are different sizes. Some shapes will never need a detail level over 100.
Quote:I'm not looking to shortcut the model building process (snip) Its the problem of knowing what numbers are ideal for each sized object
a contradiction... you are trying to shortcut the process. the ideal numbers are found by testing and experience, and again, are particular to the project you are working on.
#9
02/24/2004 (1:16 am)
In directx 9 I ones used progresive mesh i think it was, its an automatic LOD, with no steps it just removes polys based on the distance to the camera, Is that imposible to use here??? maby its just a dx9 thing and not working in OpenGl... I dont know, just that it looks realy good and its easy for the modeler...
#10
@Erik: The LOD code runs off of the real screen size. GUIs live in a 640x480 world, but 3space doesn't.
A quick way to see if a size "works" for a LOD would be zoom out from the LOD in your modelling tool until it looks acceptable. Then see how many pixels in size it is and set that as the LOD. Or you can do what Joe says, or come up with your own metrics. LOD will never look exactly perfect, but with some experience and tweaking, you can get really close. A hardcoded method like you suggested at the beginning of the thread could work well for you - in which case I encourage you to modify Torque to work that way. You have the source, after all. :)
02/24/2004 (9:54 pm)
@David: Actually, it's a pain to work with. You can't control how LOD is generated, nor is it going to be as efficient as "static" LOD. It also makes skeletal animation extremely painful.. So you end up burning a huge amount of coding and runtime resources on something that you could just as easily offload to the artist - which is also nice because it means they can control LOD exactly as they want.@Erik: The LOD code runs off of the real screen size. GUIs live in a 640x480 world, but 3space doesn't.
A quick way to see if a size "works" for a LOD would be zoom out from the LOD in your modelling tool until it looks acceptable. Then see how many pixels in size it is and set that as the LOD. Or you can do what Joe says, or come up with your own metrics. LOD will never look exactly perfect, but with some experience and tweaking, you can get really close. A hardcoded method like you suggested at the beginning of the thread could work well for you - in which case I encourage you to modify Torque to work that way. You have the source, after all. :)
Torque 3D Owner David Erenger