-
Notifications
You must be signed in to change notification settings - Fork 276
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prioritize loading tiles near the center of the screen #424
Comments
Directions from #496
Dropping some notes around an implementation for potentially drafting a PR priorityCallbackTilesRendererBase priorityCallback : 3DTilesRendererJS/src/base/TilesRendererBase.js Lines 14 to 46 in 70c3268
Could add something like this as a final check, but the if/else cascade might mean some tests are never tested against. } else if ( a.__distanceFromScreenCenter !== b.__distanceFromScreenCenter ) {
// and finally tiles closest to the center should be prioritized for faster foveated rendering.
return a.__distanceFromScreenCenter > b.__distanceFromScreenCenter ? - 1 : 1;
} Would that make sense to have some hard tests which return +1/-1 like originally, but hten the final tests would return a sum of +1/-1? Something like if ( a.__depth !== b.__depth ) { ... }
else if ( a.__inFrustum !== b.__inFrustum ) { ... }
else if ( a.__used !== b.__used ) { ... }
else if ( a.__error !== b.__error )
else if (test) {
return (a.__distanceFromCamera > b.__distanceFromCamera) + (a.__distanceFromScreenCenter > b.__distanceFromScreenCenter)
} Compute __distanceFromScreenCenterWhere to compute this
or probably better, within
Where we could compute the __distanceFromScreenCenter similar to the way the 3DTilesRendererJS/src/three/TilesRenderer.js Line 902 in 70c3268
It would probably make sense to simply compute the distance of the tile boundingVolume center, projected onto the screen, and measure that distance to the screen center - rather than for example computing the tile bounding volume projection surface onto the screen, and decide that that metric should be the distance between that projection area and the screen center. DebugTilesRenderer load order" vizProbably exactly along the lines of 3DTilesRendererJS/src/three/DebugTilesRenderer.js Lines 333 to 341 in 70c3268
|
This is ok and it's already the case that most of the time the final conditions are not used.
We should compute some adjustment of screenspace error here based distance to the center so high error tiles are still prioritized - just less so if they're off on the edge of the screen. As just an example, something like |
This is how the cesiumjs codebase merges into a single priority metric different priorities: They store it on a base10 number which is composed of (from the Cesium3DTile.js code):
It uses two priorities for the foveated rendering, a boolean The most interesting bit are probably within the function isPriorityDeferred shows that actually, within a cone with radius given in screen space, tiles loading is not deferred, and then linearly increases between that cone limit and the screen limit. PS: interesting note in the Cesium3DTilesetBaseTraversal.js file
Plus all the foveated parameters on the Cesium3DTileset docs are interesting to understand how it's working under the hood. |
Related to #138
https://cesium.com/blog/2019/05/07/faster-3d-tiles/
The text was updated successfully, but these errors were encountered: