When #543 is merged, we will support a transition period where tiles from the original and target LOD are both kept alive. A parameter representing the fade percentage is swept throughout the period so that clients know how faded to render each tile. To achieve this evolving fade percentage, a new deltaTime parameter was added to Tileset::updateView to decide how much to change the fade percentage based on how much time had elapsed since the last frame.
However, the way updateViewOffline works is it repeatedly calls updateView until there are no tiles that are still loading. This seems awkward with the new deltaTime argument, since an individual call to updateView doesn't have a sensible delta time that could be associated with it. We should find a way to support lod transition periods for offline tile selection as well (e.g., a client might use it to smooth transitions in a high-res offline render). This might require one of the following approaches:
Decouple the transition code from the traversal itself so that the traversal can run back-to-back several times and the transition can be applied afterwards. This might require managing further state information to track the result of not just a single traversal, but a sequence of traversals.
Or we can reimplement updateViewOffline to work with a single BVH traversal, by parameterizing the traversal to "demand" the ideal resolution tiles by blocking and waiting, instead of kicking and "settling" for lower-res tiles.
When #543 is merged, we will support a transition period where tiles from the original and target LOD are both kept alive. A parameter representing the fade percentage is swept throughout the period so that clients know how faded to render each tile. To achieve this evolving fade percentage, a new
deltaTime
parameter was added toTileset::updateView
to decide how much to change the fade percentage based on how much time had elapsed since the last frame.However, the way
updateViewOffline
works is it repeatedly callsupdateView
until there are no tiles that are still loading. This seems awkward with the newdeltaTime
argument, since an individual call toupdateView
doesn't have a sensible delta time that could be associated with it. We should find a way to support lod transition periods for offline tile selection as well (e.g., a client might use it to smooth transitions in a high-res offline render). This might require one of the following approaches:updateViewOffline
to work with a single BVH traversal, by parameterizing the traversal to "demand" the ideal resolution tiles by blocking and waiting, instead of kicking and "settling" for lower-res tiles.