MSFS24 MSFS 2024 LODs

[rhumbaflappy]

I thought it might help to have a thread specifically dealing with MSFS 2024 LODs. At this date, Asobo seems to be indicating they may change the LOD rules a bit, so we might need updates to any ideas here if that occurs.

To start, the sim allows up to 150 vertices for the smallest LOD of 0.5% (LOD minSize="0.5"). You can specify LOD minSize="0.0", but it will be treated as 0.5%. I made a test of cubes of different sizes to see how far away the sim will let them be visible. I uses a single LOD minSize="0.0" , triangulated, with a vertex count of 24 (well under the 150 vertex limit). The objects are vertex color only, meaning no textures used. I unchecked the 30km limit, but that wouldn't be needed for most objects.

Distances visible:
2x2x2 meter object~435 meters distance until the object disappears.
5m~1090
10m~2180
25m~5450
50m~10900
100m~21800
250m~ 54500
The visiblity distances are linear, and can be interpolated to the size of any object's bounding sphere. So your final LOD should aim for 150 vertices or less, with an LOD minSize="0.5"

I had thought the sim counted vertices in an odd way. They are not the same as Blender would display. A triangulated cube has 8 vertices, confirmed by Blender:

Perhaps they take the number of triangulated faces and multiply by 2? At any rate, it is not vertices. I'll test that in a new post.

Another post could deal with the LOD progression. LOD1 actually should be 25% the vertex count of LOD0. But does this mean the actual vertex count as shown in Blender, or the the sim's odd vertex count ( 2x the triangulated faces)? Each LOD progression would then be 25% less 'vertices' until under the 150 LOD limit for the smallest LOD? And is it really 25% as a recent Asobo admission, or is it 50% as the SDK states?

 

[rhumbaflappy]

Why are the number of my vertices not matching between MSFS and my Blender file? The actual explanation is here: https://blender.stackexchange.com/q...as-twice-the-vertices-it-should/167383#167383 The best way to find the actual number of vertices in the glTF might be to import the glTF to Blender. The imported number will likely be significantly larger than what was displayed by the loaded .blend file. It's the way a glTF is created.

ModelConverterX shows the correct number of vertices used in the sim for each LOD. I am not aware of any app that will compute the glTF number from the original .blend number, but MCX will give the actual number for each LOD in your model. This may help you figure out the right LOD minimums.

Microsoft's 3Dviewer also shows the correct glTF vertices (or a number close to it):

If you MSFS-export the model with all it's LODs, you can then import all the LODs (rather than load the .blend), and then save that as a new .blend, then that new .blend will have the correct statistics for use with MSFS (glTF statistics).
Between all these methods, there seems to be a difference of a couple of verts or so. You can also look at the glTF in a text program. Search for count, and you should get a number used by the sim.

 

[TBryson2]

I'm having an issue where the MinSize does not change IN MSFS (see images) even when I have valid LOD's and the MinSize has been set to specific values in the xml file. For my model, I have the MinSizes set for each LOD as 120, 50 and 0. I export the model, the model updates in the Project Editor and the MinSizes are updated in the xml file. BUT when I move in / out on MSFS, the "MinSize" displayed is ALWAYS at 29.70 and the LOD stays at LOD 0 of 2.

I have an (almost) identical model next to this one, and the MinSize correctly displays (on the "debug LOD's) and changes properly for that specific LOD. There is virtually NO difference in the individual xml files except for the GUIDs and model names.

I have noticed this with several other models, that the MinSize (as displayed on the Debug LOD's) is ALWAYS set to a specific value and never changes.

What am I overlooking? Or is this a bug? I'm pretty sure I exported both models (working and not working) with the same parameters.

Thanks!

TB2

UPDATE!!! I just rebuilt my project and closed it, and now the LOD's work for that building! Not sure why they were not working while in Project Manager, but they weren't! Decided to leave this post up here in case anyone else ran into this issue.

 

[rhumbaflappy]

UPDATE!!! I just rebuilt my project and closed it, and now the LOD's work for that building! Not sure why they were not working while in Project Manager, but they weren't! Decided to leave this post up here in case anyone else ran into this issue.

Another LOD mystery. I'm thinking that was caused by the Devmode somehow.
The sim overrides all LODs we make. The best course is to let the sim tell you what it wants, and rewrite the xml accordingly. Also, your graphics settings will be part of the sim's LOD computation. The SDK chart tells us we could have an object of 250000 vertices. with a graphic setting of High, it will produce a minSize of 100, With a graphic setting of Low, the minSize will be set at 400. Coming from FSX, we had control over when a shape or LOD appears. This isn't true any more. Due to streaming of the sim, and XBox use, the sim now decides what LOD it will use. My guess is to design for High settings, and let the sim do what it wants.

 

[rhumbaflappy]

A twist on LODs is making a SimPropContainer object from your creation. A good example is one of the SimPropContainer oil rigs. Amazing detail and few no FPS problems.

Attached is a test I made. Setting up the folders and package definition can be convoluted in MSFS 2024. Attached is a package with correct folders and files and definition. You can use it as a template to setup your own SimPropContainers.

SimPropContainers can be made up of Library objects, SimObjects, and other SimPropContainers. The DevMode has it's own editor for them. Just right-click on the container to have their editor available. Using the Object menu allows you to select objects. You can dragthem around in the Devmode window to place them. Their placement then becomes part of the SimPropContainer. Back in the Scenery Editor, you can then select your SimPropContainer and place that collection where you'd like.

You make the SimPropContainer, compile the package, reload the package, then you can place the container. All the sub-objects have their own LODs, animations, etc... This works well if you have, for example, a dozen roof vents on your terminal. You can use a premade vent from Asobo, and add them to the right locations in the SimPropContainer. Their LODs are already computed, so you don't need to mess with that. Lots of "props" can be added to a base object, without worrying about how to deal with their LODs. Could be a big time saver.

 

[V-Pilot]

Another LOD mystery. I'm thinking that was caused by the Devmode somehow.
The sim overrides all LODs we make. The best course is to let the sim tell you what it wants, and rewrite the xml accordingly. Also, your graphics settings will be part of the sim's LOD computation. The SDK chart tells us we could have an object of 250000 vertices. with a graphic setting of High, it will produce a minSize of 100, With a graphic setting of Low, the minSize will be set at 400. Coming from FSX, we had control over when a shape or LOD appears. This isn't true any more. Due to streaming of the sim, and XBox use, the sim now decides what LOD it will use. My guess is to design for High settings, and let the sim do what it wants.

In theory, if we assign this distances to an object to its minimum, the sim will switch LODs when it wants regardless of the user graphic settings. For example

LOD0 = 5
LOD1 = 4
LOD2 = 3
LOD3 = 2
LOD4 = 1
LOD5 = 0.5

 

[droide]

I created around 100 sceneries in MSFS2020, with several hundreds of 3D objects. So for me it was not an option to convert everything to the new LOD system.
Also, with proper PC, i did not ever experience an performance issue that would encourage me to be so vertices-restrictive like the MSFS2024 LOD system does.

I found a solution that suits me, inspired by Frederico's video

1. I make a copy of my original FS2020 scenery.
2. I edit the objects.xml file manually (in PackageSources\scene) to remove everything
3. I create a brand new projet in MSFS2024 with MSFS2024 Sdk
4. I edit the scenery in MSFS2024 Sdk, using 3D assets from this copied MSFS2020 version of the scenery.

in other words, i reduce my original MSFS2020 scenery to some sort of 3D objects library, but edit a new scenery, calling these assets from the library in MSFS2024.

i found this solution more convenient than editing in MSFS2020 the patches needed for MSFS2024 compatibility, because if you use MSFS2020 SDK you do not have the exact same terrain and satellite photography placement.
So it is better to edit in MSFS2024 to make sure the 3D objects will be placed accordingly with the new satellite and terrain information.

This solution also means that, if you have to make a complete new scenery, and you want to stay with you MSFS2020 habits (no LOD, same toolchain) for your 3D objects, you could do the same : use a MSFS2020 project as a sort of objects library, and edit your scenery in MSFS2024 SDK calling these objects.

Hope this could help some of you.

 

[pinkjr]

LODs are not that hard if you already made them for 2020. Just convert from pixels to % screen height on the XML. Then fine tune using LOD debug tool of SDK (but don't build!).

Don't recommend using the 2024 SDK to build a 2020 scenery if you have animated sim objects....it will destroy them. I typically modify on 2020 until I get the results I want on 2024 (example....light intensity)

 

[Christian Bahr]

LODs are not that hard if you already made them for 2020. Just convert from pixels to % screen height on the XML. Then fine tune using LOD debug tool of SDK (but don't build!).

It's not that simple. In 2022, I created an add-on in which all models had a functional and well-balanced LOD system. It was programmed for MSFS at the time.
In MSFS24, it turned out that the individual LOD models were almost completely unusable and some had to be recreated, and the LOD values had to be recalculated.

Simply put, that took a lot of time and, of course, a lot of nerves. Just read through the forum ;-)

After a long wait, SU3 was released yesterday. For me, and with regard to the LOD system, it was a major breakthrough. While smaller objects like ground signs at an airport still fade out relatively early, it's not quite as noticeable as before the update. And that's the best news for me: the new LOD system (LOD curve) now works really well again. Almost like in MSFS. For me, SU3 with the new LOD system is a real win!
It was definitely worth it for Microsoft/Asobo to conduct additional beta testing. Kudos to all the beta testers involved!

 

[TBryson2]

Great! (sarcastically). That means I have to go back and test everything again. LOL!!! But, if we want good products we do what we can.

TB2

 

[Christian Bahr]

There are testers for that. So you don't have to test anything yourself.
Maybe it's enough to randomly test two or three of your add-ons.
Then you'll immediately see that the new LOD system is a good one.
Have you already looked at any of your MSFS24 add-ons?

 

[TBryson2]

I'm getting ready to look into it. I don't know what you mean by "there are testers for that", but what I do is launch project editor (with my project of course), Debug LOD's, filter out just the name of my model(s), "shrink" down the "Scenery Editor" window to remove all of the clutter , move in / out of the model and see where the LOD changes.

So far, the LOD system works well with my models, but there are a few that I'll have to tweak. (LOD 0 is happening WAY too far away!) This particular building is extremely involved, and it's possible I used a "cheater block" (don't know what else to call it, an oversized transparent block so the LOD"s worked out originally.) I'm pretty sure I used them on a couple on my models. (Which I was never impressed with, but it forced it to work).

I'll play with it today if I get the chance and report back.

TB2

 

[pinkjr]

It's not that simple. In 2022, I created an add-on in which all models had a functional and well-balanced LOD system. It was programmed for MSFS at the time.
In MSFS24, it turned out that the individual LOD models were almost completely unusable and some had to be recreated, and the LOD values had to be recalculated.

Simply put, that took a lot of time and, of course, a lot of nerves. Just read through the forum ;-)

After a long wait, SU3 was released yesterday. For me, and with regard to the LOD system, it was a major breakthrough. While smaller objects like ground signs at an airport still fade out relatively early, it's not quite as noticeable as before the update. And that's the best news for me: the new LOD system (LOD curve) now works really well again. Almost like in MSFS. For me, SU3 with the new LOD system is a real win!
It was definitely worth it for Microsoft/Asobo to conduct additional beta testing. Kudos to all the beta testers involved!

I tried using several tools, and ended up just diceminating models manually in blender to match the target triangles, but only for very large models (terminals). For medium/small complexity items, just changing from pixels to % and testing with SDK was fine.

 

[Christian Bahr]

I don't know what you mean by "there are testers for that", but what I do is launch project editor (with my project of course), Debug LOD's, filter out just the name of my model(s), "shrink" down the "Scenery Editor" window to remove all of the clutter , move in / out of the model and see where the LOD changes.

That was a stupid sentence from me, sorry.

So far, the LOD system works well with my models, but there are a few that I'll have to tweak. (LOD 0 is happening WAY too far away!) This particular building is extremely involved, and it's possible I used a "cheater block" (don't know what else to call it, an oversized transparent block so the LOD"s worked out originally.) I'm pretty sure I used them on a couple on my models. (Which I was never impressed with, but it forced it to work).

Yes, most people know what that means. This trick existed back in the FSX days, as far as I can remember. It still works in MSFS/MSFS24. It's not really recommended anymore; Microsoft/Asobo explicitly state that they also check for such tricks when placing add-ons in the marketplace. So, if someone plans to place their add-ons in the marketplace, they really have to equip all their models with an LOD system.

 

[Christian Bahr]

I tried using several tools, and ended up just diceminating models manually in blender to match the target triangles, but only for very large models (terminals). For medium/small complexity items, just changing from pixels to % and testing with SDK was fine.

Yes, unfortunately, it's a lot of work. Sometimes there are scripts that can reduce the vertices of multiple models in batch processing. Unfortunately, I don't know how this works in Blender.
In 3D Studio Max, there are two modifiers for this: MultiRes and ProOptimizer. Depending on the model type, animated skin/mesh or static model, I use one or the other.

With MultiRes, you can directly enter the desired number of vertice. I have been working with MultiRes for about a year. With ProOptimize for about 12 years; it has more options, so you have to play around with it a bit. Both modifiers work reliably and surprisingly well.

 

[Azrsim]

LODs are not that hard if you already made them for 2020. Just convert from pixels to % screen height on the XML. Then fine tune using LOD debug tool of SDK (but don't build!).

Don't recommend using the 2024 SDK to build a 2020 scenery if you have animated sim objects....it will destroy them. I typically modify on 2020 until I get the results I want on 2024 (example....light intensity)

On international terminals it's a bit difficult

 

[Azrsim]

I use Exact Decimate for Blender, which is exactly what I’ve been looking for. It’s an addon where you enter the target triangle count you want your model to have, and it does the job for you. You just need to play around with the values a bit so the vertices match the required MSFS2024 limits.

The only issue is that once you get down to around 10K–20K vertices, the model becomes so heavily decimated that you can’t really reduce it further (I’m talking about terminal models here, not regular hangars or airport buildings).

I’m now trying to find a Blender addon that works like Exact Decimate, but is specifically designed for converting high-poly models into low-poly ones.

 

[pinkjr]

The only issue is that once you get down to around 10K–20K vertices, the model becomes so heavily decimated that you can’t really reduce it further (I’m talking about terminal models here, not regular hangars or airport buildings).

At this point, Blender is your friend.