|
It’s not always more expensive, but generally speaking for games and assuming some simplistic & straightforward approaches on both sides… 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. |