We currently do not have a time frame for fixing the issue that you are referring to. I will check in with the rest of the development team - maybe we can address this bug in the near future. As always, we are happy to support your efforts in tackling this bug with a pull request. If you submit a pull request, I can ensure that it will be reviewed in a timely manner.
I am not aware of any special constraints for our tilesets that will ensure that the current implementation will work fine. Maybe other community members have suggestions?
As always, if you come across more details about this issue, feel free to post them on GitHub. Let me know if you have any other questions or concerns!
Well…ok. I think at some point tile traversal was definetely “prematurely optimized” with all kinds of foveated stuff when the actual -very- important skipLod optimization was left broken. I see what I can do, that is quite a complex part of the code.
It looks like my biggest problem with skipLod is that when rotating camera, it picks double tiles: desired one and the lowest LOD. So basically using it causes lowest LOD tiles flashing on screen every now and then.
I am trying a solution now where I will discard too low LOD-tiles as a “post pass” in selectTile and see if that helps… it would be more like a workaround to make the skipLod algorithm useable.
I have been working on this more and it really seems to enter to a “statistical domain”. There is no exact correct solution in how to estimate skipLod… Whenever a parent LOD tile needs to be shown there is a difficult trade off between already showing children and this parent tile.
For now, this has been the most critical part in my trials to fix this:
My best guess is that problem and solution is somewhere there.
This seems like a very hard problem to solve and it would be great to hear if anyone else has diven deep into this one? I find this maybe the best potential optimization to 3d tiles anyways and it could be well worth investigating.
I have not met all of the issues that are shown in the GIFs here:
The only one I am experiencing is the issue with 3rd animation, the photogrammetry. I am wondering if some of the issues with the current version only reproduce with tilesets with mixed refine modes ADD and REPLACE. My test material has only REPLACE refine.
So right now for me, the skipTileLods algorithm actually works quite well. But I can confirm that it does reproduce the bug seen in 8631 with the photogrammetry model => very low detail LOD tiles appearing accidentally.
Unfortunately I haven’t been able to fix the algorithm significantly but I have learned one thing, answering my original question:
“Are there any special constraints for tilesets where the current implementation would work fine?” => The best are tilesets where lower detail LOD levels are covered by the more detailed ones.
So, LOD a sphere using box like method 2, not 1. But this is a very difficult constraint to implement in real cases…
I think there is the quite complex attempt to address this using stencil buffer but as far as I understand at this point, that would cure this issue partially for photogrammetry tilesets but now very well for CAD geometry etc.
I find that quite complex bivariateVisibility test does not help at all in the material we are testing with (meaning only REPLACE refinement). So we disabled it and try to improve the simplified version. Edit: Obviously not because the code does not event enter there in this case Lets see… it really might be best to strip out all the complexity from the tile selection algorithm and then try to improve…
I am surprised that no one in Cesium is working on this. I find almost 2-3x performance improvement opportunity in this functionality and it would be very important for Cesium JS’s user experience.