Difficulties to render multiple 3dtiles with shared queues in VR

[AnthonyGlt]

Description

I've opened this PR concerning the usage of shared queues on our project
iTowns/itowns#2579

We are meeting difficulties with the optimization of shared queues as defined here:
https://github.com/NASA-AMMOS/3DTilesRendererJS?tab=readme-ov-file#multiple-tilesrenderers-with-shared-caches-and-queues

And the VR workaround
#213 (comment)

The queues management is becoming a bit complicated.

Since the mentioned issue above, did you find a better way to handle the VR ?

Thank you :)

Reproduction steps

1. Share the downloadQueue and parseQueue
2. Use VR
3. Conflict in the queues management

Code

// code goes here

Live example

https://www.itowns-project.org/itowns/dev/examples/index.html#3dtiles_loader

Screenshots & Tile Set

No response

Library Version

0.4.7

Three.js Version

0.174.0

[gkjohnson]

Can you provide a description of what exactly the issue is? It's not clear from the linked issues.

[AnthonyGlt]

Thanks for the answer.
The issue is that we are sharing the cache and queues when have multiple renderer but we also have to overwrite the downloadQueue.schedulingCallback & the parseQueue.schedulingCallback of each renderer in VR environment:
https://github.com/iTowns/itowns/blob/adecc812efd6d3c0cf57cc5a2ed631ad83bc4d42/packages/Main/src/Layer/OGC3DTilesLayer.js#L326-L327

Which means that every renderer are sharing the same queues but also needs to have their own queue's schedulingCallback, it's conflicting.

In the example https://www.itowns-project.org/itowns/dev/examples/index.html#3dtiles_loader, you can see the issue by loading the tilesets, once a tileset is charged, you can't load a new one :/

I was wondering if you had a nice way of using shared queues and cache in a VR environment or some insights related to this.

[gkjohnson]

Which means that every renderer are sharing the same queues but also needs to have their own queue's schedulingCallback, it's conflicting.
...
you can see the issue by loading the tilesets, once a tileset is charged, you can't load a new one :/

Presumably this is because a "OGC3DTilesLayer" is removed but it's schedule callback is still being used but handled correctly any longer? I'm not following why each renderer needs to have it's own scheduling callback. If you are sharing a queue among multiple renderers then you should create the queues once and only assign the schedulingCallback in a single place to be handled independent of the update approach for the individual tile renderers. I think this can be fixed with some code reorganization.

But in general I agree that it's inconvenient that this doesn't "just work", though as discussed in the previous issue I'm not sure how to address it seamlessly. It's unfortunate that the browser doesn't have a global event to tap into that triggers on both rAF and XR rAF. But as suggested in #213 you could use setTimeout rather than rAF if you'd like to avoid depending on the animation frame logic. Or your app can provide a scheduling function that taps into xr rAF or window rAF depending on what's running.

A few other possible options that come to mind:

1. A second "setTimeout" callback with a long timer (50ms or so) could be added to the default scheduler in addition to the rAF call so that the scheduler will always run even when rAF isn't firing.
2. Add a "runJobs" function that users can run on their own that will cancel any scheduled callbacks so users can run the queues on their own timeline as needed. This would probably mean getting rid of the "schedulingCallback" option.

I'm not a huge fan of 1 since it will just look like data is loading more slowly if rAF isn't running. It can also already be implemented with the available callback. Users should really be encouraged to run the the queues on whatever rAF callback is available since that's the best kind of timing for the work being done here.