Does this satisfy your request for a factual proof of my concern, Mr. Pellissier?
I am sorry if my question sounds dumb but: isn’t the pause menu seen at 1:23 that of MSFS 2020?
I mean - are you demonstrating a model that works in 2020, assuming it won’t in 2024?
If what you are trying to demonstrate is that the 150-vertices model is ugly (which I would agree with), maybe you should remember that it will only be displayed for a vertical screen size between 0% and 1% (for high settings) ? That’s 0 to 20 pixels of height in 4K - do we really need more detail for such a height?
(EDIT: see my reply below after I fixed the maths…)
To make things clearer: if LOD 6 appears earlier than this on MSFS 2024, I would consider this a bug indeed. I wonder if it could be related that glTF files sometimes report more vertices than 3D Studio does (as discussed here)
Best regards,
Eric / Asobo
1 Like
Yes, it is 2020 with LOD Limits applied, my XML file is as follows. On the video I demonstrate that when the VertCount becomes Red, the model will disappear in FS24’. Another move is from LOD06 to 05 and 04, where the transition is also visible. LOD05 is a baked photo texture, this is the only way I can think of to keep vertexcount low. This trick does not always work, there are more complex models like belt loaders and whatnot and it is a very visible transition between the two LODs.
As mentioned a few posts above, I find the new system bearable until lower screen sizes (35% ish and lower) when there is no geometry left to remove that does not ruin the silhouette or core shape such as windows, doors etc. (Also if the vert amount wasn’t double of what I see in Blender that would help)
I appreciate the 4K comment, but this was filmed with very high settings, almost ultra, what about this very model within xbox or lower end PCs that run ObjLOD at 75-100? It’ll be right in the users face, especially if you consider a situation where there are 20-30 of similarly sized vehicles.
Xbox runs on medium settings (and Object LOD cannot be tweaked) so your LOD6 should appear when the object is 0 to 40 pixels high (again, in 4K). The PC Low configuration (with Object LOD at 100) will show it up to a height of 0 to 80 pixels (still in 4K). Hardly “right in the users face” unless I missed something?
(EDIT: see my reply below after I fixed the maths…)
Best regards,
Eric / Asobo
I think the missed point here is that according to Steam Hardware Survey 2024 only 3% of users have 4K resolution monitors. I’m running 2160p and I can see material/shape changes very well. Yes it won’t be AS noticeable when you’re focused on flying and not LODs, but this instance is one of those noticeable ones.
There’s no missed point - the pixel height will be even lower for lower resolutions. So someone playing on Xbox in 1080p will see LOD 6 when it is between 0 and 20 pixels high - since this is calculated based on a bounding sphere, we can approximate that the full object will cover a 20x20 pixels square - are you saying we need more detail than that provided in your LOD 6 in this case? (EDIT: see my reply below after I fixed the maths…)
One thing that seems a lot more interesting to me: how is your object showing in MSFS 2024? Do you see LOD switches being made a lot earlier than the theoretical values? Does LOD6 appear “right in the users face”? If that’s the case, then we may have another bug in our calculations (some were fixed during the DevAlpha) which needs to be addressed.
For what it’s worth I am checking the behavior on Series S and will report with screenshots.
Best regards,
Eric / Asobo
I will record a video from 24’ with this very model shortly.
1 Like
Discussing the issue with my colleagues, I realized that I had my maths all wrong… I fixed this in my previous posts, apologies for the mistake.
Now it means that 1% of 2106 pixels is not 2 pixels but 20 (actually 21 
) - which means your LOD 6 would be visible in a 21x21 square, which I would agree is too big for the quality you can reach with so few vertices (still I am interested to see this in action in MSFS 2024 
)
I’ll discuss again with the team tomorrow and let you know about our findings.
Best regards,
Eric / Asobo
1 Like
I thought each progressive LOD was supposed to be 1/4 the size of the next (basically texture sheet size changes, 4096 to 2048 to 1024, etc, IOW, 4096 x 4096 to 2048 x 2048 to 1024 x 1024).
Be that as it may, I think Eric has an understanding of the scale of the issue now. Py demonstrated it perfectly.
1 Like
Yes they are relevant @MichaelWimma-RWProfiles . Each material costs 1 drawcall. Drawcalls are accounted for LOD Limits.
I know.
Disregard my previous messages, I had the drawcall limits on and not the vert limits because I checked the wrong tickbox. I will delete my previous posts to mitigate confusion.
I obviously know about the drawcalls etc and that they are relevant but I didn’t think about that 6 drawcalls/materials could already be too much even though the object is still quite visible.
I was using the texture as an example of what they are actually saying when they say “vertical pixel count” and the relationship to LOD pixel size. The numbers Py has been using to show how the number of pixels per LOD reduces at the same rate as pixels on a sheet. For “simplicity”, Asobo discusses the concept in terms of vert count pixel count (just as we say a texture sheet is 1024, when it is actually 1024 x 1024), but the number of pixels allowed per LOD is reducing by 1/4, just like texture sheets reduce in size, not 1/2, as both Py and Rhumbafloppy have noted. This is probably why your parts are turning red, because they are only half the size, not 1/4 the size.
Or did I misread that.
And sorry if I confused the conversation by bringing texture sizes into it, lol. I only meant it as an analogy!
I think that was about verts too because 100 SS is 250k verts and 50SS only allows 62,5K verts. So in this case the 1/4 was about verts. But since this is the rule for verts I assume it is the same for drawcalls too?
The problem just is that since I know how you texture stuff and I do it the exact same way, obeying the drawcall limit is also near impossible. Now if the Vert limit wasn’t struggle enough, also complying with the drawcall limit for is nigh impossible, especially for buildings in my opinion.
The problem for small objects like trucks, cars, GSE etc is the vert limit, and for larger objects like buildings etc, the issue will become the material limit. Not too much of a problem up until like SS 13ish where you still have 21 Materials to work with. But as soon as it gets lower that that and you texture with tileable textures, just like you explained above, will become even more limiting that Verts I think
If I understand correctly
Half of the issue here is that you are expecting lod6 (150verts in blender) last until 1%
But the vertex count in blender is NOT the same as the game
Throw your model into a glTf viewer capable of counting vertices correctly, and you will discover your model will have in game almost double the vertex count…
1 Like
No mamu, the issue is that the LOD limits are way too strict and that it is almost impossible to make a decent looking high-quality scenery without obvious LOD popping.
Not really. You can halve the amount of stuff with every LOD, it all depends on how many LODs you make, you can have 40k/20k/10k/5k/2.5k/1.25k and so on, it’s just a recommendation, because you can tweak ScreenSize values for each LOD.
It is the LOD Limits that are just too strict, for most objects it is impossible to LOD them down to a satisfactory level.
Regarding the texture size reduction - I thoughе the simulator did downsizing itself? DDS textures have MipMaps for that exact reason. I can’t imagine having multiple versions of the same texture just for LOD purposes, packages will grow in size disproportionately.
1 Like
I still fail to see where these phantom vertices are coming from. Cube-formed geometry, no N-gons. It looks more a triangle than vertex count to me.
1 Like
That was actually something I was writing up before I deleted the other posts. The fact that this is even suggested blows my mind for several reasons:
-
with the amount of money an average dev makes and with how many objects there are in a single scenery, expecting every dev to make mulltiple textures sheets at different resolutions for every single objects is just insane. This would add so much time to the process that we would all go bust.
-
Like you say, what’s the point of having .DDS files if we still had to do it on our own
-
Package sizes would be huge with so many extra textures
-
Having different textures for different LODs is a bad idea to begin with because if the GPU isn’t quick enough unloading LOD textures out of the VRAM, we would actually see an increase in VRAM since it could happen that 2 texture sets for 1 object are loaded at the same time.
1 Like