GART: Games and Applications using RayTracing

Status
Not open for further replies.
Seems clever. From their own provided tests, the difference is negligible. The simplified scene representations can look quite horrid when shown directly, but as I understand it, they are only used for very long rays from very diffuse reflections. Sharp mirror-like reflection rays and ones that traveled short distances will still retrieve data from the full resolution polygon representation of the scene, no?

The problem is that AABB is not ideal for approximating actual geometry shape. AABB's size can be vary depending on the transform of the instances even for a single geometry. What about thin, long pipe orienting 45 degree?
For AO rays that requires exact ray length information, skipping hit test on an actual primitive/triangle and early terminating on a large AABB makes the scene overall dark. Almost all test scenes in the paper represents this problem clearly.
 
The problem is that AABB is not ideal for approximating actual geometry shape. AABB's size can be vary depending on the transform of the instances even for a single geometry. What about thin, long pipe orienting 45 degree?
For AO rays that requires exact ray length information, skipping hit test on an actual primitive/triangle and early terminating on a large AABB makes the scene overall dark. Almost all test scenes in the paper represents this problem clearly.

True. The ideal world is having a hierarchical LOD chain ala Nanite available to the Ray traversal scheme. Abusing the Bounding Box Hierarchy as a poor-man's LODing primitive is more of a dirty hack using what the tools that the limited and restrictive current DXR implementation affords devs.

Dirty, hacky, cheap, but still clever.
 
The problem is that AABB is not ideal for approximating actual geometry shape. AABB's size can be vary depending on the transform of the instances even for a single geometry. What about thin, long pipe orienting 45 degree?
For AO rays that requires exact ray length information, skipping hit test on an actual primitive/triangle and early terminating on a large AABB makes the scene overall dark. Almost all test scenes in the paper represents this problem clearly.

Would this technique actually convert thin long geometry into something blockier? It seems more geared toward lowering the detail of high frequency features.

Nvidia’s recent patent describes a technique to avoid unnecessary triangle intersection checks on thin geometry by wrapping the geometry in smaller boxes and doing box checks instead. I haven’t seen any Nvidia research on general BVH LOD though. Maybe they’re just going to brute force it.
 
Would this technique actually convert thin long geometry into something blockier? It seems more geared toward lowering the detail of high frequency features.

AMD's technique doesn't leverage SBVH nor OBB. The teapot (Fig.5) image shows "ideal case" of each level of bounding volumes depending on the ray cone size.

I haven’t seen any Nvidia research on general BVH LOD though. Maybe they’re just going to brute force it.

Their research and patents are focusing on reducing false-positive hit against bounding volumes.
For the LOD, Nvidia and Intel proposed node masking and traversal shader each.
 
Node masking as in hard coded LOD selection logic in the RT core? Got a link?

Example Visualization Use Case—Different Levels of Detail
In some scenes, the developer may want to either include or exclude certain nodes (or subtrees rooted at the certain nodes) based also on one or more other dynamic conditions that can be determined per ray. For example, for a ray that originates at a far location relative to the car 202, the traversal efficiency may be higher if a lower geometric level of detail of the interior 204 is selected, rather than a higher geometric level of detail that may be needed only for rays that originate at a relatively close distance to the car. Thus, depending on whether the ray 216, such as, for example, a ray corresponding to a user's viewpoint, originates far or close to the car 202, the desired level of geometric detail of the car 202 may be different, and an additional programmable ray operation test can be used to dynamically select the object model with the appropriate level of detail and exclude from traversal for that ray all other level of detail of that object model.

Techniques for traversing data employed in ray tracing - NVIDIA Corporation (freepatentsonline.com)
 
Interesting, DXR already supports instance masking. Wonder if any games are already doing this.

The DXR specification thus provides for an instance mask to be specified for an instance node in an acceleration structure, and for an instance node inclusion mask to be specified for a ray. During traversal of an acceleration structure with the ray, only those nodes in the acceleration structure that have an instance mask that has a predetermined value relative to the instance inclusion mask of the ray are further traversed and/or intersection tested. That is, the mask specified in the ray is intended to match, according to a predetermined logical operation (e.g. AND), nodes that are to be included in the traversal.

Since this DXR functionality is more limited than Nvidia's RTX ray operations, Nvidia's RTX hardware platform including ray operations discussed above is able to implement DXR instance masking without change or enhancement. Nevertheless, further improvements are possible.

I assume Intel and AMD are lobbying Microsoft to include traversal shaders in the DXR spec.
 
Interesting, DXR already supports instance masking. Wonder if any games are already doing this.

Instance masking is only applicable to TLAS node and yes, DXR already supports it but not usable for geometry LOD implementation on an instance. The proposed node masking expands such capability to the BLAS node to enable more fine grained inclusion/exclusion test while traversing.

I assume Intel and AMD are lobbying Microsoft to include traversal shaders in the DXR spec.

I think so. It wouldn't be surprised if Ada supports traversal shader.
 
For those who might have been looking for it, since NVIDIA apparently can't be arsed to make images clickable into higher resolutions in their articles:

image2-copy.jpg
 
Quantum Computing May Make Ray Tracing Easier - Tom's Hardware
According to the research paper (currently in preprint), ray tracing workloads aided by quantum computing can offer an up to 190% performance improvement by slashing the number of calculations required by each ray, significantly reducing the requirements of the technology.

Towards Quantum Ray Tracing - ArXiv
Rendering on conventional computers is capable of generating realistic imagery, but the computational complexity of these light transport algorithms is a limiting factor of image synthesis. Quantum computers have the potential to significantly improve rendering performance through reducing the underlying complexity of the algorithms behind light transport. This paper investigates hybrid quantum-classical algorithms for ray tracing, a core component of most rendering techniques.

A Framework for Quantum Ray Tracing - ArXiv
Ray tracing algorithm simulates the physical movements of a huge amount of rays to render a high quality image, in which the tracing procedure for each ray can be implemented in parallel. By leveraging the inherent parallelism of quantum computing, we propose a quantum ray tracing algorithm, which is proved to have a quadratic speedup over the classical path tracing.
 
Hitman 3 is extremely heavy on the CPU with RT enabled. I'm dropping as low as 30 fps in outdoor scenes like Mendoza starting scene on a 10850k (@stock 4.8GHz all-core). Definitely CPU limited as GPU usage is like 50% or so.

Really curious to see how the 12900K, 5800X3D and future CPUs perform here.
 
Reconstruction techniques really need to get better at handling RT, maybe up the sample count per pixel when that's in play? Dunno. Also I wish they'd stop amping up the reflections on windows whenever RT reflections are added. We get it, you added reflections, but now you're doing that thing like you did with bloom or god rays and just shoving it people's faces shouting "see see see!" instead of concentrating on making the art look good.

Otherwise it's a neat upgrade, typically heavy but cool and free, unlike Rockstar (cough cough).
 
The difference, amazing.
Not for the performance impact. Aside from transparent reflections, improvements are minor and come with a huge, never seen before FPS drop (110 to 30 FPS which is completely unacceptable)

This is easily one of the worst RT implementations I have seen so far when it comes to the visual/performance ratio. And franky I think RT implementations like these ruin the reputation Raytracing has among gamers (performance hog for little visual benefit), we need way more Metro Exodus Enhanced Editions which improve image fidelity by a lot and also run very performant.
 
we need way more Metro Exodus Enhanced Editions which improve image fidelity by a lot and also run very performant.
Metro also has a lot less reflections. We can't simply compare RT title performance impacts without taking into account degree of RT use. There might be considerable implementation issues as well, I don't know, but reflections tend to be significant perf impact.
 
Not for the performance impact. Aside from transparent reflections, improvements are minor and come with a huge, never seen before FPS drop (110 to 30 FPS which is completely unacceptable)

This is easily one of the worst RT implementations I have seen so far when it comes to the visual/performance ratio. And franky I think RT implementations like these ruin the reputation Raytracing has among gamers (performance hog for little visual benefit), we need way more Metro Exodus Enhanced Editions which improve image fidelity by a lot and also run very performant.

Metro was build around RT aswell, Hitman 3 wasn't. Also, Metro on consoles have had to sink the RT settings (and other settings) quite much.
 
Hitman 3 is extremely heavy on the CPU with RT enabled.
Can't say that I've seen any scene being CPU limited here on a 3080 with 5900X. Even in 1080p the game is 100% GPU limited with RT (and runs at 25-80 fps depending on reflections quality setting).
Overall CPU load seem to hang around 20-33% so not even close to being CPU limited. Although the game does have three (or so) "heavy" threads which spike to ~50-60%.
I doubt that your 10C 10850K is so much worse than a 5900X here.

This is easily one of the worst RT implementations I have seen so far when it comes to the visual/performance ratio
Somewhat true. You can lower reflections quality to low and still get RT reflections with what will be a much smaller cost (~33-40% of performance).
The difference with reflections is pretty noticeable even at low quality option although it depends on a level you're playing. It's not a transformative one though since most of these are "faked" in raster version well enough I'd say.
High quality seem to add most of in game materials into reflective category, so that even stone and asphalt reflect light creating some sort of bounced lighting. But this is not really a big deal here as levels have fully static lighting anyway.
RT shadows are pretty useless though. The change aren't visible most of the time.
 
Status
Not open for further replies.
Back
Top