I’d rather do that at build time instead of ingestion.
And believe it or not there are already messages when certain assets are too big (I think it’s only related to collision meshes though).
The problem I have with this is that we already log lots of information / warnings / errors to the point that users tell us there’s too much information and they don’t read it.
Unless these checks are blocking the package builder (which I can already anticipate some of you would be against), I am not 100% sure new warnings/errors would help a lot. We might try this though.
I need to have some technical review (with specific colleagues) of these recommendations which I think applied to 2020 but are not relevant anymore for 2024. I have the feeling that with mip streaming (which btw applies to both streamed & local packages - the term merely means streaming from disk to GPU ), having different materials for different LODs would do more harm than good.
Same answer - because of mip streaming we would only load the mip level we need for such a size, hence not overloading your VRAM with the full texture.
Re-reading the post you replied to I am not sure what you are referring to:
Different versions of the sim (I don’t think that will happen but it’s not up to us do decide) ?
Different versions of the LOD curve (this is already the case through Graphics Settings which are Medium on Xbox for object LODs) ?
Different versions of packages (developers can do this if they want to) ?
Please clarify.
As a side note: an Xbox Series X is more or less similar to my home PC, probably even better on the GPU side (granted, I have 16GB of RAM vs 12GB on the console but Windows is not running on the console!) - are you suggesting “different versions” between PCs too?
Getting back to this, I am wondering if the following would work:
0.1% → 0.5% → 150 vertices
0.5% → 1% → 1000 vertices
1%->100% → percentage of 250k (linear)
We need to keep in mind that depending on Graphics Settings there’s a multiplier on the screen size before the lookup - 0.5x on ultra, 2x on medium, 4x on low (the lower limit of 0.1% would remain the same in all cases but 0.5% and 1% would become 2% and 4% in Low).
The linear model seems like it will improve LOD popping when transitioning from high to medium LODs compared to the current one. It is also easier to calculate for developers using a rule-of-thumb. I have this calculator that I use and you can see the difference.
To add my 0.02 to the conversation, two factors make the LOD problem difficult in 2024:
First problem is that the LOD limits change with detail settings: this makes LODs difficult because even your own plane will look very different at low vs medium. The Airframe may not be that big of an issue, but in a modular plane, propeller LOD0 vs LOD3 can make a big difference.
The second and most important one is that the LODs apply to your own plane as well. I believe that your ownship should always be rendered at the highest LOD, inside and out. The AI/MP planes can drop lower, but your own plane should not. Using FS2020 as an example, the exterior is always locked at LOD0 (which is great) but the interior degenerates instead of sticking to 0. With complex models it can lead to the exterior and interior not matching correctly and makes the job more difficult.
Now in 2024, this adds an extra layer of problems. I’ll use the ENVOCCLUDER as an example: we usually put that only in LOD0. If our plane degrades to LOD1 because of the settings, then the user will have trees and rain inside the cockpit. Do we add occluders to all LODs? If yes, then the AI planes will “cut” through the fog at long distances.
IMO the linear model could be a big improvement, even though it could adversely affect performance to an extent. As far as airplanes go though, I believe that forcing the user aircraft to run at LOD0 (or no lower than LOD2) would be a huge improvement in terms of looks and work.
It is, generally speaking, a bad idea to have multiple different versions of textures in different resolutions for LODs for various reasons:
Just remove the COMP and NORM at lower LODs and keep the LOD00 albedo for all LODs. I don’t know why this is even suggested in the Documentation because of the below reasons (especially 2, 3, and 4)
(unless it is like a 4K or 8K LOD00 albedo then making a lower res version just for the last LOD could make sense.) Again it has to be judged on an object to object basis and there is no real rule of thumb apart fromt he fact that making individual textures for each LOD as the SDK suggests should be avoided.
Just saying, all of those would just disappear if we now settle for the 150 Verts limit even at the lowest screensize. So you would then still have to split them into 2, 3, or even 4 separate objects in order to not disappear.
We’ll have to test and see. It’s 2500 at 1%, 1000 at 0.5% and 150 at 0.1%, I think that’s plenty considering the amount of pixels if we do the math, I can remove pillars and other shapes and leave it to being simple cubes, though I agree, if a cube alone uses 24 verts, this might be a bit of a challenge. Once again, let’s get this update and see for ourselves how it goes. This is a starting point.
Well I’m not a true developer… but I make a lot of repaints (or I had for 2020 - 2024 makes it very difficult unless we’re using the vector method where we add a thin mesh onto an existing model - but hardly anyone knows how to do that yet who is doing this as freeware!).
But I’m mostly speaking as an end user. What I see is that my liveries disappear only a little further away from the aircraft while in flight.
Take for example the PC12 - I’m pretty sure the only model we could import with partial success was the LOD1. So it’s super aggressive though, just a little more zoom out and part of the paint disappears!
Can’t we just have a toggle option in graphics settings to “Use Standard 2024 LOD?” And when unchecked it reverts to MSFS 2020 style LOD? I don’t the engineering side of it though!
Yes. I probably shouldn’t say anything as this is off-topic, but I used to really enjoy creating liveries. It’s looking way too complex for me now. I could go on, but that discussion doesn’t belong in this thread.
Toggle aircraft to 2020 LOD’s for those who want it? Doesn’t seem like there’s any interest in that, and I’m sure they’ve got way too much other work to do. But, it’s an interesting idea to have a toggle LOD0 only option for the user aircraft. It probably won’t work in multiplayer mode, but, who knows? Those of us with 4090’s, it maybe could work?
It was written already but if you do not mind I share my experience. On the current and the one previous project we strictly implemented the process of LOD’s according the rules (we did LOD’s before too but not that deep). Do not linch me please but for me the LOD creation with 50 and 100 triangles does not give that much of a problem. We need to talk about triangles because vertex count may mislead you in blender/3DS - there you have welded vertice numbers but in the game they are separated per poly. (If you have a vertex that is connecting to 3 polys you have 3 vertices on the same place eventhough Blender/3DS counts them as one).
Where I had problems are the small objects like taxiway edge lights etc. Because of the 0,5 rule they disappeared too early. In these cases I used a 2x2x2 bounding box to concur that problem.
My other issue: As I go deeper in the LODs I remove the normal textures and the OcclusionRoughnessMetalness textures one step later. I usually open the ORM texture and with the sample tool (eyedropper) I sample a typical area and I adjust the Roughness and Metalness value of the material accordingly. For example if I have a building I sample a wall which mainly represents the whole texture. This is not a perfect solution of course. This is where I have the most of the problem. Usually it is very apparent when the LOD changes to a LOD where is no ORM texture anymore because the object’s shading changes dramatically. Especially if the texture has a wall material and a metal roof. The roof will change shading and makes the LOD change ugly.
Here comes my question. Would it be possible to use vertex color for Roughness and Metalness values on polys? Like on a second vertex color channel for roughness and third channel for the Metalness. With that way we could better blend out the ORM texture removal. On later LOD we even could remove those vertex color channels and “merge” their values on material level.
Yeah, my time on this thread is complete. Your response solidified that. Hopefully your team finds a solution. Back to focusing on things where my opinion isn’t matched with empty sarcasm.
Just to keep you updated on this topic: I implemented the new curve discussed earlier as an option that I can dynamically switch on/off from DevMode for testing purposes - the initial plan was to release it during the SU2 flighting for you to test, but unfortunately there were too many other issues to fix on our end for this to happen. To be honest, I haven’t had enough time to assess the impact on performance just yet.
The plan is now to release this switch as part of the SU3 flighting and, if the new curve proves satisfactory for everyone, to make it the new curve for the official SU3 release.
Apologies for the delay - I’ll report back on results with this new curve as soon as I have enough time to test it properly.
This is great news! Thank you for following up on this.
In the mean time, I was hoping to look deeper into the default airports and assets to learn ways to improve my LOD smoothness. I looked at LFPG, since I remembered seeing that was a sample in the sdk.
I was impressed by the smooth transitions, until I turned on the bounding sphere debug…
Do you have suggestions for default scenery assets that work well with xbox level graphics settings that we can look at in the sim to learn?
