@pyreegue this is a very good observation. It is especially difficult to LOD vehicle sized objects to a satisfactory degree in 2024.
@EPellissier It is not just 3rd party developers struggling with this. There is an abundance of evidence to suggest that 1st party modelers find it hard to work within the limits too. For example AI aircraft that LOD pop and invisible, airport ground vehicles with terrible obvious early LOD changes and models using invisible mesh to enlarge their boundary spheres.
3rd party devs get frustrated when seeing 1st party modelers using “cheat cubes” while being told we shouldn’t.
Here is an example I collected km 2024 months ago of a default truck scenery model using a huge boundary sphere.
This screenshot from a default airport in 2024 contains 1.6 million vertices of trucks alone, which is about 1.54 million more than it would if it followed the LOD limits without cheating. (quick rough math)
Yes, open LOD Debug menu and observe yourself. That’s why this system is doomed. It’s funny now that Wombii also mentioned that Asobo’s assets abuse the cube trick to fool the system. Rules for thee but not for me, as the saying goes.
You can use ModelConverterX to verify the LODs used in Asobo or Microsoft model libraries. In some cases, it’s quite shocking. There is an Aspen model I recall has only 1 LOD with a huge invisible plane. Aspen was a showcase in pre-release previews.
I also have seen a cinderblock with 7 LODs! This is an object of about 8"x8"x16". No need for 7 LODs with an object this small.
And this is crucial to ensuring proper performance, because our packages are used as a come-and-go point, they can get away with less strict limits to a certain extent, while MS’ Library objects are scattered around the globe in thousands of copies, and that puts significant pressure on the hardware.
Yup, quite literally unfortunately… This asset with a massive bounding sphere is from GAYA for a first party base sim scenery… If you are wondering what object in this screenhot has this massive bounding sphere… it’s the tiny bin in the middle of the road.
If not even first parties comply with the rules (because they are quite frankly impossible to comply with in some occasions) why should third party devs do?
We are fully aware that some first party assets used the bounding box trick (or a similar one), and their creators have been asked to rework those assets so that they comply with the rules: I believe some of these reworked assets will be included in SU2 but I need to check with the team in charge.
Are you implying that only “hardcore simmers” use the Marketplace? I am curious to know the basis on which you can make such a statement.
That’s your call and it’s a perfectly legitimate one to make - I see it as a bet that your add-ons will never need to transition to native MSFS 2024 but this is just my opinion.
Thanks for the information - I haven’t had time to test this specific release yet but I should have time to do so next week and will report my findings here.
Regarding the comments you reported or mentioned from other users that are finding the LOD system too aggressive, I feel like we are often missing essential information from such reports such as:
The hardware they are running on
A snapshot of the Display FPS option (where VRAM usage is provided)
Their graphics settings (including whatever hidden setting they may have tweaked)
The add-ons they are running that might be injecting 80 complex aircraft around them
Again, I am not saying that the LOD popping issue some (many?) complain about does not exist, but if we want to understand & improve the situation we need facts & numbers rather than feelings & vague reports.
I did also notice, that MSFS 2024 can force 3rd party aircraft also to be LODDED even there is diffrent lod structure inside of .xml. For example it will get rid off wheels before it is range of next LOD change. Is this some kind hardcoded LOD system for all objects injected in MSFS2024?
Yes. The LOD will swap to the next LOD as soon as the vertex amount exceeds the hardcoded LOD vertex limit; no matter the screensize stated in the model.xml. And if the model does not have a next LOD, it will just disappear.
I did even try to duplicate lod0 model file but when changing to lod1 (same file than lod0, but renamed), it did dissapear. No way to by pass hardcoded lod system then with ai aircrafts?
I personally gave up converting my 4 airports currently in the msmp (never had any complaints for performance). This method invites mediocre products Imo. The developer above here has a record of delivering one of, if not the best immersive airports for the sim, and this system simply doesn’t facilitate that. Making these airports was always a hobby and the income already barely covers the software licensing.
I am not sure I understand the contradiction you are trying to highlight - unless you assume that LODs should start at SS 100% and then each consecutive one should halve SS? This is not how our own LODs are created and I hope this is not something we advise to do in the documentation (if that’s the case then it is a mistake - cannot check myself right now).
The vertex limit reduces exponentially indeed, and this is because (as stated in the doc) the system is aiming at preserving on-screen vertex density - if the vertical screen size is halved, then the number of vertices is multiplied by 0.25.
Are you referring to static Library Objects or dynamic SimObjects? If the latter, this is why we introduced Modular SimObjects in 2024. If the former, I’d be curious if you have such an asset to share so that I can pass it to our artists team and see what they managed to do with it within the current constraints.
You should have a look at the LOD Selection System page in the SDK documentation.
Under the “Vertex Count Limits” section you will see this: In general you should consider the Vertex Count Limit as a modifier of the minSize attribute specified in the XML. Essentially, the effective minSize used by the simulation is the maximum value between that specified in the XML and that calculated from the curve created by the table above.
Which means that - yes, if the value set in the XML by the developer goes beyond the limit we calculated, this new limit is enforced.
As stated above (and that’s the purpose of this whole discussion thread), the LOD that is displayed depends on both the value indicated in the XML and the value calculated by the new LOD selection system - having twice the same mesh to fake LODs (another “popular” technique we have seen used in several add-ons) won’t work in MSFS 2024.
This is what is says in the SDK Manual. First requirement is possible to an extent, second and third contradict each other, because that’s utopian. It’s impossible to half the number of drawcalls (materials) if using tiled textures and decals, it just isn’t, I can’t cover brick with concrete or vice versa.
Alternative solution - a separate texture sheet for every object. That will result in significantly less drawcalls to begin with, at the expense of visual quality and VRAM load, because now that every object has its own texture instead of sharing the ones already within the local project library, VRAM is toasted, hard, unless I keep the resolution low, and if I do - now we’re looking at a pixelated mess that follows these guidelines that feel like were made for a 2010 game engine, welcome back to FSX.
You know this system is flawed, and it won’t work, your inhouse developers abuse it, there’s too much extra work(time and cost) involved to keep the details and texture sharpness at previous levels, and this is a niche industry with a moderately sized user base that is not enough to cover the extra burden financially.
I think we all understood a while ago that you had a strong opinion against the new system. But as stated above we need facts & numbers rather than opinions & feelings (“it’s utopian”, “it won’t work”…) if this topic is to be discussed seriously.
I asked previously if you could forward a model that, according to you, is impossible to properly LOD with the current system - is this an exercise you think would be useful or not?
