Level of Detail - Uniformity

[scottb613]

Hi Folks,

I've got level of detail to work on my models - 3 LOD's with the last one being empty... So I now have 5 models who's width - X axis - varies greatly... They are fence line segments and go from a single pole - to about (21) 12 foot segments... If I make the first LOD transition at "70" for all the models - the narrowest switches first and the widest switches last... Thing in I need the transitions between various LOD's to happen at the same time - irregardless of the width of the model... Is there any way to calculate this value or is there a tool to make this task a little less tedious ??? Right now - I'm just playing with the values in the ASM code and it is taking forever... Modify the ASM - compile the models - swap out the models in the respective library - launch FS9 - evaluate the effectiveness of the last change - pick new numbers - repeat...

I tried using MCX but if I modify the LOD values and save the results - when I open the same model a second time right after my save - the values are completely different from what I originally inserted... Since this doesn't make them uniform MCX really wouldn't save me all that much time anyway...

Also - I think I've got the concept on the LOD's down - as the number reflects the amount/percent of pixels displayed for the swap - but in a 100/40/10 - 100 is always the first model displayed - until you hit the 40 level - right... So on some of my models I open in MCX it shows the first LOD at 160 - what does it do to increase the first value above 100 ???

Thanks...

Regards,
Scott

 

[Stiz]

Also - I think I've got the concept on the LOD's down - as the number reflects the amount/percent of pixels displayed for the swap - but in a 100/40/10 - 100 is always the first model displayed - until you hit the 40 level - right... So on some of my models I open in MCX it shows the first LOD at 160 - what does it do to increase the first value above 100 ???

higher number means it changes quicker, from the SDK

"LODs should be implemented in order to optimize performance. The following is the triangle count for the DC3. Obviously a 747 will need more triangles than a C-172 so use your best judgment. The more complex aircraft models provided with FSX have approximately 25000 triangles for the LOD_400 model. Generally speaking LOD 35 and up will have animations while LOD 15 and below will not. Also LOD 5 is basically created using planar meshes."

LOD_400 = 14000 triangles
LOD_150 = 11000 triangles
LOD_75 = 7000 triangles
LOD_35 = 3000 triangles
LOD_15 = 800 triangles
LOD_5 = 50 triangles

 

[scottb613]

Hi Stiz,

Thanks for the response... I think I'm following - so if I put a 100 - as the largest LOD value on a model that exceeds the number of triangles/polys for a LOD_100 - the compiler just adjusts the value to the appropriate number when compiled ?

Hmm - I'll work on it - my models all have pretty low poly counts - I think 384 is the max I'm working with now...

Thanks...

Regards,
Scott

 

[arno]

Hi Scott,

The lod value is indeed the amount of pixels covered by the object at which it should switch. So it is by design that small objects will switch earlier than bigger ones. They switch once their contribution to the total scene gets smaller.

So to get them switch around the same time, you would have to use different lod values. In modelconverterx I use the distance to the vertex furthest from the center multiplied by a factor of 2.5 to calculate the switch values from the values in the mdl/asm code. In general the values I get are quite close to the ones in the mdl file.

Given that your object mainly vary in length, you could try to divide the lod values by length. So if the long fence switches at 50, a fence half the length would occupy around 25 pixels at that time and would need a lod value of 25.

About the highest lod switch value, it is irrelevant. If you make two models, one with lod 10, 40 and 100 and one with 10, 40 and 1000, they will show exactly the same behavior. So it's the values 10 and 40 that matter. That's also why you see that modelconverterx changes the highest lod. There is just no way to reconstruct that number from the values in the mdl/asm code.

 

[scottb613]

Hi Arno,

Perfect - I'll give that a shot tonight - I'm working off my laptop and I'm seriously missing the speed of my home SSD's for this work... It takes so long waiting to test my results in FS9... Appreciate the - help - patience - and tools - you provide all of us...


Thanks...

Regards,
Scott

 

[jtanabodee]

About the highest lod switch value, it is irrelevant. If you make two models, one with lod 10, 40 and 100 and one with 10, 40 and 1000, they will show exactly the same behavior. So it's the values 10 and 40 that matter. That's also why you see that modelconverterx changes the highest lod. There is just no way to reconstruct that number from the values in the mdl/asm code.

I know that this thread is old but I have a question to ask.
I personally agree with Arno about the higher LOD. However I think if I set the highest LOD more number, I can switch the lower LOD higher too. If I have a big terminal building, I would put 800 LOD for the highest and the second LOD would be 600 and the last one would be 300. So the lower LOD can kick in earlier. There might be no test for the highest LOD but it does make more headroom for lower LOD.

I know that the model with 800, 40, 20 would be the same as 100, 40, 20 LOD.

But if I set it as 800, 600, 100 LOD compare to 800, 40, 20 LOD. I think the second LOD of 40 will kick in much later than LOD 600.

I'm not sure if I understand it right, but it is what I found.

 

[arno]

Hi Tic,

You are right, the highest LOD should be higher than the second highest of course. So which value you want to use for the second highest does influence the value you want to use for the highest. But then it doesn't matter if it's 50 or 100 or 200 higher.

 

[Shaun]

With complex building like terminals I have the most detailed LOD about 600, with one at 200 with just the basic buildings, no cars, lamp posts or small details (So there's only a few drawcalls too)!

Depending on the size, I make the LODS so that you could only make out the transition if you are REALLY looking hard.

For the empty LOD, for small things like cars or static aircraft, a value of 5 works, for terminals 10 works well.

Stiz had the LODs backwards above.

 

[pinkjr]

So, for LOD to work you basically have to create different versions of the same model, manually making them simpler and simpler? What about te textures, do you use the same textures for all LOD versions of the model?

Thanks,
David

 

[jtanabodee]

LODs of texture is Mipmaps.
LODs of model can be done in MCX as well.

 

[fsintegral]

Arno explained the "visible size vs LOD value" above.
When I model something, I take it the other way around (backward process) ie, most modelers arbitrary choose the LOD values (600, 400, 150, 20, 5, etc.) then creates the models with triangles restriction limits (3000, 2000, 500, 100, 30, etc.) Just wanted to share my method, which is the inverse, if that can help...

• I build each LOD variant of the object I'm modeling. If it's a terminal, I create one very detailed (1), another with less details (2), another one even less detailed (3), and a very basic one (4)
• Then I note the resulting triangles count somewhere. Let's assume (1) has 3600 triangles, (2) 1500, (3) 600 and (4) 80.
• Then I calculate an arbitrary value of how many triangle per square pixel should be used as reference for my terminal model : I want my model to stop using the highest LOD(1) if the surface on screen it uses goes below 800x600 pixels. ie, 480000 pixels (or 0.48 MegMix) It's 0.0075 triangles per square pixel using the LOD(1) number of triangles (3600/480000)
  
• Let's take a LOD value of 600 (arbitrary) to begin with. So, the first LOD(1) follows this relation : 3600 triangles -> 480000 pixels for a LOD value of 600.
  
• Then I calculate the other LODs values : 1500 triangles LOD(2) -> 200000 pixels (=1500/0.0075) which is 41.66% of the 600 value above. So I get a new LOD value of 250. Same goes for third LOD(3) which as 600 triangles, corresponding to 80000 pixels, wich is 16.66% of the 600 value. Next LOD becomes 100.
• But heh, I wanted the terminal to switch to LOD(2) when the surface on screen goes below 800x600 pixels. So it's the LOD(2) which would have the _LOD_600 suffix, and LOD(1) should have an higher value, for eg. _LOD_800. That's why I didn't calculate the relation for the 80 triangles (LOD(4)) model.

And I get :
Terminal_LOD_800 (3600 triangles)
Terminal_LOD_600 (1500 triangles)
Terminal_LOD_250 (600 triangles)
Terminal_LOD_100 (80 triangles)
If I were to add another LOD(5), the 80 triangles computation would give me a surface factor of 10666 pixels (2.22%) and a deduced LOD value of 13.

This technique worked well for a lot of objects I made in the past for FS9 (or so I tend to believe - I haven't seen wrong LOD switches so far, but it all depends on what one or another likes)

So, for LOD to work you basically have to create different versions of the same model, manually making them simpler and simpler? What about the textures, do you use the same textures for all LOD versions of the model?

That's it. Only one of those model variants you made will be displayed at a time (assuming you set them correctly in the modeler or selected them accordingly using a compiler - In GMax, you use the suffix "_LOD_xxx" per sub-model to tell the compiler those are different LODs) The compiler uses the LOD value you provided to tell FlightSim which one will be displayed at a given size on screen.

You usually (and should) use the very same texture(s). As noted above, textures has usually mipmaps in there (or the simulator creates them in memory if missing) which are lower and lower detailed sub-versions. When seen from far, your graphic card is designed to use a lesser detailed version of the texture on objects that are rather small on screen. Less computations per texture pixel => better performances.
The more you uses textures, the more you'll have what are called drawcalls, which are redundant routines performed by the graphic card processor. Better is keep their count as low as possible, so, don't create specific textures for your lower detailed LODs...
However, an object the size of a terminal rarely uses one single texture (unless full-HD 4096x4096 pixels texture perhaps) I've seen designers adding extra smaller version of their terminal texture in an available/unused area of the main terminal texture (ie, the same texture file will be called by the drawcall) I don't know if it really improves performances, but tests I made in 2009 or 2010 have given very similar framerates, using or not that extra low detailed mapping version... No certainties so far.

Side note : I talked about drawcalls, though, knowing almost nothing about. Maybe I shouldn't have.

 

[pinkjr]

Karl, thank you so much for your explanation. So when I convert the model using MCX, the bgl should use name_LOD_xxx.bgl convention?
I noticed that MCX has an LOD panel, how is it used? Do I use that panel to assign an LOD order number?

David

 

[pinkjr]

Another question, can you collect the LOD files in a single bgl library, and place them using something like Instant Scenery? Can they all go into a single bgl, or do they need to be placed individually, keeping the LOD name convention?

 

[arno]

Hi,

All levels of detail go in the same mdl file, they are not separate objects.

The naming convention you mention is for modelling tools like GMax, not for the mdl or bgl files. MCX uses such naming in the x file it writes when you export an object.