Gprt vol tracing by Waqar-ukaea · Pull Request #205 · xdg-org/xdg

Waqar-ukaea · 2026-02-27T17:48:22Z

This PR adds all of the necessary setup to allow GPRT to perform ray tracing against volumetric (tet) meshes.

Changes:

Added all required GPRT setup/shader plumbing to handle construction of BVHs on tet meshes as well as shaders to trace against those BVHs
Added GPRTRayTracer::find_element() and updated test_find_element to test across both Embree and GPRT backends. Note - important to stress that this is a single ray dispatch version and an batch based dispatch will come in a later PR. Single dispatch versions do remain very useful for testing parity with Embree however.
For device side AABB population I have implemented a slang generic (equivalent to C++ templating) which will be nice for future PRs that add support for elements with differing numbers of nodes.
Restructured file structure for shaders to split triangle and tet shaders
Made plucker_tet_containment_test cross compatible between slang and C++. In doing so I have opted to make use of Cramer's rule rather than matrix inversion since I was having trouble with matrices between host and device. GPRT's double3x3 required implementing my own matrix inversion function and had a different row-column ordering compared to linalg's implementation.
Some minor QOL changes across GPRTRayTracer

It looks like a much larger PR than it really is since this PR also makes some structural changes to the file layout across shaders. Namely it splits shaders into three .slang files rt_common.slangh, triangle_rt_shaders.slang and tetrahedron_shaders.slang. So around 🟩 +180 additions and 🟥 −270 deletions are solely from moving the existing shaders for surface ray tracing into the new files.

Extra notes:

This is not an implementation of the full volumetric tracking algorithm we have in place that allows us to walk elements
But rather just all of the RT side BVH setup and shader setup to do element point containment checks against the BVH in find_element()
Since the PR for batch based array queries isn't in place this is just an initial attempt with each raygen shader launching a single ray.

I guess in theory should we ever need to actually perform ray tracing operations against tets it also allows for that (would just need to define a new custom intersection shader for double precision) but as far as i know there is no use case for this required by OpenMC?

…t_surface_connectivity()

…abstracted to MeshManager level

…get_volume_connectivity()

…rary numbers of vertices

… on push_back

pshriwise

A few thoughts and comments here.

One larger question: Where is the box expansion occurring in the GPRTRayTracer? I see the expansion using FLT_EPSILON in populate_aabb, but for larger volumes this expansion may not be enough to guarantee we don't run into false negatives when traversing the tree.

pshriwise · 2026-04-09T20:38:52Z

+                                  const dp::vec3 v2,
+                                  const dp::vec3 v3) {
+
+  // TODO - I've decided to use Cramer's rule here instead of matrix inversion to make it easier to implement a cross-compilable version of this function


In general this looks fine to me. In my branch for quads/hexes I've moved to a Plucker coordinate check against face and I might recommend we change to that broadly as it naturally extends to linear elements with an arbitrary number of faces, but I'm curious, what was incompatible in the previous version?

It's been a while, but I think the main issue was related to row/column convention differences between the matrix API used by GPRT/Slang and the linalg API used on the C++ side. The old method (still in main) was doing this matrix multiplication to solve for our barycentric coords:

// Solve T * [λ1, λ2, λ3] = rhs double3 lambda123 = mul(inverse(T),{rhs.x, rhs.y, rhs.z});

I initially tried to implement the same logic on the Slang side, but I got different barycentric coordinates on CPU vs GPU. My understanding is that the two math APIs were interpreting the matrix row/column ordering differently which was leading to differences when I would call mul(...).

I switched to Cramer's rule to avoid the matrix inversion and multiplication path entirely. That keeps the shared Slang/C++ implementation to just dot and cross products, which is easier to keep consistent across both C++ and slang.

I might recommend we change to that broadly as it naturally extends to linear elements with an arbitrary number of faces, but I'm curious, what was incompatible in the previous version?

Agreed, seems reasonable to move towards a more arbitrary method.

pshriwise · 2026-04-09T20:43:43Z


    // Ray Generation parameters
-    uint32_t numRayTypes_ = 1; // <! Number of ray types. Allows multiple shaders to be set to the same geometery
+    uint32_t numRayTypes_ = 2; // <! Number of ray types. 0=surface, 1=volume


Let's create a new enum for this property if there isn't one already.

Oh, I see there are some constants in shared_structs.h. Let's apply RT_NUM_RAY_TYPES here.

Oh, I see there are some constants in shared_structs.h. Let's apply RT_NUM_RAY_TYPES here.

Yeah, not sure what the best place for these would be since they're constants but will only ever be used inside of GPRTRayTracer and the slang shaders so it didn't feel appropriate to put them in constants.h. But open to suggestions on that front.

pshriwise · 2026-04-10T01:14:11Z

+    uint rayID = DispatchRaysIndex().x;
+
+    // There is some logic for handling next volumes inside the h5m-reader which I could make use of too
+    // TODO : Should the dblHit struct return the next volume ID for the ray back to the host


Responding to this comment randomly: We could do but I don't see a reason to necessarily. As long as we know what volume we're in and what surface was hit it's a really cheap operation to find the next volume and in the case of particle transport we may not use it if a collision will occur before the particle reaches that surface.

Makes sense. I'll remove this comment then.

pshriwise · 2026-04-10T01:17:50Z

+
+// ------------------------------------------------ CUSTOM INTERSECTION SHADERS ------------------------------------------------
+
+/* 1D ray generation intersection with a double precision triangle using the Plucker intersection algorithm*/


Sorry for the stray: The term "1D" threw me here for a sec.

Suggested change

/* 1D ray generation intersection with a double precision triangle using the Plucker intersection algorithm*/

/* Single ray generation intersection with a double precision triangle using the Plucker intersection algorithm*/

Agreed it is a little misleading. I've changed the comment to this in the latest commit:

// Custom FP64 Plucker ray-triangle intersection algorithm for each ray-triangle pair [shader("intersection")] void DPTrianglePluckerIntersection(uniform DPTriangleGeomData record) {

Waqar-ukaea · 2026-04-10T10:47:50Z

@pshriwise bb61bf6 addresses some of the comments you left. Most of the changes are self-explanatory, but i'll highlight one here:

I added a new shared_constants.h header so the shader code can use xdg::ID_NONE instead of hard-coded -1 values as you suggested. constants.h currently pulls in C++-only dependencies so it cant be included directly in the Slang shader path so I made a new header shared_constants.h which doesn't contain any C++ specific stuff.

I also moved the enums from shared_enums.h into that header and removed the old shared_enums.h.

A couple of small syntax changes were needed to keep the header Slang-compatible: constexpr was replaced with static const, and brace initialization like MeshID ID_NONE {-1} was replaced with MeshID ID_NONE = -1.

Waqar-ukaea · 2026-04-10T11:28:23Z

One larger question: Where is the box expansion occurring in the GPRTRayTracer? I see the expansion using FLT_EPSILON in populate_aabb, but for larger volumes this expansion may not be enough to guarantee we don't run into false negatives when traversing the tree.

I see your point, this is missing from GPRT atm and we only do the FLT_EPSILON expansion you saw. I'll think about how best to handle this and get a separate PR up for it once I figure it out

pshriwise · 2026-04-12T04:03:17Z

+#ifndef XDG_SHARED_CONSTANTS_H
+#define XDG_SHARED_CONSTANTS_H
+
+namespace xdg {


As discussed live this week, probably best to avoid changing the infrastructure too drastically to accommodate slang. Sorry for the mislead here.

No problem! I'll revert back to what I had before

pshriwise

A few more thoughts as I look over this today.

pshriwise · 2026-04-13T14:24:28Z

    // Geometry Type and Instances
    std::vector<gprt::Instance> globalBlasInstances_; //<! List of every BLAS instance stored in this ray tracer
    GPRTGeomTypeOf<DPTriangleGeomData> trianglesGeomType_; //<! Geometry type for triangles
+    GPRTGeomTypeOf<DPTetrahedronGeomData> tetrahedraGeomType_; //<! Geometry type for tetrahedra (not currently supported)


Not currently supported?

pshriwise · 2026-04-13T14:25:03Z


    // Ray Generation parameters
-    uint32_t numRayTypes_ = 1; // <! Number of ray types. Allows multiple shaders to be set to the same geometery
+    uint32_t numRayTypes_ = RT_NUM_RAY_TYPES; // <! Number of ray types. 0=surface, 1=volume


Let's remove the values in the comments here lest they change in the code itself and we forget to update the values here.

pshriwise · 2026-04-13T15:43:51Z

+  const double barycentric_min = -dp::PLUCKER_ZERO_TOL;
+  const double barycentric_max = 1.0 + dp::PLUCKER_ZERO_TOL;
+


It seems like these could be compile-time constants, no?

pshriwise · 2026-04-13T15:57:15Z

  int volume_tree; // TreeID of the volume being queried
-  SurfaceAccelerationStructure volume_accel; // The volume accel 
+  SurfaceAccelerationStructure volume_accel_surf; // The volume accel for surface acceleration structure
+  SolidAccelerationStructure volume_accel_solid; // The volume accel for solid acceleration structure


The use of solid here feels a little off. What about "ElementAccelerationStrucutre"?

I do agree but both SurfaceAccelerationStructure and SolidAccelerationStructure are types defined in GPRT here - https://github.com/gprt-org/GPRT/blob/master/gprt/gprt_builtins.slang

So I would need to put in a PR to make the name change upstream to make that change

Or I suppose I could typedef them here locally in XDG to have that extra consistency with the naming scheme we have.

Ah, I missed that. Thanks for clarifying. typedef's sound reasonable to me. I think it would help with readability and allow us to use consistent terminology. Let's try it on.

Waqar-ukaea · 2026-04-21T14:07:41Z

One larger question: Where is the box expansion occurring in the GPRTRayTracer? I see the expansion using FLT_EPSILON in populate_aabb, but for larger volumes this expansion may not be enough to guarantee we don't run into false negatives when traversing the tree.

This has now been addressed in #222 and I recommend that #222 PR is merged before this PR is so that I can rebase those changes properly into this branch first.

Waqar-ukaea added 15 commits March 19, 2026 09:11

Implemented MeshManager level versions of get_surface_vertices() + ge…

5a4f31a

…t_surface_connectivity()

Refactored get_volume_vertices() and get_volume_connectivity() to be …

1c39076

…abstracted to MeshManager level

Some more cleanup

a17d5db

Refactored tests for MOABMeshManager::get_surface_connectivity() and …

c89e498

…get_volume_connectivity()

Added method to return dense array of a volume's connectivity indices

af11f4a

Started on implementing volumetric element tree BVH construction in GPRT

4d080ad

Restructured slang shaders in preparation for new tet shaders

3eeaab4

Added the required shaders for find_element on GPU

afb6334

Added rest of plumbing to make find_element work with GPRT and 1 ray

af36622

Extended find_element test to also test with GPRT backend

63a57c6

Added a new slang __generic that populates AABBs for objects of arbit…

56c2987

…rary numbers of vertices

Changed a constant to be static const to be slang compliant

874c389

Made plucker_tet_containment code cross-compatible between C++ and slang

ac2b0f8

Switch to pre-allocate arrays in BVH construction rather than relying…

342d07e

… on push_back

Rebased to latest main

ac4c7f3

Waqar-ukaea force-pushed the GPRT-vol-tracing branch from 5f20f5b to ac4c7f3 Compare March 19, 2026 09:18

pshriwise requested changes Apr 10, 2026

View reviewed changes

Addressed comments and created new shared_constants.h header

bb61bf6

pshriwise reviewed Apr 12, 2026

View reviewed changes

Reverted change to constants

ace02e9

pshriwise requested changes Apr 13, 2026

View reviewed changes

Waqar-ukaea added the GPRT GPRT specific changes which have no effect on the existing Embree interface label Apr 14, 2026


		// ------------------------------------------------ CUSTOM INTERSECTION SHADERS ------------------------------------------------

		/* 1D ray generation intersection with a double precision triangle using the Plucker intersection algorithm*/

	/* 1D ray generation intersection with a double precision triangle using the Plucker intersection algorithm*/
	/* Single ray generation intersection with a double precision triangle using the Plucker intersection algorithm*/

		const double barycentric_min = -dp::PLUCKER_ZERO_TOL;
		const double barycentric_max = 1.0 + dp::PLUCKER_ZERO_TOL;

Uh oh!

Conversation

Waqar-ukaea commented Feb 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Changes:

Extra notes:

Uh oh!

pshriwise left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Waqar-ukaea commented Apr 10, 2026

Uh oh!

Waqar-ukaea commented Apr 10, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pshriwise left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Waqar-ukaea commented Apr 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Waqar-ukaea commented Feb 27, 2026 •

edited

Loading

Waqar-ukaea commented Apr 21, 2026 •

edited

Loading