# Time Interval Ray Tracing performance

I found a very nice paper regarding Time Interval Ray Tracing for Motion Blur published in 2017. That was before RTX GPUs were on the market. I have a few questions about an optimal implementation and its performance.

Short introduction: I'm using the Vulkan api to raytrace outer space scenarios, like spacecraft docking scenarios. So the scenario has only one till max 10 spacecrafts, which are close enough to be visible. Each spacecraft is very detailed. It is optimized to only have the outer shell, so they have no geometry inside. The spacecraft geometries has up to 50.000 triangles each. And the scenario should be rendered in real-time (hopefully 60 fps).

Problem: So when using the Motion Blur algorithm linked above, The number of triangles will increase to factor *3 when only using two keyframes. These new triangles and their position / orientation will change from frame to frame. And each frame I have to store the new triangles to the Bottom-Level-Acceleration-Structure (BLAS). Do you guys see a performance problem here? So the idea is to use the render pipeline (from vertex- till geometry- shader) to create the 4D (3D + time) geometry on GPU. Rotations are the most problematic transformations. To have a good rotational movement, the number of keyframes need to be increased depending on the rotational speed and the exposure time. I think these keyframes need to be split into several BLAS (one BLAS for each keyframe transformation).

In case to fill the BLAS is no performance problem, I think the next problem could be to fire rays. When having fast camera movements or fast translating spacecrafts, a ray could hit a lot of primitives (triangles). Is this a performance problem? Usually the scenario is very simple. We are trying to generate the output image as realistic as possible, so the different blending functions are extremely interesting for us.

Questions:

1. How performant is filling the BLAS? (I thought about refitting acceleration structures, because the number of primitives will not change)
2. Is it better to use several BLAS for the same objekt in case of faster rotations and therefore several keyframes?
3. How performant is firing the rays?
4. Do I have enough performance to fire even more rays? Shadow rays, reflection / refraction rays, Photon mapping rays?
5. Did someone even tested the algorithm with a newer RTX graphics card? (For this project we will use a NVIDIA RTX3080)
6. Do you know other techniques which better fit to our scenario for real-time?

EDIT:

I added this self made image, just to show how I think this algorithm works...

When having both intersection points of a triangle, I can calculate the UV-coordinates and do texture lookup do get a very good motion blur effect. With this technology I can implement all kind of shutter for my simulated physical camera.

• You can use the standard integration of time if you want to avoid constructing additional triangles. It's the "worse" techniques they compare to (also they do not compare to dithered blue noise time sampling, which would severely improve the look of those, and would be fixed with a small blur), those introduce some noise, but do not require you to construct new triangles. If the motion of said spaceships can be represented through a linear transformation, then you don't even need to touch the blas, as you can instead apply the inverse linear transformation to the rays. Oct 27 '21 at 22:16
• @lightxbulb thanks a lot, can you link a paper? Oct 28 '21 at 13:05
• Assume that you transform your spaceship using a matrix $M(t)$ where $t \in [0,1]$. Then you can instead use the ray with origin: $(M(t))^{-1}(\vec{o},1)$ and direction $(M(t))^{-1}(d,0)$ to intersect the mesh. By sampling $t$ randomly in $[0,1]$ you get rays at different moments in time, and consequently motion blur. To make it easier to denoise the samples can be offset using the idea from the paper "blue noise dithered sampling". Oct 28 '21 at 19:23
• @lightxbulb 1st: Yes, the transformations are linear, so the geometry will only be translated and/or rotated. I am not sure if I understand your solution correctly... Is it correct, that with your solution I fire a lot of rays per pixel in time (10 for example) each image (each ray) is of cause correct, and later I blend the results to one image (like moving the object 10 times per image?). And to not have artifacts, I blur the 10 images? Do you have a paper for this technique? How many time steps are possible per frame to still have real time conditions? Oct 29 '21 at 8:33
• In a standard ray-tracer, you shoot rays from a pixel, and average their contribution. In what I am describing you shoot rays from a pixel and associate each ray with a time, and average. There are probably many papers on extensions of this, but it's ultimately just numerical integration over time. Oct 29 '21 at 9:35