No, if you have a 2020 package in the 2024 community folder it will follow 2020 LOD rules (apart from the screensize bug). This is also why nothing disappears at your EDI for example. If 2020 packages in 2024 followed 24 rules, all building at EDI would disappear instantly since none of them have LODs.
@mamuDesign made a very good video showing off what would happen with 2020 non lodded objects if they were combined with the 24 LOD system: https://youtu.be/sQbjvyqgOY0?t=373
Well, let me change that from all to most buildings then. But you get the point. All of the buildings I posted below would disappear instantly if it used the 24 system in 24.
This was not meant to talk badly of you by the way. I have stated multiple times in the past, also publicly, that you are my idol and in my opinion obviously and clearly the best developer when it comes to modelling and texturing, but optimisation wise, especially sceneries other than EGBB, leave a lot to be desired. This is also why I was quite (positively!) surprised to see you form this bug report yesterday as I am not used to u going that deep into LODs.
I think you are approaching the issue from the wrong end with this example: the issue is not really that this low-detail LOD goes beyond the 150 vertices limit - the issue is that you probably cannot model your high-detail LOD with the upper limit we apply.
With this in view, you’re likely to split the LOD0 in several parts, with each part being able to use up to 150 vertices for their low-detail LOD - which should resolve the issue you are highlighting.
Again, feel free to correct me if what I describe cannot work in your case.
Best regards,
Eric / Asobo
Right. Still works fine even on XBOX. VRAM usage at 5-6GBs. Vertex amounts are huge but there are textures shared between buildings countless times. Also, mostly limited by CPU. (Remove LightRows and VectorPlacement stuff - instant 7fps gain. There is room for improvement, but that is out of the scope of this topic specifically.
Not too sure what you are trying to demonstrate with these screenshots - can you please elaborate?
Best regards,
Eric / Asobo
That was for Michael. Not really related to my OP. Disregard
No don’t worry about those. Both of us digressed here because I said none of his buildings at EDI are LODed and would disappear in 24 if 24 rules were applied to 20 packages.
Those basically have to do with the follow up question: do 20 packages use 24 lod rules in 24 which I then answered here:
Ok, for now I’ll have to stay on 20’ SDK without SimPropContainers etc., too many users still using FS20’ to not make a version for both platforms at this moment.
We also do many things (depending on the platform) on the engine side to accommodate for add-ons that believe using 8k or even bigger textures is smart. I won’t even go into the topic of users who think bumping settings found in obscure configuration files is a good idea (8k shadow maps on 8GB graphics cards, really?!!!).
What I am getting at is that the LOD limits are just one part of everything we do to ensure good performance - just because there are other aspects to this issue doesn’t mean this one shouldn’t be taken care of. 
Best regards,
Eric / Asobo
I also agree that sticking objects together in the sim, whether it be with SPCs or not, is impossible without having obvious seams.
@EPellissier you need to understand that sticking objects together in the sim and splitting them in the first place is just not possible for multiple reasons that Py already mentioned previously:
In order to “stick” them together properly in the sim they need to have the same origin in blender otherwise it is impossible to align them in the sim sim. This causes bounding sphere issues
the workflow this creates is highly undesirable and way to complex for what it actually solves and makes creating sceneries, especially high quality ones, more tedious than it already is.
we are making flightsim sceneries here. This means a lot of terminals, hotels, multi-storeys, etc. So we would need to do this for A LOT of objects.
That’s certainly a very valid point - just keep in mind that there will be some LOD rework to do when/if you decide to switch to a native 2024 project.
Maybe things will have moved on the 2024 side when you reach this point too.
Best regards,
Eric / Asobo
I find LOD limits acceptable up to a certain point, but after around SS35-ish is where it starts to become real problematic. Splitting the object will help, significantly, but my terminals will have to be split into 40 or 50, hotels and stuff into 5 or 10, I think. More work = more hours = less content produced. Yes I can hire someone else to do this for me but is there really enough revenue to feed everyone in this niche market of airports. Anyway, thanks for your help once again.
well yeah I agree with that too. Some users are - and sorry for being so rude here - just hopeless cases… There are ppl who complain that they can’t run the sim at stable 60 FPS and have a 4GB VRAM GPU… (Yes I have seen that and I am not exaggerating) People don’t understand that 2010 hardware just isn’t able to run certain things anymore in 2025.
But why have people with a 4090 or 5090 suffer from it just because of those people? Your argument is that you basically want to save those ppl from issues by limiting what they can see, but by doing that you also simultaneously punish the people that could run it and paid extraordinarily sums for there hardware in order to run it.
People with such hardware can probably run the sim at Ultra settings, which should eliminate any LOD popping issue. That is of course providing LODs have been done properly in the first place. If not, I don’t think it is the LOD selection system that should be blamed for “punishing” those simmers.
That being said, I’d happily review instances of severe LOD popping on such hardware - would you be able to provide or name packages that I could use to repro?
Best regards,
Eric / Asobo
Just to make sure I get this right: do you mean that the problems appear for SS below or above 35%?
Because of the amount of vertices you want to put into LOD0 or because of the vertex limit on the least detailed LOD?
Best regards,
Eric / Asobo
At the end of the day as developers, we have to budget our projects and consider things like this and choose a platform.
This LOD constraint imposes severe production challenges and extends production time significantly as well, while failing to provide a major benefit for our customers, who are all “hardcore” users (you know, the ones who are spending money in your marketplace, on our products)
So now that we’re facing an option for our new product, why would I choose FS24, with such constraints and numerous production challenges, along with a low adoption rate?
For the time being, our products are going to FS20 exclusively. It’s stable, it’s widely adopted.
Sorry if this sounds rude, but at the end of the day, we have bills to pay.
@EPellissier First, thank you for taking the time to engage in this conversation. As Michael mentions, the splitting of buildings and putting them together in simpropcontainers is difficult because it’s very difficult to line up the different parts without exporting them all with an anchor node at origin, which may or may not affect boundary spheres.
Could the simpropcontainer system for sceneries be amended to support attaching parts to named nodes, like the aircraft system? This would make this process much more developer friendly.
Edit: if it supported attaching to named nodes, we could even come up with our own scripts to build the simpropcontainers based on node names, making it even quicker.
Edit 2: Based on my own limited testing on xbox series S with draft version of my ENSH, the xbox series S Object LOD setting feels lower than pc medium. I estimated it as low as 20 the last time, and my model LODs struggled with a lot of visible degradation, after spending a lot of time adapting them to a setting of 50-100 on pc.
Sorry for the late reply.
One release that particularly struggles with this is the new iniBuilds EGLL Premium, for example. I have had a look at their LODs myself and almost everything is heavily optimised and LODed. I think there is not much more they can do. Yet a lot of people have reported WAY too aggressive LOD popping on their machines. In fact, a lot of people and customers complain about the LOD popping in 24 in general which is all down to the extremely strict LOD limits we have been talking about. As you can see, there are indeed a lot of people complaining about it.
(the user does not have this on any other scenery because the others are all 2020 native which don’t use the 24 LOD system as we know)
And those are just a few examples. I cannot say how many people have mentioned this before, but it feels like a lot (I know, probably a tiny amount compared to the overall userbase ,but we have to keep in mind that those who report are the ones that care, and those who don’t are the ones that will just stop playing the game)
I am well connected in the flightsim community and most of the people I talk to on a daily, also some casuals amongst them, say that the LOD popping, especially on 24 native sceneries, is unbareable.
There is a reason why we only have a handful of native 2024 sceneries yet and why a lot of devs still choose to work in 2020 - even for new projects they only recently started or are about to start. In order to get the majority of devs to move on and migrate to the 24 SDK, something about the LOD system must change.
Yes Eric, I have no problem with LOD0-1-2, at all, but the impossible bit begins at around ScreenSize 35-ish or less. I spent the day thinking why, and I’ve got the answer. The ScreenSize to VertLimit Curve is the problem, and it’s a very simple fix that will preserve the need for proper LODing yet not be a limit to creativity and innovation.
As the ScreenSize reduces, so does the VertLimit, but if my understanding of the graph is correct here, the upper limit reduces exponentially, not progressively. So at 100% SS we’ve got 250k vertices to work with - no problem, but at half the size - 50% we’ve only now got around 60k vertices to work with. Quite the contrary to what is mentioned in the SDK Docs, which says every consecutive LOD should have about half the amount of verts of the previous one. This is the problem. As the ScreenSize becomes lower and lower, this limit becomes a knot on the neck that tightens even more, and this is probably where all the complaints are coming from.
Either make the number go down progressively or even reverse the curve so that the limit expands, and it’s probably even mandatory at this point, because smaller things like GSE/Vehicles, especially those with special liveries or complex geometry like belt loaders or fuel tankers, can not be properly LODed without obvious popping or texture/silhouette change.
