Ray tracing massive amounts of animated geometry using tetrahedral cages
1–10 of 20 posts
Re: Ray tracing massive amounts of animated geometry using tetrahedral cages
#2what 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?
Re: Ray tracing massive amounts of animated geometry using tetrahedral cages
#3what 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?
To make ray tracing practical, you need to update the ray-tracing accelerating structures when you animate.
Re: Ray tracing massive amounts of animated geometry using tetrahedral cages
#4what 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?
Massively simplifying here but when doing one rasterization pass you process a flat list of triangles, in order, once. When raytracing a camera view you query a database of triangles, at least once for each pixel. To avoid scanning the whole list of triangles for every pixel, the database needs a fancy 3D spatial index whose structure depends on the exact position of each vertex. When you modify the position of vertices you have to fix up or rebuild the fancy spatial index too.
Re: Ray tracing massive amounts of animated geometry using tetrahedral cages
#5Cool technique!
Re: Ray tracing massive amounts of animated geometry using tetrahedral cages
#6what 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?
it's a global visibility problem, unlike rasterization which is a mostly localized problem.
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.
Re: Ray tracing massive amounts of animated geometry using tetrahedral cages
#7For anyone who – like me – was hoping for a video to see what it looks like:
Re: Ray tracing massive amounts of animated geometry using tetrahedral cages
#8what 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?
> compared to old-school bone animation where you send the info to the vertex shader every frame?
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.
Re: Ray tracing massive amounts of animated geometry using tetrahedral cages
#9what 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?
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.
Re: Ray tracing massive amounts of animated geometry using tetrahedral cages
#10what 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?
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.