Next gen lighting technologies - voxelised, traced, and everything else *spawn*

this might be feasible only if you're willing to trade off the two not interacting with each other. Sounds a lot like what we have today already.

 

Why? Trace the same ray in each, see which one spits the closest hit and shade that.

 

At first though I think that's only going to work for primary rays I think. Once you get to bouncing that isn't going to work as well. You'd have to issue 2 rays for both for every single intersection. That's a lot of interaction between two objects and one BVH may not process as fast as the other and then you'd have sync points to consider. You're also double spawning rays for everything, sounds extremely heavy on bandwidth and you're going to wreck any sort of ray coherency you have.

 

Yeah, I'm assuming here that for the forseable future, games won't be doing multi-bounce anything, and also I also have the hunch most devs will land into deferred shading for RT hits, with even some steps of software driven ray buffering and clustering.

 

Sure, but neither triangle nor box intersection instructions may be available to shaders.
On AMD it might be, because shaders control outer traversal loop, they feed the intersection units with data. Question is how much of traversal logic and data processing is handled by shaders too. I can't make enough sense of TMU patent to be sure.

But we have to wait and see. Everybody now seems to be sure real HW matches TMU patent, but no confirmation on that? And even if, AMD could have added fixed function outer loop processing, ending up close to NVs RT cores.
Or they have both: FF processing and optional shader driven to support traversal shaders where needed.

Intels traversal shader paper proposes a best of both solution, where only certain nodes trigger processing intervention from programmable shaders, IIRC.
I think this makes sense. Because a ray box intersection instruction alone would not help much. Even without a special instruction we can do this faster than the loading of box coordinates from memory takes.
Triangle intersection is more complex, but still i guess HW RT would mean some hardwired BVH restrictions and processing to be effective enough.

 

No, in typical RT work, 80% of ray intersctions are against BVH node bounding boxes until we find some triangles, which then ar only 20 % of intersection tests. (randomly guessed numbers, depends on data)
So RTX has HW box intersection for sure.
And there likely is no difference between dynamic and static BVH while tracing.
We can optimize harder for static BVH build (SAH is expensive), but likely we also build dynamic BVH only once, using the same expensive optimization, and we keep the optimized tree structure static, but only refit the bounding box coordinates after animation.

So we have optimized precomputed bottom level BVH for everything. The myth 'tree building is too expensive for realtime' was never true.

This works for almost all things we see in games. Only a totally shape changing stuff like surface of fluid would require a full rebuild of BVH.

 

Office Corridor [UE4 / Real-Time Ray Tracing]
April 15, 2020

https://www.artstation.com/artwork/nQrD0X

 

https://github.com/GPSnoopy/RayTracingInVulkan

Yes you have reason maybe using lower precision from what this guy experiment find.

Probably faster than ray-triangle intersection on RTX.

 

I'm fairly sure that NV can expose box intersection results back to shaders if this will be needed and this will essentially work as its supposed to on RDNA2.

Isn't this more or less what is allowed by DXR 1.0 even?

 

https://computergraphics.stackexcha...r-voxel-grids-and-rtx-accelerated-ray-tracing

Here it seems, it is useful only when you use triangle after maybe it is the same on RDNA2.

EDIT: Sorry I was thinking maybe RDNA2 can accelerate intersection test with other things than triangle. Maybe this is false and exactly like describe here.

 

My bad I was thinking RDNA2 GPU can accelerate intersection test with other primitives than triangle, probably not the case at all...

 

My memory is horrible, but wasn't there specs where doing BVH testing had 2 different forms, with one being roughly half the rate perhaps even a third of the other? For the life of me, I can't remember if it was for Nvidia or if it was Triangles vs Boxes.

But for some reason it feels like there's still a lot of unknowns on AMD's RT despite having a patent or two about it. As with all things, feelings can easily be wrong.

 

I still have no experience with DXR, so i might miss some things and get some wrong. But if DXR had support fro traversal shaders, neither MS nor Intel would propose them as future addition.
But we could emulate it:
Use custom intersection shader boxes to trigger shader execution, and here we could just launch a new ray, eventually in another less detailed version of the scene.
The downside is probably: If we decide to keep the current lod, we still need to start a new ray from scratch, loosing the traversal work already done and needing to restart from the root.

Would make no sense yet. Which other primitive would be worth it? Nurbs? Catmull Clark subdiv? ... nothing of this became widely used in games runtime data, and all of it boils down to triangles anyways.
The only problem i see with current triangles in boxes is the black boxed relation between them. I want to keep the BVH static, but have access to box dimensions and triangles shape. And i want to disable leaf nodes, set the parent as the leaf instead and put low detailed triangles into it.
I'm sure both NV and AMD could support such options without any need to rebuild trees. No fancy traversal shaders would be necessary to allow dynamic detail.
But i'm requesting a feature although nobody (including myself) has such an advanced solution to the LOD problem yet. So far we could not solve it with rasterization, so requesting RT support for progressive mesh methods is far fetched at the moment, i have to admit

 

It's not only games that benefit from ray tracing acceleration

 

It would be at least useful for raytracing in Dreams probably or voxel based games.

 

Yeah, but movies using CC or Nurbs can convert their stuff to triangles (which they have to do anyways) and use RTX. Everybody happy, and NV will agree because their patch offerings never payed off.
For movie industry, 'triangles only' is surely no problem, but limited options about instancing might be, and ofc limited RAM.

Now with inline RT from compute, i guess it's possible to use RT HW to hit a bounding box, and then you could even use parallel algorithm to intersect your custom geometry.
The 'single threaded rays limitation' from DXR 1.0 seems gone. (IDK if it's possible to continue a ray that misses custom intersection, or if full restart is necessary - probably it's possible to continue.)
But could Dreams be traced efficiently just because it's technically possible? I wish i knew.
The problem is we inherit the divergence from the RT system: The hit points we get within our compute workgroup will be scattered across the scene. So parallel algorithms make no sense and we can just use the single threaded custom intersection shaders from DXR 1.0.
To improve this, we would need ray reordering in hardware to cluster all hits at a certain box together, but then we end up with low threads saturation in our CU. Probably nor really an improvement.

So if you ask me what's necessary to use RT for alternative geometry, the answer is the exact same as for my LOD requests: Having control over BVH construction and dynamic modification.
I do not need custom intersection instructions to intersect a ray with a sphere or box - that's super cheap with regular CUs already.

... still curious if Sony could offer more flexibility than MS plans to do. But MS can change their mind any time if necessary.

 

Even without RT hardware, I think so. SDF strikes me as similar to CSG is terms of mathematical resolving.

 

One question in my mind is that how willing are developers to spend time with low level api when even the high level API seems to be too much time(aka. money) to invest in? Does low level API even make sense until the higher level API use is widespread and there is widespread requests from many developers to add specific bits of programmability into the hw/api. These requests would likely come to public via gdc talks/post mortems/tweets where the big players would say hey we did this, its shipping, now we know we need x to make things that much better for next title.

This probably is one of those cases where evolution happens fairly slowly but surely. There is a starting point and things will get slowly better(faster, more programmable).

 

Depends on if they use SDF and CSG only for modeling, like mentioned in the old paper. I think so. Full scene SDF always sounds too memory costly. Compare with Claybooks restrictions about scene size and materials/texturing for example.
I may be wrong, but somebody said they moved back closer to the 'brick engine', also mentioned in the paper. This was voxels with volumetric content. HW RT could then be useful for finding those voxels. (I think they use those coarse voxel polys also for occlusion queries, which was why it was mentioned somewhere)

 

I'm not working in game industry,but i assume your concerns don't apply to most.
Smaller Indie teams use some U engine, and programming efford spent on U engine is shared by a whole lot of games. So it's worth it.
AAA Studios use their own engines. Few programmers in comparison to many artists. Hiring one programmer more to focus on RT won't hurt the budget, but helps to remain competive. So it's worth it.