This seems like it could be inefficient for coherence reasons because of the pointer traversal, are there more efficient ways of storing a BVH to mitigate this problem?
YutianW
What's the use of closest.t here? It seems that we only update closest.t when it is a node leaf node. But if it is a leaf node, it will not make recursive calls and use closest.t again.
Oh_skr
Not so sure about this, but I don't think sorting would be very realistic, since the order of the primitives depends a lot on the origin and the direction of the ray. If we have a scene with a lot of different rays, we would keep a sorted list of primitives for each one of them.
anag
@YutianW, It seems like the use of closest.t is to make sure that the first general bounding box you hit is the only one that'd for sure contain the closest primitive. If the update of closest.t were still greater than the first hit with a different bounding box, then that other bounding box might have an even closer object than the one in the closer "box".
This seems like it could be inefficient for coherence reasons because of the pointer traversal, are there more efficient ways of storing a BVH to mitigate this problem?
What's the use of closest.t here? It seems that we only update closest.t when it is a node leaf node. But if it is a leaf node, it will not make recursive calls and use closest.t again.
Not so sure about this, but I don't think sorting would be very realistic, since the order of the primitives depends a lot on the origin and the direction of the ray. If we have a scene with a lot of different rays, we would keep a sorted list of primitives for each one of them.
@YutianW, It seems like the use of closest.t is to make sure that the first general bounding box you hit is the only one that'd for sure contain the closest primitive. If the update of closest.t were still greater than the first hit with a different bounding box, then that other bounding box might have an even closer object than the one in the closer "box".