MantisBT
Mantis Bug Tracker Workflow

View Revisions: Issue #27590 All Revisions ] Back to Issue ]
Summary 0027590: Visualization, Ray Tracing - port to quad BVH trees (QBVH)
Revision 2016-10-27 23:10 by dbp
Description Currently, OCCT ray-tracing core (like many other render engines) uses binary BVH trees to accelerate ray-triangle intersection tests. However, binary trees have some drawbacks:

1/ Big height of the tree for complex scenes resulting in large stack size needed for BVH traversal. As we can see, stack size is one of the most critical points affecting performance of GLSL-based ray-tracing.

2/ Significant divergence of thread execution paths caused by many iterations over tree structure. At the same time, we are interested in maximum coherence of threads in order to keep GPU busy.

3/ Significant memory consumption of binary BVH. We need to store ~2N nodes for N primitives.

In view these considerations, it is reasonable to evaluate (and possibly to migrate) the quad BVH (QBVH) accelerating structure. This type of BVH is produced by flattening standard binary BVH (by leaving out intermediate levels). As a result, each BVH node contains up to 4 child nodes. In this way, we achieve a smaller memory consumption and favor thread coherency. However, the main challange here is to keep stack size equal to tree height. In conventional QBVH, we need stack of size 3H (where H is tree height) to store all potentially hit nodes. To overcome this limitation it is proposed to reserve few bits in node index in order to store additional information.
Revision 2016-06-10 13:06 by dbp
Description Currently, OCCT ray-tracing core (like many other render engines) uses binary BVH trees to accelerate ray-triangle intersection tests. However, binary trees have some drawbacks:

1/ Big height of the tree for complex scenes resulting in large stack size needed for BVH traversal. As we can see, stack size is one of the most critical points affecting performance of GLSL-based ray-tracing.

2/ Significant divergence of thread execution paths caused by many iterations over tree structure. At the same time, we are interested in maximum coherence of threads in order to keep GPU busy.

3/ Significant memory consumption of binary BVH. We need to store ~2N nodes for N primitives.

In view these considerations, it is reasonable to evaluate (and possibly to migrate) the quad BVH (QBVH) accelerating structure. This type of BVH is produced by flattening standard binary BVH (by leaving out intermediate levels). As a result, each BVH node contains up to 4 child nodes. In this way, we achieve a smaller memory consumption and favor thread coherency. However, the main challange here is to keep stack size equal to tree height. In conventional QBVH, we need stack of size 3H (where H is tree height) to store all potentially hit nodes. To overcome this limitation it is proposed to reserve few bits in node index in order to store additional information.


Copyright © 2000 - 2019 MantisBT Team
Powered by Mantis Bugtracker