Yes I know, hence why I brought airplanes and GSX up. Like I said if you make sceneries you have to assume people use other addons too and therefore take them into account when optimising the scenery. I still don’t see the point in such strict restrictions because like I said the dev should see those issues and adapt accordingly. And if there is no need to adapt because it runs well then leave all the detail that you want and that the sim is capable of handling.
It all comes down to the point of the system punishing some devs and addons just because others, which are a completely different scenario, maybe need it…
I would like to point out that LOD5 of the DA62 (available as an SDK sample aircraft) uses the invisible bounding box technique. Possibly a bit misleading…
May I ask if you can show the vertex limit that is calculated for this attachment? I have the feeling we force LOD0 for the interior but not for its attachments (which might be a mistake).
Like I said 3 times now, no we should not remove it because then some developers would not optimise it at all like some did in 2020.
This would be a first step in the right direction and would greatly improve LOD popping as we are able to have a few more verts to play with at lower screensizes. I am all for this
At the end of the day what I and I assume all others in here would want to see is just the vert limit being upped a bit so that we have more verts to play with at lower screensizes. That is all we have been asking for the past 4 days / ever since the sim released.
Again, just want to make it clear that if any of my previous messages have come across aggressively: I didn’t mean it like that. I also just want this to get better for the sake of everyone. But as you might have noticed I am very passionate about not only this topic but flightsim and scenery creation in general and that’s why I got a bit emotional at some point. Should this have offended anyone, I do apologies!
This has been acknowledged earlier in this thread when several people pointed out that many 1stP assets were using the trick - my answer was that many of them were asked to rework their assets.
Agreed but what’s important is the scale of the increase you are asking for - I’ll ask my colleagues their view on multiplying by 8 the vertex limit for the last LOD.
Eric, I think his point was that this is the SDK sample aircraft!
Really, I think the point has been made, everyone clearly understands the challenges, and it’s time to figure out a way to improve the algorithm, and likely in several ways (i.e. LOD0 in the cockpit needs work, too, and, likely the current vert size algorithm is too simplistic, and, sadly, a more complex method is required.).
The thing is though that not only the last LOD is the issue as Py mentioned. It all starts getting tricky below a screensize of 35-25. This is why I think a curve adjustment for the all lods would be desireable.
Notice how it’s the tail section? Now imagine having to apply those same bounding fixes across an entire aircraft that uses a single combined interior/exterior model. When I see individual parts needing artificial treatment just to survive the LOD system, it’s obvious that non-modular aircraft will suffer even more—essentially forcing a full rework of an already well-optimized 2020 counterpart just to meet 2024’s new expectations.
I think there’s a major development hurdle that’s easy to overlook. Even if we build an aircraft around a singular, well-optimized interior and exterior model, following proper MSFS 2024 practices still requires us to move those models into the attachments folder. That’s no longer just a preference—it’s the only way we can take full advantage of new features like preflight pins, modular upgrades, and future career-mode integration, all of which are built to work within that structure.
The real issue is that, somewhere along the way, the attachments folder became associated with smaller components and recycled parts—not full aircraft interiors. But MSFS 2024 relies on this modular attachment approach for scalability, visibility control, and feature access. So now we’re caught in a bind.
We’re being forced to either put in the massive effort to completely tear down our 3D models, code, and sound logic into granular components—or we can skip out on the benefits of the new sim entirely and risk dragging down the quality and reputation of our products. That’s not a small ask for teams like ours who have already optimized our aircraft thoroughly for 2020.
That’s why, at least for now, I prefer the invisible bounding box method. It’s not elegant, but it allows us to retain visual fidelity without significant performance cost. More importantly, it keeps our aircraft “attachment compatible”, feature coherent and competitive while maintaining uniformity in asset creation between both simulators. Until a better path is available, it’s the only practical middle ground that doesn’t require sacrificing quality or tearing apart a stable development pipeline.
Yes, but, the joke is, your own sample is espousing bad practices…
Likely out of necessity?
Anyway… I think we all just thought it was funny… no harm intended.
(Like I said, text is a horrible communication method, all innuendo is lost)
Apologies again - what I asked the team is exactly: “what do you think of replacing the current curve by a straight line 1% → 2.5k, 100% → 250k”.
This made me think - I believe we will also need a new value for between 0% and 1% (150 today) - what do you think would be an acceptable one? 500, 1000? Do you always want 2500 (not sure it will be done)?
Out of curiosity, would the new curve (now a straight line) discussed here help you significantly?
I will have to double check this but I am not sure attachments are a prerequisites for preflight and career mode. Actually they are not either for modular SimObjects even if a modular object without attachments makes little sense.
Let’s say we amend the LOD selection curve - would you be in favor of us ignoring the invisible polygons that artificially modify the bounding sphere of the object?
I haven’t checked its state myself yet (too busy answering you all here) but I am told our own LEBB should demonstrate this. Please have a look and let us know.
In my honest opinion, control needs to shift back to the developers—without hardcoded limits dictating how we build. Devs know the tradeoffs between fidelity and performance better than anyone, and we should be trusted to make those decisions based on our project’s goals and audience.
I get why Asobo’s cautious. There’s always the fear that third parties will abuse that freedom and ship poorly optimized products that hurt the player experience. But the solution isn’t strict enforcement—it’s better tooling, clearer guidelines, and stronger Marketplace curation. Restrictive systems just penalize the developers who are trying to do things right.
That’s why I believe each LOD limit should be defined directly in the model’s XML—just like we had in MSFS 2020. Give us control over when and how LODs switch. Let us choose when LOD0 stays active, especially in cockpit or VR views. Not every aircraft fits the same mold, and forcing one-size-fits-all limits only breaks immersion and undermines quality.
@Jonx To add to that, there’s already some guidelines for Marketplace Sellers, and if the product performs badly - you can get “flagged”. New rating system also provides a clearer description with the ability to vote for visual fidelity/performance etc.
Well there are tools such as the Statistic Profiler. The thing is - if a line turns red telling you that an object is too heavy (for whatever reason), I suspect people will say that its calculations are too restrictive.
Unfortunately, some don’t, which is the main reason why we have this now. Because some didn’t understand its necessity in 2020…