[scottb613]

Hi Folks,

Just a more generic question from a modeling point of view... Is there anything significantly different on how OR handles LOD's as opposed to the way MSTS handles them ??? Specifically - is there anything in OR that binds the various LOD models together ??? I'm sure many are familiar with the almost arcane steps necessary to keep models from exploding when LOD's are introduced in MSTS... I got spoiled creating content for MSFS which doesn't link anything between the LOD's... The LOD's can be either compiled in your modeling software or exported first then - added after... Everything I create for MSFS is exported in Direct X and formated via compilers outside the modeling software... The MSFS LOD's can have different groups - different textures - and - even completely different models... Is this possible in OR now - with the exception that we are short a compiler for the shape files - or - is there something native to the MSTS shape file format that necessitates following all the old rules once we move to OR ???

THANKS !!!
:jawdrop2:

Regards,
Scott

[James Ross]

Scott,

My understanding of the shape files is that, in principal, you could have each LOD being entirely different shapes, with different vertices, textures, surface options, lighting models, etc.. OR loads each LOD as a separate "model" in the game engine and simply flips between them at runtime based on distance.

Of course, you are (currently) still limited by having to use the MSTS shape format, which means that all the information for each LOD (including all the things I mentioned above) have to go inside a single file.

P.S. I'm not actually familiar with the arcane steps for LODs in MSTS, so do please mention specific issues if you care about them, and I'll try and explain how they relate to OR.

[scottb613]

Hi James,

Man - you guys are quick - thanks so much for responding...

It's been a while - but - the significant MSTS rules I can remember:

1) You cannot change the hierarchy of the model at all – if you have 60 groups defined in your modeling software – you need 60 groups defined in each and every LOD…

2) Each group must have the same exact textures defined – if a group uses two texture sheets – each group must still maintain those two texture sheets through every instance of the LOD… Typically – you can trim away all the faces you don’t want – but - just leave one remaining face that calls that texture sheet…

3) You can swap models as long as rule one and rule two are satisfied…

I’m probably missing something… When these rules are violated – the model just explodes in MSTS or Shape Viewer… The current exporter we use in 3DC doesn’t care about these rules and will export the shape just fine – the only time you know you have a problem is when the model is loaded into Shape Viewer or MSTS… Sometimes Shape Viewer will work but it will still explode in MSTS…

While it may not sound too bad – when modeling complex steam locomotives – it’s so easy to inadvertently violate a rule - which then forces you to spend a considerable amount of time back tracking to troubleshoot where you went wrong… It can be quite difficult… In addition – these rules force you to trim face by face – without the rules – it would make it sooo much easier – we could delete an entire group without worrying about the repercussions… Many people forego the use of LOD’s due to the complexity of creating them… When done intelligently – LOD’s significantly improve the overall performance of the sim – without those obvious transitions so prevalent in the early days of MSTS…

Regards,
Scott

[Genma Saotome]

The .s file format for LOD's is, AFAIK, very basic: Everything that is needed to be used to be show something at a specific LOD distance or less is referenced in that LOD section. The actual definitions are located at the start of the file as "global" data. At 50m the reference section may be small but by the time you get out to 2000m it includes everything. The "global" section, by definition, contains everything.

[James Ross]

 scottb613, on 15 May 2013 - 04:32 AM, said:

1) You cannot change the hierarchy of the model at all – if you have 60 groups defined in your modeling software – you need 60 groups defined in each and every LOD…

Ah yes, my old friend the hierarchy. I don't believe OR imposes this restriction directly, but the hierarchy data is global to the shape so it must be the same for each LOD. OR won't force you to use every element of the hierarchy in every LOD, though - but I guess you might have issues exporting shapes from existing tools in that case.

 scottb613, on 15 May 2013 - 04:32 AM, said:

2) Each group must have the same exact textures defined – if a group uses two texture sheets – each group must still maintain those two texture sheets through every instance of the LOD… Typically – you can trim away all the faces you don’t want – but - just leave one remaining face that calls that texture sheet…

I am sure that this one doesn't apply to OR; each LOD loads separately and, although the list of textures is global to the shape, only those referenced are loaded/used and any unused ones are ignored.

[Lindsayts]

Just a curious question, what would be a better way of doing this LOD thing. Currently because that everything is in the shape file it restricts how one can build objects, it simply being easier to not use LOD's. On my recent experiment on LOD distances I would say at least 2/3rds of the shapes I edited only had one LOD, so it would seem an easier method is required?

My impression is also not everything requires multiple LODS. Simple shapes such as trees, telepraph poles etc appearing not have enough separate pieces to display to effect the frame rate in a major way, where as some of the more recent high detail loco's particularly steamers can cause a significant drop in the frame rate.

Lindsay

[Genma Saotome]

IIRC mesh for each placed object to be seen in any given frame has to be sent to the GPU so from that one perspective I suspect any use of LOD's is advantageous by virtue of occasionally being able to send less data in any given frame. There may be a minimum quantity beyond which is no longer productive but I don't know what that might be. OTOH the use of LOD's does make the .s file larger and disk reads being slow the gratuitous use of LOD's could impair file loading performance by quite a bit.

I've no idea how to balance the two... and I'd sure like to know if there is a point at which a poly count is already as low as it needs to be (i.e., use of a LOD is a waste of effort)... what that point is.

[scottb613]

Morn'n Guys,

Thanks for all the information - I'll have to try some experiments with this...

I'm not sure how complex a model needs to be to start using LOD's but they sure do seem to help... Even with freight cars that are three of four thousand polys you really gain a benefit using LOD's... Shorter trains - you can probably get away without LOD's but once you start tacking on 45, 50 or more cars - you do start noticing the performance hit... I've been playing around with Derek's massive Mallet on the Feather River with 90 car trains... Big difference when pulling freight cars with LOD's from those without...

I've just come off a binge of modeling for MSFS - man - if only MSTS had come out after MSFS FS9 - everything is sooooo much better for developers in FS9... I'm not sure - but - I'm guessing some of the technology crosses over or is similar... If only we had "auto-gen" in MSTS - draw simple little squares on an image of a tile - and - "Autogen Annotator" populates houses, buildings, and foliage based on your specification... You can knock out and entire tile worth of scenery in a matter of minutes... LOL - if only...

One of the MSFS gurus created a tool where you can take a model file - and - it crunches the model through various algorithms based on about 20 different variable parameters to produce as many LOD’s as you want - in a matter of seconds… If you don’t like a LOD – it’s just a click to delete it and run it again… MSFS also supports creating the LOD’s in your modeling software as well… MSFS handles LOD’s a little differently though – in MSTS they are just based on a flat distance figure – in MSFS they are based on an objects size… If you have a large object and a small object both defined for LOD40 – the smaller object will transition well before the larger object… Actually – I think they are based on some computation of the number of pixels displayed on the screen to calculate the transition points… It kind of makes sense… We typically finish all models out with an empty LOD to conserve resources but I think the ranges at which objects are populated are much larger in MSFS… If at some point we could gain some of these tools/capabilities it would sure make a modeler's life easier...

As mentioned earlier – 3DC will export a shape – regardless of whether the rules I mentioned are followed or not… I’ll have to build some test subjects and see how OR handles them…

Thanks !!!
:clapping:

Regards,
Scott