Tool to automatically adjust LODs based on object size
#1
Posted 25 June 2018 - 10:03 AM
1) Copy all the shapes in a given folder, such as USA1/Shapes, into a temporary folder.
2) Uncompress all the shapes.
3) Calculate the size of each shape, and adjust the LODs. The end user can choose the number of pixels under which an object wouldn't be drawn, and the tool would calculate the LOD.
4) Recompress the shapes.
5) Save all the original shapes in another folder, perhaps USA1/Shapes/original going by the example above.
5) Copy the new shape files into the original folder, overwriting the old ones.
6) Delete the temporary folder.
A nice optional feature if it doesn't entail too much extra work would be to put all the original shapes into a .zip folder instead of saving them individually. This would save potentially having hundreds of thousands of extra files.
Any thoughts? Anyone here able and willing to tackle a project like this? I obviously don't have the programming skills to tackle something like this or I would attempt it myself.
#2
Posted 25 June 2018 - 11:16 AM
A different solution (one I prefer) could be the addition of a MaxDisplay() in the .sd file. Let OR assume the value is 2000m if that parameter is missing; It it is present use whatever distance it specifies, short or far.
Both of these are likely far easier to implement.
#3
Posted 25 June 2018 - 11:57 AM
Genma Saotome, on 25 June 2018 - 11:16 AM, said:
A different solution (one I prefer) could be the addition of a MaxDisplay() in the .sd file. Let OR assume the value is 2000m if that parameter is missing; It it is present use whatever distance it specifies, short or far.
Both of these are likely far easier to implement.
Those are all great ideas. Yes, having OR evaluate the bounding box is a pretty good idea. I wonder if this would be all that expensive from a computational point of view (as the CPU would be doing it as opposed to the GPU)?
#4
Posted 25 June 2018 - 06:53 PM
#5
Posted 25 June 2018 - 09:24 PM
jtr1962, on 25 June 2018 - 11:57 AM, said:
It could be done in the loader thread. The Render/game loop is already over burdened.
The problem w/ trying to apply a LOD to individual faces is what do you do when the small face is actually an integral part of a larger surface? The parallel faces that make up a pipe are individually narrow but in total represent a much larger shape. Anything that represents a curved surface would be improperly LOD'd.
#6
Posted 26 June 2018 - 12:27 AM
Genma Saotome, on 25 June 2018 - 09:24 PM, said:
What are you t...a...l...k...i...n...g about? The load seems p..u...r...e..l...y... nominal to m...e...! So long as you look a...w...a...y... for five seconds every m...i...n...u...t...e... or so!
;)
The way that you create your LODs has a lot to do with the end result. You can avoid a lot of the problems with curved surfaces with a little planning and careful vertex welding, but it does take some work, and you have to set the distances so that the changes occur on a model that is small enough on-screen for the reduction to be more or less invisible. A secondary problem is that OR follows the MSTS convention of relying on distance instead of size on screen (which is what MSFS does). LODs in MSTS/OR only really work when the zoom is within a nominal amount. Anything beyond that, and you'll see the change. It's a balancing act.
#7
Posted 26 June 2018 - 07:16 AM
ErickC, on 25 June 2018 - 06:53 PM, said:
From my research into the issue the problem is more one of draw calls than drawing triangles. Modern GPUs can draw billions of triangles per second. Because of this, I'm not sure it makes sense to have multiple LODs for an object (except maybe on very complex objects which appear multiple times in a scene, such as rolling stock). Rather, just have one LOD which basically decides whether or not the object is drawn at all. Of course, we could probably do this in the .sd file just by looking at the size of the bounding box. I also like the idea of a MaxDisplay() line in the .sd file, although that runs into the same issue as adjusting the LODs in the shape file, namely that the end user has to go through thousands of files, unless a utility could be made to automatically add the MaxDisplay() line.
#8
Posted 26 June 2018 - 08:09 AM
WRT where does the shape become invisible... yeah, it largely depends on screen resolution. IIRC I calculated 1 inch of face surface becomes 1 pixel at 125m when viewed at 1920x1200 (or 1080) resolution. From that it becomes a judgement issue of whether you set the LOD for any face based on that... or some lesser distance. For example, I'll do a much shorter LOD when the face is at a peculiar angle not well suited for normal viewing and/or the object itself is placed well into the background off to the side where the winking might not be noticed. But up close to where the camera -- and your eye -- normally goes? I'll follow that 1" to 125m rule.
#9
Posted 26 June 2018 - 10:52 AM
jtr1962, on 25 June 2018 - 10:03 AM, said:
If you just want to scale the LODs such that the object disappears when smaller than N pixels on your screen, we can pretty easily do that inside OR I believe because:
- We know the screen resolution being used
- We know the size of the object (bounding box, view sphere, and actual graphical data)
- You could set the smallest size you care about (N pixels)
- Shapes include a distance with every LOD including the last (which is when the object disappears normally), so we'd scale them all so the last one matches the calculated distance
One wrinkle is that the last LOD may well be set to 2000 in many objects purely because of MSTS, not because it was the right distance relative to the others; for those cases, we could take Dave's suggestion of MaxDisplay() in the .sd file and have it override that final LOD distance before Open Rails starts scaling it all (this means that it is just substituting for editing the shape file itself, not providing any extra functionality).
All this would be done in the loader and sounds like it'd be a trivial amount of work for the CPU, as we're just doing some very basic maths and adjusting the LODs. Once adjusted, the LODs would be static and control the rendering as normal.
#10
Posted 26 June 2018 - 11:18 AM
James Ross, on 26 June 2018 - 10:52 AM, said:
- We know the screen resolution being used
- We know the size of the object (bounding box, view sphere, and actual graphical data)
- You could set the smallest size you care about (N pixels)
- Shapes include a distance with every LOD including the last (which is when the object disappears normally), so we'd scale them all so the last one matches the calculated distance
One wrinkle is that the last LOD may well be set to 2000 in many objects purely because of MSTS, not because it was the right distance relative to the others; for those cases, we could take Dave's suggestion of MaxDisplay() in the .sd file and have it override that final LOD distance before Open Rails starts scaling it all (this means that it is just substituting for editing the shape file itself, not providing any extra functionality).
All this would be done in the loader and sounds like it'd be a trivial amount of work for the CPU, as we're just doing some very basic maths and adjusting the LODs. Once adjusted, the LODs would be static and control the rendering as normal.
Thanks for the explanation. I'm leaning more and more in the direction of having OR do this, rather than altering a bunch of files. It does sound like a trivial amount of work for the CPU.