Let’s not get carried away with finger-pointing and stay on topic. Primary reason is to keep all objects uniformly optimized for the new engine and since there is product streaming now, to keep the bandwidth within limits.
I am not pointing a finger that’s why “I said I am not saying who”…
This was to demonstrate why we NEED some sort of limit and why we have them now.
Stuff like this is literally the reason why I have always said in this thread that some sort of limit is necessary, but it should’t be as strict and I am more than happy to hear now that Eric has forwarded this!
(and no, this is not from your sceneries if you thought I would imply that… I specifically chose another scenery of a developer not present in this discussion)
I am planning to try the proposed curve on an internal build asap, and check the impact on various aspects & platforms - I think I have meetings nearly all day tomorrow and on Thursday, so it may be that I cannot discuss with the team and report here before Friday or early next week.
Best regards,
Eric / Asobo
1 Like
@EPellissier Fingers crossed. I’m glad we were able to come up with something. Cheers
2 Likes
Agreed, if this can be implemented or improved in any way, I am more than happy. I am also glad we came to some sort of conclusion! 
2 Likes
Great conversation here about the LOD flaws in 2024. I am fairly new to modelling airports and making custom objects in Blender (18 months). I did a freeware airport for 2020 (KFDK) and currently working on a new airport with the 2024 SDK trying to learn better techniques as well as doing proper LOD’s . It is a small GA airport and I was surprised to see how strict the LOD’s were as I have had trouble keeping a simple hangar from disappearing only a mile from the airport. I have learned to do LOD’s only a few months ago and have used 2-4 lods on each object trying to follow the rules (no invisible cubes!) . It has been frustrating and I could see how frustrating this would be for the pro developers. I can also imagine how freeware scenery creators may blow off the hobby completely with some of these issues as I personally would not even release a freeware airport where there was such obvious popping in/out of the airport structures. I know there may not be a way to split the restrictions depending on the size of airport/area, etc but a loosening of the rules would give the Dev the responsibility to determine what they should be based on how complex the project is. For example, my current project is a small GA airport with a 2700’ runway. You will certainly not be flying a complex airliner into this airport nor be using GSX, FSLTL, etc. I do hope the suggestions presented by the other more knowledgeable devs are taken into consideration!!
2 Likes
Just one thing if I may - can you confirm that you believe 2.5k should remain the limit between 0% and 1% or can we target something a bit lower? I was thinking of 1k (which is already 6x more than before 
) but perhaps this would be too low for some of you?
Best regards,
Eric / Asobo
1 Like
Below 1% can be anything to be honest, my weakest points were ~35-1%.
2 Likes
I wouldn’t say anything. Maybe 500? Because for a VERY complex (complex architecture IRL, think about curved roofs on terminals etc) 150 could also be too low I feel like.
1k should definitely be fine. If this gets accepted I would of course happily take it. But it should not be lower than 500 imo.
1 Like
At the end of the day, I’m just here voicing my perspective. As long as it’s been heard, that’s all that really matters.
As for the limits—you can safely assume I’ll continue working around them, tricks or not. Calculations are optional. Limits are meant to be overcome. That’s the definition of progress.
1 Like
Just want to give support to the proposed linear line option. Anything that gives us scenery devs a ‘little’ more wiggle room is very welcome.
Also, I’d like to throw something else into the discussion that hasn’t really been touched on yet. Currently the final LOD is forced to 0.5% regardless of what is set in the XML. Generally this isn’t too much of an issue, except for small ‘important’ objects that should be visible from a distance.
We have a number of sceneries where runway markers (think cones or markers as per the photo below) line the runways. Its perfectly possible for us to get the final LOD within the 150vert limit, but due to the small size of these objects, they still pop out way too early. These objects are critical for pilots to be able to see on approach to a runway and the current 0.5% limit is simply too high.
We currently use the ‘cube trick’ on objects like this, but it would be nice if the final LOD limit was a little more forgiving so we didn’t have to resort to ‘hacks’.
4 Likes
I would like to highlight a direct observation:
The common theme here seems to be:
- We used the “Cube Trick.”
Considering most—if not all—developers in this discussion have resorted to it, the conclusion is pretty clear.
Across the board, the current LOD limits are too strict. And this isn’t due to group influence or shared guidance—it’s simply the result of every team independently running into the same limitations. When workarounds become the norm without coordination, it’s a strong sign that the system itself needs to be reevaluated.
This, however, doesn’t promote positive problem-solving.
The mindset shouldn’t be “We know how to detect this and stop it.” It should be “Why is everyone doing this in the first place?”
If nearly every experienced developer is resorting to the same workaround, it’s not a question of trying to cheat the system—it’s a sign that the system itself needs work. Solutions should come from collaboration and understanding, not enforcement.
7 Likes
Just a tough about the cube trick
An object like the one posted by @B21 (or a taxiway sign)
, made visible at 500 meters distance won’t affect performance (especially in 2024 thanks to fast mass instancing). Pretty sure that its last Lod would be a simple white pyramid
On the other side, using the cube trick to avoid doing LODs and keep visible a single multi million Lod boat is just being lazy
–
An addition
A check/warning during injestion using…uhm… the statistics profiler output would give developers a little bit more attention to the quality of their assets
Of course it is hard for customers to understand that they can’t have ultra settings with bad optimised assets, full atc and weather with a potato computer and 56k internet connection
(I grew up with very low level hardware and interner and get used to optimisation)
And keep it that way please.
1 Like
This is a tough call, because on one hand it’s an issue that the new proposed limits might help alleviate, and you don’t necessarily want people using this method just to get away with not doing any LODs. However on another hand, you have the following example where this method is the only option to get the result you need:
I’m glad that this was brought up. I was just catching up on this thread and was going to mention it. I have resorted to placing a square underground for these objects to keep them loaded past this pop-out threshold. I only put it on the last LOD, which still affects all of the minsize values. However, I am still doing full LODs for the object first and then adjust the minsizes to keep it performant.
I’m glad this was clarified. I’ve been looking for clarification on this for a long time. Without diverging too far off topic, could you offer some clarification on these Optimization Recommendation points from the SDK as well?
- Remove textures you may not need at a distance, such as the normal map.
Obviously this means having a different material for each LOD. Material_LOD0, Material_LOD1, etc (Just a structure example, not saying you’d want to get rid of the normal map on LOD1). Is this still a recommendation? Are there any downsides to worry about with swapping between these materials in a semi-fast succession? (LOD swaps) The reason I ask is I implemented this on my Library assets about 1-2 years ago and it seemed to tank performance a bit on Xbox when almost all assets in the scene did this. Though, there are no tools on Xbox to pull hard data for this, so I was just going by feel and how long it took flying around the airport until memory finally ran out. When I reverted back to using only a single material (until I get to the vertex paint LOD) performance seemed to improve on the Xbox. On PC, there was no noticeable difference, so it made it difficult to test. Obviously the statistics profiler showed a lower memory usage when using this optimization recommendation.
- Prefer low-resolution textures for LODs below the approximate 5% “minSize”. if you really do need a texture, try to keep this as 64x64px or smaller.
Also, this isn’t something I use a lot, but I do have a few use cases where it is needed over vertex paint. With the texture streaming in 2024, is this method useful still, or is it better to use a material with just your same LOD0 ALBD material?
Please take a look at my post here, I used a 256x256 texture that is baked from 4 points of view of the model, front/back/side/top, which I applied to a very simplified shape of the vehicle at LOD05, it works great. LOD00 texture is 4K for PC and 2K for XBOX.
Just for further clarification: I was asking from a performance standpoint in general. Is it better to just use the main Albedo texture in place of the 64px texture? This is with the new texture streaming in mind. Assuming this is also done for local packages and not just those packages streamed from Marketplace.
Edit: I understand that you used a dedicated 256px texture to make a very low poly version for your tug, but that wasn’t the exact question I had intended!
Eric, I don’t see any other way around this!
There MUST be two different versions - one for Xbox. One for PC!
Why are we PC users penalized with aggressive LOD? No Xbox will match my 12700K, RTX 4080 and 64GB ram. I paid for my parts and built my own machine - the cost, of course, was far greater than what an Xbox cost.
I make liveries and even they turn to white just a little further away from the aircraft.
It’s not acceptable.
Good point and well noted on our end - I’ll include testing tweaks on this value in my tests. 
Best regards,
Eric / Asobo
1 Like
Did you miss what happened next in the conversation?
Best regards,
Eric / Asobo
1 Like