wonder-sk
commented
3 years ago I have looked at how potree does the rendering and it should be as follows:
- octree is traversed in the order of screen space size of nodes (similar calculation to what we have in
screenSpaceError, using bounds of each node) - i.e. first visiting nodes that are covering larger screen are before visiting others covering smaller screen area - traversal stops when:
- node does not intersect view frustum
- number of points to be shown has reached point budget
- projected size of the node is too small
What we have in QgsChunkedEntity is similar, with two differences:
- we do not have a point budget yet (it would be useful also for mesh-based data to limit screen complexity)
- we do traversal in depth-first order
In order to implement point budget support, we should probably also change the traversal order, otherwise the scenes may not be rendered well when the point budget limit is hit.
Other consideration is that point (or triangle) budget should be ideally defined for the whole scene, and then somehow split among the individual 3D renderers... but probably it will be good enough if in the beginning each chunked entity would have its own (constant) budget.
NEDJIMAbelgacem
The current screen space error approach to thin point clouds works well for sparse point clouds, but doesn't assist with the rendering performance of very dense point clouds. This means a dense point cloud of a confined area (say, a building or a tree) can easily result in all the points from the dataset being rendered in a 3d view.
We should investigate if we can change the thinning approach to a "max point density" type approach to aid with these point clouds.