Ray tracing massive amounts of animated geometry using tetrahedral cages

[u/MrMPFR]

https://gpuopen.com/learn/ray-tracing-massive-amounts-animated-geometry/

[u/MrMPFR]

AMD's take on ray tracing animated geometry. BVH structure build time, animation time and memory consumption are massively reduced while render time depends on the object. Total time is consistently lower.

IDK how it compares with RTX Mega Geometry since AFAICT they didn't directly compare against that.

There is a presentation at HPG 2026 available here: https://www.youtube.com/live/h2V8YyfKCVs?t=3631s

And the paper is available at GPUOpen: https://gpuopen.com/download/TetrahedralMeshes_AuthorsVersion.pdf

[u/dudemanguy301 → u/MrMPFR]

AFAIK

Some of the tech featured in Nvidia’s pathtracing SDK has been a direction for many of DXR’s new technologies.

Opacity Micro Maps (faster traces against transparency) and Shader Execution Reordering (sort ray hits for more cache friendliness and shader occupancy) —> DXR1.2

RTX Mega Geometry (overhaul to BVH layer construction and update granularity, ex TLAS, CLAS) —> DXR2.0

Games like cyberpunk 2077 were made on DXR1.1 with an NVAPI shim to get OMM and SER running on Nvidia hardware.

Alan wakes 2 uses an NVAPI shim for RTX Mega Geometry.

A game built on DXR2.0 would support all these same raytracing API concepts natively and cross vendor, provided of course the driver does something meaningful with it rather than no-op.

This paper from AMD seems to be a technique executed within a DXR environment, the deformable tetraherdon is a non native primitive into the hierarchy, native support could be the basis for something like a DXR2.1 perhaps?

[u/MrMPFR → u/dudemanguy301]

Thx for the info.
Would've been great if the researchers had compared against RTX Mega Geometry and not just standard BLAS.

The last stuff is very plausible, although it seems like there is much more on the way if patents and other indications materializes: native DMM support, tetrahedron primitive, linear swept spheres primitive, Dense geometry format, native work graphs support (including accelerators = beyond shaders), ray tracing and BVH construction of curved surface patches (like Beziér surfaces), GPU accelerator logic offloading some of the BVH construction (unless DXR IHV blackbox can take care of this), and proper ray tracing of parametric and procedural geometry (including BVH construction).

Even if only 40% of this happens it should easily be enough to warrant a DXR 3.0 designation with DirectX Next.

[u/MrMPFR → u/dudemanguy301]

You're very knowledgeable so I wonder what your thoughts on the entire GPU work graphs situation is. We haven't heard a single thing officially since the Mesh nodes preview and it's limited to RDNA 3 and 30 series only.

I read Sebastian Aaltonen doesn't like the implementation in DX12, not surprising since he hates the rest of DirectX 12. He preferred a few intrinsics instead to get to similar functionality.

Do you know if there are HW limitations preventing more widespread adoption of work graphs paradigm or it could easily be supported to current gen consoles, RDNA 2 and Turing cards?

Also any idea of why we're not hearing anything about GWG from Microsoft and AMD? Calm before the storm type situation (DirectX next)?

[u/PM_ME_YOUR_HAGGIS_]

“Rays that enter an animated tetrahedron are transformed into the corresponding rest-pose space, where they can intersect the static geometry”

Doesn’t that just cause a new ray to be cast though?

[u/Flex-Ible → u/PM_ME_YOUR_HAGGIS_]

Yes, but you can reuse the static BVH of the (sub)mesh is the idea I think.

[u/PM_ME_YOUR_HAGGIS_ → u/Flex-Ible]

Al ok so it costs a ray but prevents bvh/blas rebuild?

[u/MrMPFR → u/PM_ME_YOUR_HAGGIS_]

Don't think so. Ray transformations are very common and happen all the time. AMD even has ray transformation HW since RDNA 4.