Updating a BVH is expensive. Lots of work. Generally speaking acceleration structures like this are “do one large expensive computation upfront and then re-use the results”. And then you cast rays against it every frame.
The old school approach is effectively the same cost frame to frame. It doesn’t cost more to render frame 17 of an animation than frame 16 or 18.
In a sense your question is “why is one function more expensive than a completely separate and unrelated function”. And the answer is… because it is? It’s not a bad question. But you may not get a satisfying answer.
The method from the paper safes both, memory bandwidth and compute time. You animate and write (to memory) a way smaller number of vertices. You update a smaller (less memory bandwidth, less compute) BVH.
Comments
Updating a BVH is expensive. Lots of work. Generally speaking acceleration structures like this are “do one large expensive computation upfront and then re-use the results”. And then you cast rays against it every frame.
The old school approach is effectively the same cost frame to frame. It doesn’t cost more to render frame 17 of an animation than frame 16 or 18.
In a sense your question is “why is one function more expensive than a completely separate and unrelated function”. And the answer is… because it is? It’s not a bad question. But you may not get a satisfying answer.
As aek and dahart said, updating a BVH (refitting) is not expensive. If anything, it's bandwidth limited.
The challenge is minimizing the cost of (selectively) rebuilding.
The method from the paper safes both, memory bandwidth and compute time. You animate and write (to memory) a way smaller number of vertices. You update a smaller (less memory bandwidth, less compute) BVH.
That’s just another way of saying “updating a BVH is expensive therefore spend effort to minimize the amount of updating it”.
The fastest code is the code that never runs.
There’s a material algorithmic difference between rebuild and refit. Not sure if that point was clearly understood.