Bug description: Custom models disappear too quickly even when LODed properly. Depending on their size, they seem do it at a random point below a screensize of 1%, even though the last LOD is below the 1000 vert limit.
Now it seems no much of an issue for most objects since below 1% screensize a single object disappearing wouldn’t be noticeable. But when a lot of these objects are clustered and all of them disappear it becomes really obvious. The best example for this are cars or apron GSE. In this video I have made a few clusters of GSE to better show what I mean. Even when fairly close to the apron everything just disappears. (Again, like mentioned, they are all properly lodded and the last LOD has 400 verts - well below the 1k limit)
The problem really is that, especially for GSE, the threshold of it despawning is so high that LOD popping is extremely obvious in normal flying conditions too. Look at this video for example where I simulate moving along the runway. The models clearly pop on the apron which looks extremely poor.
For cars it is even worse when whole carparks are filled and they just all disappear in plain sight.
I have worked around this by using the old cube trick that was often used to cheat the LOD system. I am not doing it to cheat the system in this case because as you can see I have properly LODed them without the cube anyways, but making the object bigger is the only way to make them not disappear.
The problem just is that this completely defeats the purpose of LODing it to begin with when even if we follow the LOD rules they still disappear regardless.
Please change the threshold to make properly LODed objects not disappear so quickly. I suggest a Screensize of 0.3% or less. But then again I don’t see a reason why they should disappear at all if LODed properly.
Repro steps: Make a small object and cluster it. Then move the camera back until it hits a SS of 1% and see when it disappears.
I’ve noticed this too, objects disappears far too early even with proper LODs and following the guides for vertex count and screensize. It’s quite obvious when this happens, and it looks for the user that proper development wasn’t done when it actually was.
I also noticed that even when an object disappears the LOD debug info still shows, given an insight that the object should stay visible for at least as long as the debug info shows.
Exactly! That’s also what baffles me. The object is obviously still loaded otherwise the debug wouldn’t show. So why is the model itself disappearing. Makes very little sense to me!
That info is no longer correct. It was adjusted a few months ago after a lengthy discussion here: Bounding Sphere Issue / LODs / Screen Size and the implementation of the new LOD curve. The 150 limit was raised to 1000 below a SS of 1%, which is why the LOD debug stays green in the examples above even after the models itself disappear.
When they de-spawn due too the last LOD having too many verts, the debug turns red first and as soon as the threshold is hit the object AND the debug disappears.
This is different here though. They are not de-spawning due to vert limits as explained and shown above. The debug is still thre even though the object is not. And it all remains green because everything is within the “new” vert limits.
It will probably make modellers cringe but I had that problem with some objects on an airfield I created. They would not appear until I was almost on top of the airfield. I solved it by adding a narrow, invisible, uncollidable pole several times the height of the object to ‘claim’ a higher screen vertical percentage. Yes, cringe away, I remain pragmatic.
Curiously, is the issue present even without enabled “dynamic settings” in the graphics settings? I remember disabling “dynamic settings” was a workaround for another LOD issue in the past…
I have never had dynamic seettings turned on. It has nothing to do with settings. I have tried at an OLOD of 50, 100, 150, 200, you name it. They always despawn at the same time and they de-spawn before the LOD debug de-spawns which is the underlying issue here. The LOD debug still shows up (as green) as the model itself would still be perfectly fine to be rendered as it is within the vertex limit of its Screensize percentage limitation, yet it disappears for no apparent reason.
Then I assume you had no - or too few - LODs set up; or your last LOD was above the 1000 vertex limit. Every model will de-spawn if the last LOD is above 1000 verts in the LOD debug. But as shown above, this one doesn’t: It only has 400.
The pole trick you are referring to is something I already mentioned here:
But this should not be abused. Especially not if it is used to work around the LOD system.
When you use it you should do proper LODs first and only then add it to prevent it from despawning too soon. (and, of course, adjust the LOD swap screensizes accordingly. Otherwise they will swap way too late because the object is now bigger than it actually is…) But, then again, this is the exact point of this report. The fact that we should not have to do this.
This just lets the sim control the LODs. And the LOD1 is usually 60% the vertices of LOD0, with each remaining LOD at 25% of the previous vertices. This works for almost all scenery objects. LOD2 is usually so far away, it is just colored basic geometry. The Comp and Normals can usually be removed for LOD2 to the last LOD, and the last LOD can sometimes just be vertex coloring.
Sorry, but this is not how it should work… Just because others abuse a system and live with it doesn’t mean you should too…
But I have to admit I don’t quite understand why you bring this LOD XML here or what you are trying to show with it to be honest. I don’t know if you have seen what I have posted and written above, but the last LOD is and does exactly what you said. And, again, for the third time in this thread, the point is that the objects disappear at a Screensize of 0.7 or 0.4 (depending on the object) even though THEY FOLLOW ALL LOD RESTRICTIONS.
To show again what I mean: this particular model disappears at a SS of 0.58. If it was a single model it wouldn’t be an issue and not obvious as it is really small and not noticeable. But as shown above in my original post, when clustered together (as GSE and cars in a carpark usually are…) the popping becomes more than obvious.
and the LOD debug for it, even though the object has still disappeared, stays visible until a SS of 0.10
I am not saying the object must still be visible at such a low screensize as I do agree that this is useless, but it should not disappear until a screensize of at least 0.2 or 0.3 to minimise popping.
And, as also mentioned above, funnily enough the Object Level of Detail setting does not influence this behaviour in the slightest. No matter if you set it to 10, 50, 100, 200. They always disappear at the same screensize.
Thank your for your comments. Your solution was much the same, fool the sim into thinking the object is larger than it is. My objects have at least 4 LOD levels but I will have to go and check the vertices count of the lowest.
I agree with @MichaelWimma-RWProfiles, although there’s known workarounds to this problem. The problem shouldn’t exist at all if the system was working as it was supposed to.
The main issue here is that the objects are disappearing far too early, even with proper LODs and respecting the vertex count for screensize, where it shouldn’t happen.
The OP also mentioned that the LOD debug info still shows even when the object de-spawns, given an insight that the system is indeed not behaving correctly.
We should provide info, so the developers can take a look at this. Instead of finding workarounds that are not advised to be used by the developers themselves.
Without out making any personal judgement as to what should work, the process I outlined just works. And it is used for hundreds of Microsoft-created objects, as well as many Asobo-created objects.
The real problem with what the SDK writes is that it is fiction, as this thread indicates. My concern is that some struggling developers reading this thread may get lost in the complaint, without having direction as to how to fix their issue with disappearing objects at distance. I don’t consider what I wrote as a ‘work-around’. It replicates what hundred of assets that are currently being used in the sim as default scenery objects. For the benefit of devs reading this thread that are pulling their hair out over LODs and disappearing objects, I included the process that I find just works. I didn’t mean to argue the intent of the thread, but to offer my solution to a persistent problem that Asobo cannot resolve.
Which I all already outlined in the original post to begin with:
I wonder, though, where you get the information that Asobo cannot resolve this issue.
As far as I am concerned, we have not heard anything from Asobo on this particular issue in this thread yet. So if you have seen them saying they cannot fix this somewhere else, please let me know, as I am very curious as to why they would be unable to address this.
Apologies if this has mentioned here already, but I wonder if this is related to the “contribution culling” that occurs on top of the LOD system. There was a different dev post about landing gear of aircraft disappearing even without the LOD of the aircraft being used not changing. And this was the response from the devs:
As part of their response, they link to an older article that offers suggestions, one being using fake geometry.
Again, not sure if its the same as the issue posted here, but if so, would explain why the object, or part of an object, would disappear even with LODs being setup correctly.
This could in fact be related / the issue in question indeed. At least it would make sense. I mean as mentioned by myself in the OP and by Flappy, making the object bigger does “solve” (like mentioned before it doesn’t solve it it just works around an existing system) the problem of the objects disappearing. And since they said it is expected behaviour in the post you linked I now assume that there is indeed no intention of it being fixed, unfortunately. I would just like to understand why and the reasoning behind it. Not because I question or doubt it per se, but because I always like to learn more about game development in general.
I wonder how difficult it would be for the devs to implement a setting to allow the enable/disable of this culling system and let the LODs really behave like they should… another performance-related setting to allow the end-user control over performance vs quality.
