[Genma Saotome]

I do all of my modeling in inches, set my LOD values in meters. Being curious one day I figured out than at HD resolution (1920x1200 on my monitor) one inch of model equaled 1 pixel at 125m. Since then I've used a fairly standard LOD set of values:

• 250m for narrowest face of 2 inches
  
• 500m for narrowest face of 2.1 to 4 inches
  
• 750m for narrowest face of 4.1 to 6 inches
  
• 1000m for narrowest face of 6.1 to 8 inches
  
• 1500m for narrowest face of 8.1 to 12 inches
  
• 2000m for narrowest face of 12.1 to 16 inches

I admit the numbers are purely subjective; I only use those LOD levels that are relevant to the model and provide some value in their reduction in faces.

My problem: Like many, I've now changed monitors and am running them at UHD resolution (i.e., 4k). I'm not going to change my LOD values (too many models to update) but it did get me thinking about something I think might be a fairly simple change for OR: Add 1 line to .sd files that says something about what screen resolution was used to set the original LOD's and then in the loader software have OR glance at the current monitors resolution and based on the difference between what is in the .sd file and what the computer is using, apply a factor to the LOD values in the .s file before passing it on to the game engine.

For example, if the .sd file has LODResolution(HD) and the monitor is currently UHD, multiply the LOD values in the .s file by 2. That would keep a faces in view that would ordinarily wink out at higher resolutions.

Some guess work would be needed for older models as most people who built models are no longer available to answer questions... and perhaps the example value I used above (HD) is not the best choice... perhaps 1920 would make more sense. The software makes no adjustments if someone has not bothered to put LODResolution() into the .s file.

Last thought: At first I thought this could be added as an option but thinking further I realized there are so many different ideas of what distance made sense when a model was made and that we all have models with those differences that a one size fits all would be unsatisfactory. The .sd file idea let's everyone examine and "fix" those few models they care about and let all of the "don't care" models wink out. It is also less work for end users than the 1 for 1 substitution idea I proposed some time ago as that would require several lines of data in the .sd file.

[wacampbell]

And don't forget about camera zoom. When you are zoomed in, you want the sim to use a more detailed LOD despite being far away.

Most of the commercial game engines factor camera zoom and screen resolution when determining what LOD to display.

[Aldarion]

never used lods in the last 8 years when modeling rolling stock. I figured that there was no point in having more than one modelin the same s file, and have the CPU load different shapes acording to distance. For me, makes more sense in a scenery object, but actually I never used LOD's with the scenery I create.

[Genma Saotome]

wacampbell, on 24 October 2022 - 04:10 AM, said:

And don't forget about camera zoom. When you are zoomed in, you want the sim to use a more detailed LOD despite being far away.

Most of the commercial game engines factor camera zoom and screen resolution when determining what LOD to display.

I never thought about that but it is a great observation!

[Genma Saotome]

Aldarion, on 24 October 2022 - 07:06 AM, said:

never used lods in the last 8 years when modeling rolling stock. I figured that there was no point in having more than one modelin the same s file, and have the CPU load different shapes acording to distance. For me, makes more sense in a scenery object, but actually I never used LOD's with the scenery I create.

Almost all of my models are of large structures, usually entire city blocks -- many city blocks. There are always a lot of polys because I won't make a simple cube. I also extend the view distances, often as far as 10,000m. Taking all of that into account it makes a lot of sense for me to use LODs in most models, especially as reducing the amount of data the CPU sends to the GPU is an important performance consideration.

I was satisfied with what I was doing until I changed monitors (2k to 4k) and started to notice things winking out -- not big, not closeup, but still obvious. The idea of changing the LOD values in so many models is for me a non-starter idea.

[PerryPlatypus]

wacampbell, on 24 October 2022 - 04:10 AM, said:

And don't forget about camera zoom. When you are zoomed in, you want the sim to use a more detailed LOD despite being far away.

Most of the commercial game engines factor camera zoom and screen resolution when determining what LOD to display.

This would be *extremely* desired, if possible to implement. :) (Is this already on the "roadmap" or list of desired features?) I can't tell you how many times I've tried to take "telephoto" screenshots in the sim and end up not just because of the LOD's.

[ErickC]

Aldarion, on 24 October 2022 - 07:06 AM, said:

never used lods in the last 8 years when modeling rolling stock. I figured that there was no point in having more than one modelin the same s file, and have the CPU load different shapes acording to distance. For me, makes more sense in a scenery object, but actually I never used LOD's with the scenery I create.

Oh, I ran some tests on a 110-car coal train and it made quite the difference for me - but maybe my system is more marginal than yours. :o

Anyway, I agree that the zoom needs to be factored in. MSFS uses a system where the LOD level is determined by the percentage an object takes up on-screen - I think there was some discussion of potentially implementing a similar system a few years back. We'd have to settle on what percentage corresponds to what distance for back-compatibility though...

[Genma Saotome]

ErickC, on 24 October 2022 - 03:04 PM, said:

Anyway, I agree that the zoom needs to be factored in. MSFS uses a system where the LOD level is determined by the percentage an object takes up on-screen - I think there was some discussion of potentially implementing a similar system a few years back. We'd have to settle on what percentage corresponds to what distance for back-compatibility though...

I was initially enthusiastic about Wayne's suggestion but as I thought about it I wondered how costly it might be to refactor every LOD in sight with each click of the zoom wheel whenever the camera setting is somewhere between normal and zoomed in (I'm pretty sure there is no need when the camera setting is between normal and zoomed out). This could be a performance issue.

It's never straightforward and easy, is it?

As for the old MSTS method... isn't that pretty much what GPU's now do when they cull pixels? I know that covers things behind foreground objects but doesn't it also apply to stuff that's smaller than 1 pixel?


Another possible consideration: Does it make any sense at all for the software to bother w/ LODs when the frame rate exceeds the refresh rate of the monitor? In that state there is no added value in reducing the amount of data being passed to the GPU. AFAIK LODs are only useful when things are going slower than desired and that is measurable in-game.

[eric from trainsim]

Aldarion, on 24 October 2022 - 07:06 AM, said:

never used lods in the last 8 years when modeling rolling stock. I figured that there was no point in having more than one modelin the same s file, and have the CPU load different shapes acording to distance. For me, makes more sense in a scenery object, but actually I never used LOD's with the scenery I create.

Same with me. I've set an unofficial 1000 poly limit for my models and it seems to work for me at least.

I do admit that the extreme detail in Dave's buildings constructed for his Goose Island and Loop are a new level of amazing.

[cjakeman]

Genma Saotome, on 23 October 2022 - 12:06 PM, said:

I think might be a fairly simple change for OR: Add 1 line to .sd files that says something about what screen resolution was used to set the original LOD's and then in the loader software have OR glance at the current monitors resolution and based on the difference between what is in the .sd file and what the computer is using, apply a factor to the LOD values in the .s file before passing it on to the game engine.

Yes, James reckons it will be fairly simple. I've approved Dave's Trello card (by moving it from the "Unsorted" column to the "1.X" column.

I've also raised a separate card for the Zoom calculation and approved that as well.