LOD limits feature: what are the criteria?

[MSFS 2020] Questions & Community Discussions Airports & Sceneries
1

Hello MS/Asobo. First of all, thk you for your last update. I have a question
regarding the SDK limits LOD feature, which seems to enable the future LOD
management system. I tested it on one of my scenery (Tours), and the LODS that
does not display seem to be quite erratic. Here are some screenshot to
illustrate it: Current LOD management (scenery works as intended, except for
snow coverage):

2560Ă—1440 1.43 MB
Future LOD
management (tiles disappear, but not the ones i would expect);
2560Ă—1440 1.44 MB
To better illustrate, here are
the same in wireframe representation: Current LOD management (scenery works as
intended, except for snow coverage):
2560Ă—1440 1.81 MB
Future LOD management (tiles
disappear, but not the ones i would expect);
2560Ă—1440 1.85 MB
For both LOD management
features, snow covering does not work properly. So, i wonder what criteria are
taken into account in the future LOD management system to not display an
object. What should i take into avccount in the statistics profiler window to
know exactly what i can change on my object LODS to fix it. Also, to complete
those informations, here is an example of a 3-LODs tile:

      1. xml version="1.0"?>
  2.  guid="{aca9755f-1f5c-4495-b65a-663eb142d044}" version="1.1">
  3.   
  4.      MinSize="50" ModelFile="30604042607170725_LOD00.gltf" />
  5.      MinSize="15" ModelFile="30604042607170725_LOD01.gltf" />
  6.      MinSize="0" ModelFile="30604042607170725_LOD02.gltf" />
  7.   
  8.

The scenery also uses some more detailed tiles, which are 4-LODs tiles:

      1. xml version="1.0"?>
  2.  guid="{19b86587-d0aa-4a0b-957a-8c7031a3d923}" version="1.1">
  3.   
  4.      MinSize="70" ModelFile="30604042607353517_LOD00.gltf" />
  5.      MinSize="50" ModelFile="30604042607353517_LOD01.gltf" />
  6.      MinSize="15" ModelFile="30604042607353517_LOD02.gltf" />
  7.      MinSize="0" ModelFile="30604042607353517_LOD03.gltf" />
  8.   
  9.

By advance, thks, Best regards

2

OK, will read the
https://docs.flightsimulator.com/html/Asset_Creation/3D_Models/LoDs.htm#h1

3

The hardcoded LOD requirements will force a major redesign of most LODs in an
aircraft. It would be fine if those were implemented early on, but as a
developer with a ton of models in the currently distributed products and
several in developement using the “old” guidelines, this is a major setback
for our schedule. These limits should really be relaxed a lot more or give us
an option to override them somehow, per-LOD. Hardcoding the bottom two LODs
makes sense, but limiting the LODs in the higher tiers is very problematic.
What happens if someone makes a plane whose engine is exposed and visible?
I’ll take the Stearman, Airco DH-2, B-314, B-247, B-29 or the likes of
Aeroplane Heaven’s Spitfires. Most of these models may not show up in external
view before LOD2 or 3, rendering all the fine detail work useless. I believe
the best course of action would be to:

  • Hardcode the lower two LOD limitations
  • Switch MIPs sooner to preserve texture memory
  • Give clear guidelines to developers so they can reduce their drawcalls efficiently and let them handle the LODs.
4

After studying this on our models with the tools in the simulator, I’d have to
agree with Alex. This seems far, far too restrictive for the exterior views on
smaller aircraft, which are much more likely to have many small details on the
screen at once. The restrictions on the exterior model come into play at
distances where it will be very noticeable if smaller or fine detail is
reduced. A large aircraft may have more vertices in total, but to fill your
screen with the aircraft requires a more distant level of zoom, at which the
smaller details can be more easily culled in order to provide a smaller LOD.

5

I also agree with Alex and Jim… It makes no sense culling so hard on LOD 0 to
LOD2, I get this is necessary to keep performance when multiplayer and AI
traffic is around, but these objects would generally always showing at LOD3 to
LOD5 already where the culling makes sense and where the harsh low drawcalls
are required ir order to avoid overloading the sim due to many objects being
presented in the screen. However for the user flyable aircraft, high level of
details are always desired. This is what customers want to see… This new
algorithm requires fine tuning, it makes sense for AI traffic, multiplayer,
animals, environment, etc. but not for the user flyable aircraft. Please
remember when 3rd party developers are creating a flyable user aircraft they
don’t necessarily want it to be used for AI traffic or multiplayer purposes,
there are specific AI traffic models for this purpose which are designed and
developed from the beginning with low polys since the intention is to never
been flown by the user. It would be bad to asume for example, that PMDG 737,
FWB A320, etc. should be used as a passive / AI traffic in the simulator,
these are high end models intended for high details and according they should
be skipped by the base sim to be rendered for multiplayer purposes. This is
the reason why other platforms (FSX, P3D, etc.) had an option inside the
aircraft where the developer could specify if this model could be used for
passive / AI traffict. Lastly but not less important, using vertex numbers for
the culling is very confusing… it is a stat most 3rd party designers never
use, the standard count for any 3D model designer is number of polys or
trigs… not numbers of vertex… this move makes it more difficult for the
entire 3rd party developer community to understand what needs to be done to
avoid objects disappearing for our customers. In addition the current
numbers are very tight and limiting, each year customers demand more and more
detail from 3rd party developers, NOT LESS, we want to see a platform
capable of fulfill our customers demands, not the contrary… so I think these
limits needs to be reviewed and raised by 30% to 40% and instead implement
what I explained above, if we want to develop an Aircraft / object that is
intended for high fidelity and quality we can simply set the flag this object
should not be rendered for passive / AI traffic / multiplayer purposes and
proceed to implement the level of detail required. In the other hand if we are
developing an aircraft / object intended for multiplayer / AI purposes such as
the Reno air races, then we don’t put the flag and we have to obey the LOD
limits and enforcement as intended. Kind Regards, Simbol

6

@OptimalCoyote89 FYI

7

Regarding AI Model development we at AIG can provide experience. Our
developers (in hoouse and 3rd party) have years of try and error when it comes
to best performance vs visuals on AI models. With our current Test setup (mix
of glTF and MDLX Ai models) we can still achive high FPS even at major
airports. My system is able to keep 60 FPS locked on ULTRA

8

Let me make a suggestion as well on it

  1. Take the “Air Traffic” flag out of aircraft.cfg
  2. Planes that are to be used in MP/AI should have an AI.cfg. If they aren’t then the nearest type of aircraft is picked from the AI-capable ones (default or add on)
  3. That AI.cfg should have its own “model=” entries to point to a folder with AI models
  4. If it is for a flyable model, the AI.cfg should have aliases to the [FLTSIM.X] entry of aircraft.cfg so as to be aliased to that livery of the flyable aircraft
  5. Enforce LOD limits for the AI models only

This way:

  • Developers of AI aircraft have their own set of rules to work with
  • Developers of flyable planes who don’t care about MP/AI do not do LODs at all. These guys will see their King Air B200 being aliased to the default 350i
  • Developers who do flyables and want MP/AI can do a simplified model with condensed textures and special care. This is much easier than downgrading a high-res aircraft as you are not always able to reduce polies/vertices easily with these. Therefore you can do a simpler, AI model that has half the textures or less and start with an AI LOD0 that’s already 30% of the flyable model’s.
9

To see what happens, I recommend to enable the LOD text display and filter
your model. Then, enable the current/max vertex count display, and you will
see exactly when and why your model switches LODs earlier (i.e. when it goes
over the maximum). This max vtx count display can also be used without
enabling the new LOD limits system, and it will show the model lod text in red
if they would switch to a lower-res LOD under the new system.

10

Thanks. For you, is this a concern for user-controlled aircraft only, or also
for airtraffic of those airplanes?

11

By the way, if your model disappears completely, it means your last LOD is
over the limits, and there is no lower-resolution LOD available to display the
model with.

12

Thank you for your feedback. I hear you! Let me be clear on a few things, as I
have the impression these did not really sink in:

  • LOD0 is forced for the user airplane, so for this purpose you don’t need to care about LODs. LODs are only for non-user aircraft.
  • LOD streaming makes it so that you do not need to create separate aircraft for AI. The benefit is that your plane will look amazing in a close-up, even when it is just airtraffic.
  • We chose vertex counts over triangle counts for two reasons:
    • Vertex counts are a more accurate representation of (GPU) memory cost, which is the main concern.
    • Vertex count limits benefit high-detail models: typically, the more triangles a surface has, the more vertices can be shared.
  • The model LOD limits system won’t be activated until several months from now.
    • Models exported before the system is activated won’t be limited.
  • If a non-user model LOD exceeds the vertex limits, it will increase the minSize of that LOD until it falls within the limits, so you will see a lower resolution LOD in its place until that minSize **** is reached. The model is culled completely only if there is no lower resolution LOD available at all.

As such, you can set appropriate minSizes for airtraffic and not care about
the user airplane. For example, a 500k vertex LOD0 allows a minSize down to
~155%. This is roughly the minSize of our LOD0 models. That being said, I love
the open engine example. Do you believe that the limits are too restricting
for airtraffic aircraft with that amount of detail? Some direct replies:
@SWS-AlexVletsas > Switch MIPs sooner to
preserve texture memory

  • We already load a mip less for airtraffic. We did think about loading and unloading mips dynamically, but that requires significant development work.

Give clear guidelines to developers so they can reduce their drawcalls
efficiently and let them handle the LODs.

  • These lod limits are a reflection of the guidelines.

That AI.cfg should have its own “model=” entries to point to a folder with
AI models

  • You can already create a separate variations for airtraffic, but I don’t know how the selection for airtraffic models works. Making the regular FLTSIM.X entry reference the airtraffic variant seems like a good solution to me, the rest shouldn’t need any changes. @FlyingRaccoon

@Simbol > This new algorithm requires fine tuning,
it makes sense for AI traffic, multiplayer, animals, environment, etc. but not
for the user flyable aircraft.

  • You don’t have to care about it for the user airplane, as we force LOD0 anyway!

other platforms (FSX, P3D, etc.) had an option inside the aircraft where the
developer could specify if this model could be used for passive / AI traffic

  • So, we have this too, the “isAirtraffic” option in the [fltsim.x] section.
13

@OptimalCoyote89 the main problem with the
LOD limits as they stand is that many developers have to go back and redo
their scenery and freeze new developements. That means they are doing this at
a cost as old scenery doesn’t sell and this could have wide-ranging
consequences for them, their products and their customers. For MP/AI aircraft,
I think it actually works well as long as the AI/MP aircraft have an ai.cfg
that’s equivalent to the aircraft.cfg in terms of functionality. My
suggestions, a bit more analytically:

  • Regular aircraft: all models/liveries are referenced from aircraft.cfg and apply to the user’s ownship
  • AI/MP aircraft: models/liveries are referenced from ai.cfg (same format as aircraft.cfg). Any redundant information is skipped. So essentially you’d add a model, sound and texture line to ai.cfg
  • Planes that don’t have an AI.cfg will not be visible in MP or as AI and aliased to the most relevant compatible aircraft (Turbopro>Twin Engine>Manufacturer>Model)

This way AI developers have less work to do in their flight model and
aircraft.cfg. Flyable aircraft devs can skip the extra work completely OR do
lower res versions of their aircraft to facilitate MP & AI. Regarding the open
engine, it was not uncommon in Prepar3D & FSX to have aircraft that one could
walk around and open panels to expose internal details. This would often be
done in Multiplayer, or AI aircraft could be set up so as to appear in a
maintenance state. Care should be taken to not go “overkill” in such cases,
but this kind of insane detail happened in the past and will happen again.
Wing42’s Vega for FSX is one such example which is finding its way into MSFS.

14

Hi
@OptimalCoyote89
, Thanks for the further clarifications. So what happens if we go above the
recommended limits for LOD0? just to expand on this, it is also a bit related
to your open engine example among other similar things that requires more
verts for details upon user demands. Very large flyable objects with open
engines will have multiple hoses, pipes, etc. which with low poly / trigs /
verts looks really bad… and you are forced to apply via 3DS either Turbo
smooth on these parts or NURMS divisions curves applied. Both of course
increases the number of vert considerable. Just for example, a simple Rotax
912S engine optimized enough to the point the pipes will start to deform
further if you continue, can reach up to 171,000 verts… that is just the
engine… it is missing the battery, battery cables, water container, oil
container, oil hoses, etc. you get my drift…

1179Ă—573 139 KB
Many users like to remove the
cowl on small airplanes and see these engines types, similarly with airlines
and private jets, and not only the engines, sometimes the cargo area, baggage
load area, kitchen area cabinets, toilets, etc. for FSX / P3D it was very
common to see users being able to remove the engines cover and inspect things
inside among many other parts of the aircraft… specially when 3rd party
developers were offering packages of aircraft that had multiple types of
engines, for example Prat and Whitney vs Rolls Royce engines… These are the
kind of things people are missing from MSFS and that of course want to see
under MSFS since the overall impression is that MSFS is better than the old
engine platforms and therefore it should be able to handle everything much
better and have actually more DETAILS than their pre-successors. This is one
of the reasons why I consider the current Poly count / Verts count for flyable
user aircraft really tight… we can’t push the platform as hard as we
should be able like this. Regarding AI / passive traffic, most 3rd party
developers doing high quality aircraft with features as I explain above, have
ZERO intentions for their models to be used as an AI traffic. This has been
the culture since FSX / P3D days for over 2 decades now… so when PMDG,
FSLABS, FSW, etc. are building their big airlines they are trying to please
the demand of the flyable user and not even considering this being rendered
for multiplayer purposes, more over most of the time, such aircraft will have
custom WASM modules, custom services, etc. to complement specific areas of the
flying model which of course is fine for an object being used once… and soon
as it is loaded multiple times (for example to render for example 60 PMDG 737
in an airport) all of them loading these modules, etc. well the results are
going to be pretty bad… It is good to see you guys have a flag for AI, but
my advise would be to never asume a flyable aircraft should be used for
passive / AI traffic unless the developer specifically set this flag as
“TRUE”… there are very specific products out there 100% designed for passive
traffic and those are the key ones that will come to the market (AIGM-OCI is
an example) perfectly optimized for this purpose. My point being is, if the
effort on these algorithms to cull LODs etc, is being made to optimize content
in the community folder so it can be used as passive traffic, it is a waste of
time, simply put most developers are not creating objects for this purpose
since the main objective is another… they want to fulfill their customers
desire to see high quality details when they fly their aircraft… Thanks for
your time to explain further and address our concerns. Regards, Simbol

15

we should discuss this in comments or on the side, this is not an answer to
the orignal question (nor is mine actually, in hindsight… though it answers
the extra questions asked) As for already released products, we will find a
way to avoid having to do this for already released products, and only force
this for new exports, like with the pink textures. Of course, if an update to
a package is made, it will be necessary to fix the issues (but only if
exported after the feature is enabled, which will still take a few months).
The LOD limits are not culling LODs completely; they are simple adapting the
minSize property such that the model falls within the limits. If you already
have reasonable LODs, you will not see a big change. Only if you have some bad
LODs that fall far outside the limits will you really notice the difference
(as I suspect is the case in the original question). I don’t see a significant
enough advantage to your suggestions to the configuration setup to warrant
some changes. What you suggest is a different way to do what is already
possible. I believe reuse/consistency is more important: the less to learn,
the better. For the open engine and similar issues, I would like to introduce
an attachment system with independent LODs. I am not yet sure if and how this
will fit into aircraft model limits, or if they will have their own model LOD
limits, or something else. I’ve updated my original post with the extra
information.

16

Just have to say that a simple way to adapt the LODs would be to add an
aditionnal LOD with very few vertices, as the last LOD in the list. The
problem is, if we have a look at the statistics profiler, even some airports
included in the sim suffer from two many drawcalls and vertices in the last,
or before the last LOD.

17

Yes, in your case just an appropriate last LOD is probably what was missing,
as per the documentation. And indeed, many of our own models also have bad
some LODs and need to be optimized.

18

This is one of the reasons why I consider the current Poly count / Verts
count for flyable user aircraft really tight… You seem to have missed
the part where I said the limits do not apply to the user aircraft, because
it’s forced to LOD0? Or are you worried about something I did not mention?
And similarly, I mentioned you have the option to opt out of airtraffic. Per
default this is already set to false if it the option is not present in the
aircraft.cfg.

19

I don’t think the LODs are bad. If you take a look at those models, you will
see that they are tiles that cover a wide area. So the minsize are correctly
adjusted according to this. Only the max LODs use a lot of vertices and
drawcalls, but it is because of their nature. Decimate them could produce bad
results (many holes and distorsion). A target LOD file for the future LOD
management system would look like this (for a current 3-LODs tile):

having a 30604042607170725_LOD03.gltf that uses 24 vertices (in fact, it is
the bounding box of the tile), knowing that the last MinSize value will be
overriden by the engine. Also, consider that my projects are very specific,
and i think that the wider perimeter (isolate scenery models, airports,
aicraft models, etc…) is not covered by my example.

20

I see, thanks I am a bit confused since I thought when the user zoomed out…
the LODs enforcement would also apply for PC and XBOX causing the flyable
aircraft to disapear eventually. So saying this will never happen? Thanks for
letting me know the AI is disabled by default, good move. Regards, Simbol