Are you saying that the 2020 package does not behave in 2024 as it did in 2020? If that’s the case, yes there is a bug indeed and it needs to be fixed.
However, if the assets you used to make the 2020 package behave differently once compiled into a 2024 package, then that is the expected behavior. But it has nothing to do with backwards compatibility which is provided at the package level, not the assets level.
Yes - there was no good reason to do this in 2020.
Again please clarify: both sims use a different LOD selection system but 2024 will apply the 2020 LOD selection system to 2020 packages. If you are saying that maintaining two versions of the same add-on for both sims requires more work then yes, you are right - but this has nothing to do with backwards compatibility.
Obviously I am within the bounding sphere of this building and, in MSFS 2020, the screen size would be 1000 - so there is definitely a bug in our backwards compatibility scheme (which I believe we have identified a few minutes ago with one of my colleagues).
I’ll check that the fix we thought about is actually the right one and I’ll report here.
SGF is not my main worry because performance there is great anyways even though LODS are not exactly how they should be. It was our first scenery and we were new to the topic so it might not be the best to test with as LODs are not as good as they could and should be.
But that doesn’t matter in this case and the problem is the same like you saw for yourself.
But with heavily optimising our new scnenery with a lot more LODs this became more and more of an issue hence why I raised it. I will make a native 2024 SGF build soon anyways.
But please make sure you don’t just change one sim or the other to use the other system. You need to make it so that 2020 sceneries use the 2020 method in 2024, and not change the 2024 system to the old one because this will break already exising 2024 native sceneries that used the 2024 Boundingsphere numbers to trigger LODS
You also cannot use the 2024 numbers in 2020 becuase that will break all LOD switches of 2020 sceneries in 2020.
I am sure you are aware of that, jsut wanted to mention it for good measure!
Sorry for that: bad wording on my end. With “system” I did not mean the LOD system per se. i more meant, which you know know is an actual bug, that 2020 sceneries should use the same boundingsphere size and numbers in both sims to ensure backwards compatibility. A 2020 scenery should and must use the same boundingsphere screensize in 2024 to make sure the LODs switch at the intended point, and not way sooner as illustrated.
I’ll get it reviewed by some colleagues and then integrated into a future SU3 Beta build - I’ll let you know when I know the first version number in which it will be available.
Apologies in advance if my comment/ question is stupid. I didn’t get to read through all of the responses on this thread and I have only begun going through the 2024 SDK. What I wanted to know is would it be possible in the future (For aircraft only) to raise the limits on the LOD vertices and decrease the size on screen before the LOD disappears?
I can understand from a scenery perspective, there needs to be lower limits on LODs. However when we tested in FS2020 with an airplane, we could hit 20 million triangles easily ( no textures ) and the sim would run just fine with not noticeable drop in FPS. My impression is that for both aircraft and scenery, good texture management is important so that the VRAM is not overloaded. For aircraft in particular, assuming LOD’s are used, the first two LOD’s can easily be in the millions of triangles and sim won’t even notice. It’s really the texture management that affects the FPS ( and on the inside, the systems, avionics must be optimized to avoid FPS hits ). Am I wrong in making this assumption?
So my hope is that for airplanes, when we setup a package, we can have different set of limits so that we are not forced to split up the each LOD in multiple sections. Would this be something you guys would consider or have already considered doing? Or at least giving an option for much higher limits on a PC spec package vs Xbox package?
May I ask if this is still on course to be integrated into SU3?
In any case, according to my tests the current SU3 beta (1.5.24.0) is still breaking backwards compatibility with 2020 packages in terms of dynamic LOD rendering as long as the new experimental LOD curve option is enabled.
I’ve been doing some tests with objects LODs and I’m experiencing an odd behavior in sim. When I export an object with it’s associated LOD’s and minsize values I have to cycle a setting in the object properties, in sim, so that the values I entered for minsize works as expected, otherwise the transition of LODs occurs much sooner or even jumps LOD levels altogether. All this with an object that doesn’t go over hardcoded vertex limits.
Another thing that I’ve noticed is that when I’m far away from an object, it disappears before the minsize is reached with an object that respects the hardcoded vertex limits. In the statistics profiler it shows the last LOD with a red warning regarding bitmap count, should that be the issue why that LOD is disappearing even thought is within vertex limits? Also I’ve made sure to not have any texture associated to that last LOD, so I’m not sure why this warning is showing.
Thanks in advance, hope someone can help me with this.
PS. I’m quite new to MSFS development, please let me know If I’m doing something wrong.
This topic has been automatically closed after 60 days of inactivity since it was marked as obsolete.
If there is important new information about this same report, you can use the “Request reopen” button below to ask the moderation team to review it again.
For other issues or broader discussion, please open a new topic in the appropriate category.
What I wanted to know is would it be possible in the future (For aircraft only) to raise the limits on the LOD vertices and decrease the size on screen before the LOD disappears?