Bounding Sphere Issue / LODs / Screen Size

[MSFS 2024] Bug Reports Airport & Sceneries
1

Version: *1.3.23.0

Frequency: Consistently

Severity: High

Context: Airport Package. Built, within Community Folder.

*Similar MSFS 2020 issue: Works properly in FS20’

**Bug description:
Bounding Sphere/Box is not rendered correctly. LODs DO NOT work as intended and DO NOT respect screen size when you are CLOSE to the object or INSIDE the object in walkaround mode.

I’m following SDK Guidelines on LODs for Scenery Objects and Vertex/Drawcall limits (close to impossible if you ask me and I think they should either not be mandatory or adjusted, anything smaller than 50x50m has to either be a box with 1 texture or have a 100m fake box around it to not disappear from 2m away.

This is not the way to go, most developers do not have the time nor resource to make 7-8 LODs for each object, nor is it necessary because packages from FS20’ work well enough. I understand the reason for this but I struggle a lot together with many others, there’s often no geometry left to reduce that does not ruin the silhouette of the model and becomes a very noticeable transition between LODs. The last LOD limit of 150verts is unreal, I’ve attached a screenshot of the last LOD for my terminal pier, it’s just the basic shape of the facade and the roof, it’s 555 vertices. Even if I reduce it to just simple triangles and facade it’s still double the limit.**

**Repro steps: Make a model of a building, preferably a larger one, 100m or more, make LODs for it (0-4), and then move closer and you’ll see them not being rendered properly, LOD01 and higher are used while I’m right next to the object. Here’s a video to illustrate.

CPE_LOD05
CPE_LOD052559×1018 133 KB

1 Like
2

Whilst I fully and 100% agree with you on the fact that this new LOD system is WAY too aggressive and almost impossible to work with for high-quality sceneries especially, I also have to say that, unfortunately, you and other developers who didn’t do proper LODs previously are partially to blame for this… :frowning:

It is not surprising that ASOBO had to set some sort of limits to finally force devs to optimise their sceneries.

However, what I really don’t get, though, is the way in which they did it. LOD Limits as they are in 2024 have always been a thing on the 2020 XBOX version, but never on PC. I just cannot comprehend why we now have them on PC too when PCs are able to handle way more geometry - and also drawcalls and textures - than XBOX.

Like you say, it is near impossible to do proper LODs for a big building without visible LOD popping which is a massive immersion killer, especially when the enforced LOD swap happens just metres away.

The thing with the new LOD system is that in the longrun it will make performance, especially on XBOX, even worse. Previoulsy, unless there were no LODs done at all, the sim on XBOX had the LOD Limits enforced to keep somewhat reasonable FPS because of XBOX’s obvious subpar hardware compare to most modern gaming PCs. If everyone starts to do the cube trick now we will also trick the new LOD system, which makes the enforced LOD swapping useless. and it will harm XBOX (but also PC) performance even more than it had done in 2020.

Like I said, I 100% agree with you that this system is ridiculous, too aggressive, and poorly executed. But we also have to think about why they might have implemented it… And I would argue that some devs who didn’t LOD a single building in 2020 and caused a lot of performance issues for a lot of people might have contributed to that… Because at the end of the day the casual doesn’t blame the scenery, they blame the sim. So it is pretty clear that ASOBO and MS wanted a way to enforce reasonable performance to not make the casuals think that the game itself is poorly optimised.

In my opinion they should still be mandatory because otherwise devs would just go back to what they did in 2020 and don’t do LODs at all, but they should definitely be less strict on PC. If you want to keep them for XBOX, fine, because I can understand why they are there on such a limited plattform. But PCs are way more capable than XBOX and as we have seen in 2020 they were also detached there. So why not just loosen them a bit on PC and keep them as they are for XBOX. If they are not as strict but still mandatory on PC we get the best of both worlds: Devs are forced to optimise their sceneries but they can still produce high-quality sceneries without too obvious LOD popping.

EDIT: Oh and what I forgot to mention is that I also noticed that the LOD switching whilst being in the actual bounding sphere is indeed a bug that needs to be fixed. LOD limits aside now, as long as one is inside the bounding sphere, LODs should not be swapped for obvious reasons. This needs to be fixed rather sooner than later.
When I first had this I actually thought that I messed up the origin of the model and therefore the bounding sphere was incorrect. I haven’t re-visited that model yet so I can’t say for sure, but having seen this now I am pretty confident that the root cause is that very bug of LODs switching even when inside the bounding sphere.

2 Likes
3

Possibly related to my post here about 2020 screensize calculations not matching 2024 screensize calculations even after the boundary sphere positioning was fixed. See post 3-7.

@MichaelWimma-RWProfiles i think one of the issues here is that models that were made to comply with the fs2020 xbox LOD limits do not work that well in fs2024, because the LOD switching seems to be switching closer than the 2020 xbox limits.

4

@pyreegue

There are lots of things missing from your report:
1/ What are the vertex counts for each LOD in the building?
2/ What’s the graphics settings used to record the video?
3/ Can you display the bounding sphere of the buidling?

Now, back to the original question: you are essentially saying that the building you show “should display LOD0 when you are close to it”. Why is that? Does it mean that if someone replaces “building” by “airport”, “city” or “country”, the sim should display the LOD0 when the player is in the bounding sphere? Surely not.

What I am getting at is: your building is too large to include the details you want to put into it with one single 3D object - how many vertices do you have in your stairs? Any rendering engine will require you to break it down for good performance (unless you use a nanite-like rendering technique but then there will be other drawbacks).

Back to the alleged LOD selection bug when in the bounding sphere (I am in the train so I cannot test it for myself) - I understand you read the documentation on LODs: LOD Selection System. Hence you know that the LOD selection will be based on the projected vertical size of the bounding sphere: if your LOD0 exceeds the vertex limits calculated for this vertical size in the position you are showing, then we will display LOD1 - even if you are in the bounding sphere (remember: we calculate a percentage of the vertical screen size - it can go beyond 100%).

Now, we perfectly understand that the restrictions we put on LODs require more work on the developers side - but in this specific case, how long do you reckon it would take to break this large/flat building in 3 or 4 different objects? Do we really need the stairs to be rendered at the right end of the building when the player is sitting at the left end?

Best regards,

Eric / Asobo

5

Yes! Exactly my point, anything above SS100 starts behaving very funny. And I think this is the problem
LOD_Limit

6

As I have already stated elsewhere on this platform: we know that this trick is being used, and we know how to detect the use cases - we have warned that this technique should be avoided where possible. I am not sure it would be good for anyone if players start reporting performance issues with add-ons that are abusing this mechanism. :frowning:

I rarely do this but: how would you have implemented the system?

Best regards,

Eric / Asobo

7

Can you be a bit more specific with “behaving very funny” ? :slight_smile:
What I understood from your initial report is that you thought LOD0 should be displayed when you are in the bounding sphere (which is untrue). Are you seeing LOD switching between 0 & 1 while moving forward, or simply complaining that LOD0 is used “too late” when moving forward? If the latter, then it is simply that your LOD0 is too heavy as explained in my post above.

Best regards,

Eric / Asobo

8

This would be related if the OP was speaking of a 2020 package used in 2024 - unless I am mistaken, he has made his tests with a building used in a 2024 package.
@pyreegue - can you confirm?

Best regards,

Eric / Asobo

9

Like I mentioned here:

I already explained how it should have been done in my opinion. Basically a combination of the old and new system.

LOD limies should be mandatory on both versions to force lazy devs to optimise their sceneries, but they should not have the same limits on XBOX and PC. PC should have less strict limits as most PCs are not as hardware limited, generally speaking, as an XBOX.

10

Hi Eric, thanks for the response. Test performed with a 2020 package inside 2024.

Object data as follows:
LOD/VertexCount/DrawcallCount/ScreenSize

LOD00 40,126 verts/46/s250
LOD01 29,769 verts/43/s110
LOD02 18,233 verts/38/s30
LOD03 4,677 verts/25/s5
LOD04 331 verts/0/s0

Also, when in sim, the vertex amount is duplicated for whatever reason. I thought it was linked to instancing, but even some objects without those have double of the actual vertex amount. And yes I mean vertices, not edges/polys.

Here’s this building inside FS20. It has a 200m cube attached to it, otherwise it exceeds vertex limits almost point-blank. The amount of geometry is already very conservative, the only way to have less is to use more textures (increases VRAM consumption = black screens on XBOX guaranteed) and bake all the framing and windows, but that is a sure way to go back to FSX days of “photo textures” on walls. You can see in the video that the model exceeds vertex/dc limits at very close range, even with a 200m cube attached to it.

(On the note of XBOX - I ship my airports for xbox with 50% texture size of that on PC, works like a charm, much friendlier VRAM use, rarely any complaints, and most were from XBOX S, very few from XBX)

Another building to illustrate the issue is the white tent-like pier of the terminal, no cubes attached, reaches the last LOD when viewing from just the runway. All of this tested at Object LOD 150, at 100 it is comparable to GTA:SA LODs and the famous fog where objects disappear is a similar fashion.
(All building have the correct scale applied within the editing software)

Regarding the “split the building into pieces” part. Well, yes that is a solution, and that’s exactly what I did with my main terminal, but that is counterproductive, I’m increasing drawcall amount with every other “part” of the building, and also considering the fact I have to keep them all centered to the same point to be able to snap all parts together, another problem arises - bounding box becomes offset, here’s an image of my terminal pier from that interior video I’ve attached above. It’s a rectangular shaped pier (as most are) and is offset to have the same center point as all my other piers, otherwise there’s no way to stitch them all together without visible seams/gaps. The bounding box of this object is wrong because when looking from the right side you get more than twice the Screen Size value, which results in LODs coming in sooner when arriving from South compared to North.

Bounding_Sphere
Bounding_Sphere1395×1128 238 KB

Diamond_House_Rendered
Diamond_House_Rendered1920×995 195 KB

Diamond_House_Wireframe
Diamond_House_Wireframe1920×1011 184 KB

Terminal_Pier
Terminal_Pier1642×1118 156 KB

11

See, the thing is I am also against using the trick because all it does is make performance worse than it was previously with the old system. I am totally with you here. But you have to understand that for certain objects it is just impossible to not use the cube trick without getting horrendous looking LOD popping that destroys every scenery even with correctly done LODs!

Some buildings or objects are just too complex in their base geometry (because of their shape IRL for example) to make LODs according to the enforced LOD limits. And this is the Problem.

There are devs, like us for example, who don’t want to sell on XBOX anyways. We at least don’t want to because quite frankly we don’t care about the money and just want to make high-quality and good performing sceneries. And because XBOX doesn’t allow us to do that we thought about stop selling on XBOX.

But what is the point now if PC is restricted by the same limits as XBOX is even though a lot of PCs are far more capable than XBOX?

I just don’t get it why you would force this on ppl with a let’s say 4090 and 9950X3D. I know this is a very rare PC and definitely not the norm these days, but the point is that they paid for that hardware to be used. And they cannot make use of it if the sim itself basically gives the an XBOX based LOD system that causes LOD popping even for people with such hardware.

12

LOD Limits are already less strict on PC: Xbox Series is using the same setting as PC Medium for object LODs.

Best regards,

Eric / Asobo

13

Apologies for the misunderstanding then - this is a backwards compatibility issue which must be looked into, and it may very well be related to the issue @WombiiActual mentioned. Is this package available for us to have a look into?

That being said, you should keep in mind that when transitioning to native MSFS 2024, you will probably have to split the building for good performance.

Best regards,

Eric / Asobo

14

Yes I can attach the package privately no problem. Still I’m puzzled by the need to split medium sized buildings into even smaller ones. That will require different LOD/SS values for each part and overall very “messy” workflow while trying to keep track of all the extra objects and xmls. Isn’t that similar to just slapping a giant cube but in a different way?

15

Oh really?

OK, three things then: 1st of all I want to apologies for that statement then, I did not know that.

2nd, is that mentioned in the SDK doc and I am just blind or that information missing by any chance? Because I have read through that section multiple time and I really can’t remember it.

And thirdly, I still think that they could be raised a bit on PCs. Sure it won’t necessarily make performance better at bigger airports, but smaller sceneries would not have to suffer from the issues caused by the LOD limits. Whilst I find it good to somewhat force devs into making LODs, for bigger sceneries they also need to be a bit more responsible themselves and think about how to do what in order to maintain performance and reduce LOD popping.

16

@EPellissier I also fully agree with what py says here: more often it is way better to have more geometry than to have more textures because I think we all know the sim handles more verts way better than more textures. So instead of focusing on the real problem which most of the time is VRAM and DRAWCALLS, this system mainly focuses on geometry which are not the root cause of performance issues, and if used correctly can actually be used to reduce texture size and VRAM usage like py mentioned above.

I think that it would just be a good idea to increase the allowed verts for a specific screensize on PC. This way it would not harm XBOX and those with a more capable hardware will have a better experience. And since they are still enforced, just less strict than they are now, devs are still forced to make LODs

17

It’s very different from the engine point of view:

  • Slapping a giant cube means you’ll force your object to always render at LOD0, hence putting pressure on VRAM/perfs for elements that may be very far away from the user.
  • Dividing the large building in 3 or 4 parts - and not cheating the bounding box :stuck_out_tongue: - means that the part in front of you will be displayed at LOD0 while others may use LOD1,2,…

I am not 100% sure how your building has been done but an alternative could also be that the building itself and inside elements (stairs) are different objects, each having their own BB and hence being LOD-selected individually. They can be grouped together in the sim through what we call SimPropContainers - SimPropContainer Objects

I agree with you that all of this means more assets management but I am not too sure if it can be called “a messy workflow” since this is more or less what every videogame company does these days :wink: .

Best regards,

Eric / Asobo

1 Like
18

No need to apologize!

The fact that Xbox uses an equivalent of the Medium setting is not stated in the SDK - simply because it is not set in stone. Surely any scenery/aircraft developer checks that his work is still “acceptable” in low settings? :wink:

The problems are:

  • How would you qualify a “smaller scenery”? :stuck_out_tongue:
  • Which limit should we apply to such a scenery?

Not saying you don’t have a point, but where do you draw the limit?
Hint: everyone will have a different answer (depending on what he’s working on right now).

Best regards,

Eric / Asobo

19

Other games offer more versatility in terms of texturing and whatnot, together with object scatter/instancing and whatnot (FS Instancing still counts instanced geometry into verts for LODs).

Good example - A/B/C channel for texture colors and decal alphas, which for now are not possible and I have to either use more polygons to apply different colors to let’s say facade tiles or a larger texture sheet to paint the whole building manually instead of using 1 texture for a wall e.g. and 1 for grime/dirt and mask it with an alpha map. I know there’s ways to do this with vertex alpha but yet again - vertex alpha needs vertices, a lot of them.
I use vertex colors primarily for ground polygon, which basically let’s me have 1-2 textures for asphalt and concrete and an infinite amount of shades, so I don’t have to use a large underlying satellite image and as a result - less VRAM used.

On the topic of LODs - here’s another example. Last lod for a hotel, barebones cubes - 246 verts, almost double the 150 limit.

But if you say splitting the object is the way to go then so be it, who am I to argue after all. I’ll go this way then. (Not possible for things like Jetways though?)

Novotel_LOD
Novotel_LOD1920×966 86.1 KB

Please keep us updated on the ScreenSize logic for 20’ packages in 24’.
Also, are LOD Limits in 24’ forced on packages built with 20’?
Cheers.

20

Yeah I totally agree with you on the fact that, like you say, this is generally speaking highly subjective and everyone has a different definition for small, medium, and big airports. I didn’t really mean that you should change the limits based on the size, I more meant that you should increase the allowed vertex count on PC before a LOD swap is enforced in general to mitigate LOD popping, and the devs themselves should think about what is necessary in a scenery and what’s not. I have to admit I myself am guilty of modelling things that are not “necessary” per se because I also like adding as much detail as possible and re-creating the airport as best as I can to mimic its real-life counterpart, but this more a problem of customers demanding more and more with every release, because scenery “standards” have now reach and undesirable level from a game development perspective as developers have pushed this standard that high. I have nothing against innovation, but at the end of the day we need to keep in mind that this is a flightsim at the end of the day. Have we modelled full interiors etc. in the past too? Yes, of course, but mainly because customers demand it these days in order for it to be called “good scenery”.

And I also have to admit that I like them myself too as, especially at night, fully modelled interiors look way better than FSX style emissive textures, for example. But I digress.

So, long story short, I am totally with you that you (Asobo) could not judge what a small, medium, or big airoport is. But what I would like to see is an increase in the allowed verts in relation to screensize before a LOD is swapped on PC. I still want it to be mandatory to force devs to do LODs, but I would like to see it loosened a bit more.

As py illustrates above, the fact that this very very very simply object is not allowed to be displayed at a certain distance is ridiculous. I mean let’s be real, what performance impact does a 246 vert building with only vertex colours have that it is justified to make it disappear?

This is what I meant with ridiculous in the first place. The fact that they just disappear at a certain distance is what makes this such a pain to work with and makes the cube trick a necessity for some objects. Because if a whole hotel, even though it has near 0 performance impact, disappears completely, something is wrong with the system in my opinion.

The sim, and especially modern graphics cards, are capable of handling rather high poly counts. The main issue for most people is still the VRAM limitation and drawcalls. And whilst the vert limits help a little bit in this regard, it doesn’t tackle the two core problems. It just makes the visual quality and overall feel of a scenery deteriorate because of the obvious LOD popping, but doesn’t solve VRAM issues and mainthread limitations cause by too many drawcalls.

1 Like