what is it about raytraced animation that makes it more expensive to update the BVH mesh vertices every frame, compared to old-school bone animation where you send the info to the vertex shader every frame?
I'm going to answer this in two parts.
First, you absolutely can update the BVH, keeping the tree topology the same, and just updating the internal bounding as the triangles and other primitives move around. It's essentially a bottom-up walk of the tree where you figure out where the triangles now are, update the bounding boxes to contain them tightly, then update the boxes of the parent nodes, then the parents of those parents, etc., all the way back up to the root node of the tree. The tree structure stays the same and the bounding boxes around each node just update. This is often called "refitting", as you just refit the bounding boxes around everything in the tree below them like a rubber band.
For simple animation where things only move slightly between frames, this works just fine. And if you're using the DirectX Ray tracing (DXR) API, you can do this via what it calls "acceleration structure updates" [1]. You have to tell the API that you plan to do this when you first build the BVH, and then pass another flag when you actually do it. And there are rules that you have to keep the triangles, the same and only move the vertices. But you can do it pretty easily. And in fact, it's usually nice and fast, often much faster than building a BVH from scratch.
Where it can fall apart, however, is in the performance of the ray tracing itself. As a super-simple example, let's say we have a little BVH of three triangles (A, B, and C) and three nodes (1, 2, and 3), something like this:
+-------------------------+
|1 +-----+|
| |3 * ||
| | /C\ || 1
| |*---*|| / \
| +-----+| 2 3
|+---------+ | / \ \
||2 * *---*| | A B C
|| /A\ \B/ | |
||*---* * | |
|+---------+ |
+-------------------------+
+-------------------------+
|1 +-----+|
| |3 * ||
| | /C\ || 1
| |*---*|| / \
| +-----+| 2 3
|+-----------------------+| / \ \
||2 * *---*|| A B C
|| /A\ \B/ ||
||*---* * ||
|+-----------------------+|
+-------------------------+
Instead, for something like the above, you'd want a tree that looks more like this:
+-------------------------+
|1 +-----+|
| |3 * ||
| | /C\ || 1
| |*---*|| / \
| | || 2 3
|+-----+ | || / / \
||2 * | |*---*|| A B C
|| /A\ | | \B/ ||
||*---*| | * ||
|+-----+ +-----+|
+-------------------------+
Now, the second part of my answer. There are 580 million triangles in the paper's demo video. Even if you only refit and never rebuild the BVHs, updating all of those vertices for animation is going to be prohibitively expensive. (And even just doing the bone animation for the vertices for 580 million triangles might be too costly, let alone the BVH updates.)
So what's happening here is a bit of cheating. A coarse grid of tetrahedra (2 million in this video) are built around the model in rest pose, and for each tetrahedra, the triangles contained in it or touching it are determined. Then just those tetrahedra are animated and the BVHs around them updated/rebuilt. When a ray intersects an animated tetrahedron, the ray is warped back to where it would be relative to the rest pose and intersected against against the triangles that tetrahedron touches, using a little micro BVH. (I should note that this sort of "warp the ray" idea is pretty common in ray tracing. It's how instancing works so cheaply, for example.) If you look at the paper itself [2], you can see an illustration of the tetragedral grid in Figure 2 and the ray warping in Figure 5.
But the point of the paper is that after all the initial setup, it's faster to update the BVH for those 2M tetrahedra than it is for 580M triangles, or whatever ratio you choose to use. You can choose the ratio depending on how approximate and fast or faithful and slow you want the animation cost to be (by how coarse or fine the tetrahedral mesh is, respectively), but the point is that it lets you decouple the BVH update costs from the triangle count.
[1] https://microsoft.github.io/DirectX-Specs/d3d/Raytracing.htm...
[2] https://gpuopen.com/download/TetrahedralMeshes_AuthorsVersio...
In some exercises most of the scene was made up of soft body objects containing millions of triangles which could be deformed and even destroyed - cutting any random edges.
The simulation was handled by creating a coarser mesh of tetrahedra which were treated as deformable physical objects and skinning the triangles to these. Cutting simply removed entire tetrahedra and the triangles were reskinned to the nearest one or simply removed if none were close enough.
[1] https://www.highperformancegraphics.org/2026/schedule/
[2] https://dl.acm.org/doi/10.1145/3820013
[3] https://www.youtube.com/live/vTUdO2A73i0?si=Hy6zle7EtWp7rL60...
With raster, you don’t necessarily have a BVH to update, you evaluate your rig, e.g., bone animation, which means re-calculating all the vertices in your animated object/character, and then drawing the resulting mesh.
With ray tracing, you have to evaluate the rig (do everything above) and then also update the BVH, so the BVH update is extra. It’s also sometimes expensive because if you rebuild a BVH from scratch, that means sorting the triangles, sometimes multiple times. You can sometimes get away with a BVH “refit” for animated stuff, which is faster, but has tradeoffs. Even in the best case, you still have to read all the animated verts a second time after computing them, which costs memory bandwidth.
Sometimes games with raster engines do have a BVH, but it’s likely to be a small BVH over objects in the scene, whereas ray tracing usually builds a large BVH over triangles and is a much bulkier acceleration structure.
BTW, the linked paper here saves on both rig evaluation and BVH rebuild - in other words, this would help save time even if you weren’t ray tracing. This is essentially building a lattice rig so you don’t have to do the bone animation. Assuming the lattice rig has fewer verts than the bone rig, you save on rig evaluation time. It’s also meant to build a smaller BVH - you need a BVH over the lattice cells, and the BVH inside each lattice cell can stay static and contain multiple triangles. Only the lattice moves, and you only need to update the lattice BVH, so the ratio of lattice cells to triangles in the lattice gives you the approximate BVH build speedup.
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 challenge is minimizing the cost of (selectively) rebuilding.
The fastest code is the code that never runs.
If I understand correctly this really isn't a thing anymore. Instead most modern engines copy the original vertices to a temp or skinned vertex buffer with a compute shader and then use normal non-skinned rendering techniques to display them. This means you don't need 2 copies of every shader, one with skinning and one without so less combinations.
That doesn't change the other answers to your question.
apart from all the updates and acceleration structures you have to do, you are also battling cache coherency during ray traversal, or as the saying goes: Primary rays cache, secondary trash.