skipLevelOfDetail?

CesiumJS
1

Hi!

Is there any estimate when this will be fixed:

Or are there any special constraints for tilesets where the current implementation would work fine? Skipping level of detail tiles would be very important for loading performance.

Or would anyone have a sandcastle link where the possible bug with skipLevelOfDetails occurs consistently? I have seen it failing mainly this way:

  • When camera is moving, some tiles fall back to the most low-detailed LOD accidentally
2

@v12424124_34

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!

Best,
Sam

3

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.

1 Like
4

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.

image

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.

5

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. :slight_smile:

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.

6

@v12424124_34

Thank you very much for continuing this discussion with a follow-up post. I think you have narrowed down the problem. Let’s keep this thread open for more discussion.

-Sam

7

Couple of more notes on this:

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… :slight_smile:
image

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.

1 Like
8

Next note:

  • 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 :slight_smile: 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.

9

Final note, hopefully:
One very simple fix seems to greatly improve the skipLod loading behaviour: Do not fallback to ancestor LOD tile if camera is inside the ancestor.

This seems to make current algorithm “good enough” for us, but lets see if this holds after more testing.

2 Likes
10

@sam.rothstein is this issue documented anywhere in the api docs? We haven’t seen much of an issue having skipLevelOfDetail enabled until recently, where it took us a few hours to figure out that this was the issue.

Could this be documented here: Cesium3DTileset - Cesium Documentation

As there is no mention of the possibility of artifacts when having this enabled in the docs.

Also, is this being actively worked on? We’ve seen a significant decline in performance now this has been disabled. It would be great if a fix is on its way.

Thanks,
Tom

11

Hi!

Would you have any images to post how this bug affects the visualization you are doing? To my knowledge this is still a remaining issue and I have not seen that much development on this.

We were able to workaround some of the problems in our use case by using the ideas mentioned here.

12

Hey,

Thanks for looking into this, we’re seeing the first and third image, mainly the third one, from this issue you linked earlier:

Would be great to see this being worked on since it looks like this has been around for a while now

13

Those are the same issues we saw. Is it correct for your case also that the image eventually settles and has no error? For us at least I think this happens only when camera is moving. Once stopped, the lodding does correct itself.

It would be good to know also if you are using ADD or REPLACE refinement in your tilesets? I quess this whole issue applies to REPLACE more…

14

It does take a while for it to disappear, sometimes it doesn’t go away at all, It goes away quicker if you pan the camera slightly, but it comes back just as quickly as it disappears so we had to resort to disabling skipLOD.

We’re using the ion on-premise tiler, which seems to use replace as the refinement method.

15

I made this sandcastle to reproduce the original problem:

I think with that tileset it is not possible to end up in broken static frame - the issue is only visible when moving. Are you using “requestRenderMode”?

16

One other idea:

tileset.skipLevelOfDetail = true;
tileset.immediatelyLoadDesiredLevelOfDetail = true;

Setting immediatelyLoadDesiredLevelOfDetail reduces the skip-artifact, but of course makes the tile loading quite different as well… But who knows, in some use cases that could work?

17

Yes we had immediatelyLoadDesiredLevelOfDetail set to true already, some models seemed to work fine, or the artefacts were minimal so it was worth having them over the render time reduction, but we now have a couple of models where the artefacts are so bad we’ve had to disable skipLOD.

No we’re not using request render mode, this is on our road map but we need to update our state management prior to implementing this - have you seen a difference using the request render mode?

18

“No we’re not using request render mode, this is on our road map but we need to update our state management prior to implementing this - have you seen a difference using the request render mode?”
=> No we have not. It has not have effect to this issue really.

Do you think the issues you are seeing reproduce with the “original sandcastle” I posted? I have been thinking trying some of the fixes to Cesium master head branch and see if they would help anything…

19

Yep they do, tried on multiple versions of cesium with varying configs, whenever skipLOD is true the issue occurs

20

Hi @v12424124_34 , did you end up getting anywhere with this? I’ve got some time to take a look at this now - although I was hoping this would be fixed by now for something which seems like such a big performance gain. We’re having some pretty big issues with tilesets stored far away, e.g. stored in Australia and accessing from the UK. When skipLOD is false it’s very slow to load, when skipLOD is true it’s rapid - but the artefacts can be severe in some tilesets, so we would really like this fixed now.

Have you learnt anything that could help me when I take a look at this? Looks like there has been some work on tile traversals, i.e. base & skip are now in separate classes.

It may be though that tiles 1.1 use a different traversal algo due to implicit tiling which is why this hasn’t been worked on?

Cheers