<p>As you said, the RTX Turing architecture comes with wired primitive-ray intersection, (to be more specific, triangle-ray intersection). The BVH is built by specifying the Bounding Box program to OptiX, the signature of which is:</p>

<pre><code>RT_PROGRAM void my_boundingbox_build_program( int, float result[6] )
</code></pre>

<p>As you can guess, the result must contain the minimun (3 first components) and maximum (3 last components) bounds of the bounding box. You can use this to build virtual bounding boxes even if you have no geometry (for instance, a chunk of 16x16x16 voxels).</p>

<p>When you perform <code>rtTrace</code> , the OptiX API will detect the collision through the BVH which it has build with the help of your bounding box program. In that momment, it will call the Intersection program, which you can specify and which signature is:</p>

<pre><code>RT_PROGRAM void my_intersection_program( int prim_index )
</code></pre>

<p>Where you will report any possible intersection within your 16x16x16 chunk of voxels (obviously you can ignore the prim_index, which is only useful when using geometry primitives). </p>

<p>Now, if you would use their special structure <code>RTgeometrytriangles</code> , the Turing RTX architecture would be able to make use of the wired primitive intersection, which is where performance boost would be gained, and you would not need to implement your own intersection program.</p>

<p>To sumarize:
Since you are not using the specific <code>RTgeometrytriangles</code> , you will not access the intersection performance boost from the Turing architecture.</p>

CC BY-SA 4.0
2019-07-26T14:36:58.483Z
2019-07-26T14:36:58.483Z
Nadir
<p>I've been looking to play with ray tracing, starting with a simplest of minecraft clones (making something more akin to <a href="https://www.youtube.com/watch?v=NEwKBy3babgg&amp;usg=AOvVaw3X91bRH8o8Sxdz7jZIuyLt" rel="nofollow noreferrer">cave game</a>, for starter). </p>

<p>I figured I'd define a voxel as a primitive and then use the regular voxel grid to trace the rays. I don't need to test (look) for intersections here, I can precisely calculate them, tracing the ray voxel by voxel.</p>

<p>However, I do have an RTX card which does accelerate ray tracing with dedicated hardware, and I may be able to get faster results if I were to leverage it.</p>

<p>From what I gathered, one of the components of the RTX system (or any ray tracer, really) is an acceleration structure that speeds up the process of testing for intersections.</p>

<p>You give the card an octree or a BVH (or something similar) and it uses it to quickly find the closest hit (or any other hits, for that matter).</p>

<p>If I'm not mistaken, the hardware accelerated part here is the hit test. It's power is in the ability to test many primitives against one or more rays in a very short amount of time.</p>

<p>Given the method I'm using for ray tracing, that is the one part that I don't really need, since I don't need to search for which primitives the ray intersects (I calculate them explicitly), I just need to check where the intersection on them is.</p>

<p>Am I wrong? Can the architecture be used to accelerate what I'm doing?
If so, is it due to the fact that I misunderstood how it works, or can I adapt my plan in order to make it more friendly to the architecture, making the resulting plan faster than the original?</p>

<raytracing><voxelization>
Regular voxel grids and RTX accelerated ray tracing
Karlovsky120
# Regular voxel grids and RTX accelerated ray tracing

(Asked by: username_0 on 2019-07-23)

I've been looking to play with ray tracing, starting with a simplest of minecraft clones (making something more akin to [cave game](https://www.youtube.com/watch?v=NEwKBy3babgg&usg=AOvVaw3X91bRH8o8Sxdz7jZIuyLt), for starter).

I figured I'd define a voxel as a primitive and then use the regular voxel grid to trace the rays. I don't need to test (look) for intersections here, I can precisely calculate them, tracing the ray voxel by voxel.

However, I do have an RTX card which does accelerate ray tracing with dedicated hardware, and I may be able to get faster results if I were to leverage it.

From what I gathered, one of the components of the RTX system (or any ray tracer, really) is an acceleration structure that speeds up the process of testing for intersections.

You give the card an octree or a BVH (or something similar) and it uses it to quickly find the closest hit (or any other hits, for that matter).

If I'm not mistaken, the hardware accelerated part here is the hit test. It's power is in the ability to test many primitives against one or more rays in a very short amount of time.

Given the method I'm using for ray tracing, that is the one part that I don't really need, since I don't need to search for which primitives the ray intersects (I calculate them explicitly), I just need to check where the intersection on them is.

Am I wrong? Can the architecture be used to accelerate what I'm doing?
If so, is it due to the fact that I misunderstood how it works, or can I adapt my plan in order to make it more friendly to the architecture, making the resulting plan faster than the original?

**Tags:** raytracing, voxelization


---

## 1 answers

### Answer by username_1 on 2019-07-26. Score: 4 | Accepted answer

As you said, the RTX Turing architecture comes with wired primitive-ray intersection, (to be more specific, triangle-ray intersection). The BVH is built by specifying the Bounding Box program to OptiX, the signature of which is:

```
RT_PROGRAM void my_boundingbox_build_program( int, float result[6] )

```

As you can guess, the result must contain the minimun (3 first components) and maximum (3 last components) bounds of the bounding box. You can use this to build virtual bounding boxes even if you have no geometry (for instance, a chunk of 16x16x16 voxels).

When you perform `rtTrace` , the OptiX API will detect the collision through the BVH which it has build with the help of your bounding box program. In that momment, it will call the Intersection program, which you can specify and which signature is:

```
RT_PROGRAM void my_intersection_program( int prim_index )

```

Where you will report any possible intersection within your 16x16x16 chunk of voxels (obviously you can ignore the prim\_index, which is only useful when using geometry primitives).

Now, if you would use their special structure `RTgeometrytriangles` , the Turing RTX architecture would be able to make use of the wired primitive intersection, which is where performance boost would be gained, and you would not need to implement your own intersection program.

To sumarize:
Since you are not using the specific `RTgeometrytriangles` , you will not access the intersection performance boost from the Turing architecture.


---

