DirectX Ray-Tracing [DXR]

[Shifty Geezer]

Actually, it does.

No, it doesn't A+B does not lead to C. You're suggesting a better algorithm but you've no supporting data for that, instead speculating how performance will improve. As Andrew says, if they can hit better than DXR demo quality at DXR speeds, just by tweaking their engine a bit, why haven't they done so?

Of course they're not compelling to somebody unwilling to consider them.

You don't get graphics programmers being disinterested in the achievements of others in their field. There is no ego. There's the challenge to create better, faster visuals, and that's what appeals to these people, and they all share and learn (whole frickin' point of GDC!!). There are no 'lifetime achievement' awards being sought, or 'graphics programmer Oscars'. So take Andrew's opinions as those working in the field with an open view to all that's going on it.

 

[chris1515]

No, it doesn't A+B does not lead to C. You're suggesting a better algorithm but you've no supporting data for that, instead speculating how performance will improve. As Andrew says, if they can hit better than DXR demo quality at DXR speeds, just by tweaking their engine a bit, why haven't they done so?

You don't get graphics programmers being disinterested in the achievements of others in their field. There is no ego. There's the challenge to create better, faster visuals, and that's what appeals to these people, and they all share and learn (whole frickin' point of GDC!!). There are no 'lifetime achievement' awards being sought, or 'graphics programmer Oscars'. So take Andrew's opinions as those working in the field with an open view to all that's going on it.

+1 between GDC, SIGGRAPH, Eurographics, University paper, Blog post and Twitter it is a field where everyone like to share...

 

[xz321zx]

The crux of the issue with "1spp " seems to be the temporal part of "Spatiotemporal Variance-Guided Filtering" is in need of substantial high and preferably invariant framerate . So it's a proverbial problem (chicken or egg) .

 

[JoeJ]

Hey guys, new to this forum!

I'm a self-taught graphics programmer, released some indie games, worked on offline animation but not for the games industry.
I work on realtime GI for a decade, tried many techniques and ended up with something that is slightly similar to the Many LODs paper. Still months of work to proof it's good and fast enough for current gen consoles...

I've not implemented path tracing because i consider it a very inefficient algorithm: Bad caching caused by random memory access, divergent workloads hard to distribute efficiently.
It's simple and elegant, but it's brute force and slow. I doubt this can (or should) be fixed with future hardware acceleration for rays alone.
So, personally i think the solution is to combine multiple techniques, with recent DXR demos being good examples in this direction.

But on the other hand i understand OCASMs opinion, because the paper and video he mentions implies realtime pathtracing is not just around the corner but totally possible just now.
To proof that with some math, i could naively say:

Take a 16x16 neighbourhood of pixels and a history of 16 frames, and boom: 16^3 = 4096 samples, enough for noise free images.

So the question is: What are the hidden limitations the paper and video do not point out?
I'd love to here what you guys think about it.

Personally i can only do some speculation:

The video shows just static scenes. We have no way to see how fast things converge with dynamic scenes.
There are some scenes showing the 'detaching shadows' problem from moving columns, but this scene is too simple. We can not assume it is as good for a scene from a game.

Reflections are - of course - blurry.

Rasterized primary rays - no depth of field and motion blur. (Saying the game guys can do this in screenspace is a weak consolation.)

That's all i can think about. But those are pretty weak points - it's not enough to proof OCASM wrong!
In fact my own technique has the same limitations and i accept them without much worries.

So again, any thoughts welcome...

 

[Jawed]

I'm going to propose Jawed's Law of Real Time Ray Tracing for Animated Graphics: "99.9999% of all rays used in a given frame are identical to those from the frame before and in the frame after."

 

[Ethatron]

I'm going to propose Jawed's Law of Real Time Ray Tracing for Animated Graphics: "99.9999% of all rays used in a given frame are identical to those from the frame before and in the frame after."

We could turn on ECC for moar benefit.

 

[JoeJ]

I'm going to propose Jawed's Law of Real Time Ray Tracing for Animated Graphics: "99.9999% of all rays used in a given frame are identical to those from the frame before and in the frame after."

Good point, i'll add this to my list of doubts:
What happens if you quickly turn your view 180 degrees in a FPS - how would denoising behave in such a situation? Is the result still practical for games?

If not, the solution would be: Cache results in world space instead screen space, so we have information everywhere (which makes sense anyways because stuff behind the camera still contributes to GI).
And if we do this, we open another main optimization: Get infinite bounces for free by updating cached results with just one bounce per frame.
At this point we no longer do classical pathtracing, it's more kind of using the radiosity method with the additional complexity to maintain caching.

The SEED demo does those things, so in my opinion it is already better than path tracers.
(I doubt OTOY caches in worldspace: Beautiful simplicity is lost; A need for global parametrization may come up; No more easy instancing...)

 

[OCASM]

http://www.gdcvault.com/browse/gdc-18

Many presentations available for free including some about ray tracing.

No, it doesn't A+B does not lead to C. You're suggesting a better algorithm but you've no supporting data for that, instead speculating how performance will improve. As Andrew says, if they can hit better than DXR demo quality at DXR speeds, just by tweaking their engine a bit, why haven't they done so?

You don't get graphics programmers being disinterested in the achievements of others in their field. There is no ego. There's the challenge to create better, faster visuals, and that's what appeals to these people, and they all share and learn (whole frickin' point of GDC!!). There are no 'lifetime achievement' awards being sought, or 'graphics programmer Oscars'. So take Andrew's opinions as those working in the field with an open view to all that's going on it.

1) OTOY is mostly interested in real-time, movie quality, full path tracing, not hybrid rendering at video game quality. Now, Andrew says his renderer can do full path-tracing so all he has to do is crank up the settings to match those of the Octane demo and if it reaches the same quality at the same speed then I'll admit my mistake.

2) To believe that his few months old research project is already just as good as what these other guys have developed, optimized and battle tested over the course of several years even though he's only shown a limited featureset and at a much lower quality shows nothing but arrogance on his part. You'd think he'd at least inform himself a little about Octane's latest developments before outright dismissing the idea of it delivering a better bang for your buck. For example, its use of AI to massively reduce noise even before the denoising filter is applied (which is AI based as well).

Good point, i'll add this to my list of doubts:
What happens if you quickly turn your view 180 degrees in a FPS - how would denoising behave in such a situation? Is the result still practical for games?

If not, the solution would be: Cache results in world space instead screen space, so we have information everywhere (which makes sense anyways because stuff behind the camera still contributes to GI).
And if we do this, we open another main optimization: Get infinite bounces for free by updating cached results with just one bounce per frame.
At this point we no longer do classical pathtracing, it's more kind of using the radiosity method with the additional complexity to maintain caching.

The SEED demo does those things, so in my opinion it is already better than path tracers.
(I doubt OTOY caches in worldspace: Beautiful simplicity is lost; A need for global parametrization may come up; No more easy instancing...)

One of NVIDIA's presentations linked above talks about those types of optimizations. I think it's the one with Morgan McGuire.

 

[Shifty Geezer]

2) To believe that his few months old research project is already just as good as what these other guys have developed, optimized and battle tested over the course of several years even though he's only shown a limited featureset and at a much lower quality shows nothing but arrogance on his part.

You started with the 'arrogance'. You asserted as fact...

"Limit Octane to the uses and quality of the RTX demos and it could be running at 60fps in current hardware."​

The argument then was about the factual basis for such assertions, of which there is none beyond your gut feeling that you know what Octane is doing and you know what RTX is doing. If you want to reign in your enthusiasm and talk about the actual 'next-gen' features of Octane and compare/contrast them to the actual implementations of RTX, please do so - that's exactly what this forum is for. Otherwise, expect to irk a lot of developers with grandiose, unsubstantiated talk of 'next-gen engines' as you compare chalk to cheese.

For example, hypothetically, a non-realtime engine could spend half a second creating and optimising a sophisticated spatial representation of the scene to further accelerate ray tracing, where an engine operating in a < 33ms time slice can't and has to take different shortcuts to hit the realtime target.

 

[JoeJ]

OTOY is mostly interested in real-time, movie quality, full path tracing, not hybrid rendering at video game quality.

Everyone is interested in photorealistic realtime graphics, we have the same goal. But ruling out everything different than path tracing could be a big mistake.
Waiting year after year until hardware becomes strong enough while increasing resolution and frequency demands negate this is one option - making smaller steps at inferior video game quality another.
We need to be open to alternatives, and we need to keep working on improving them. Each has its strengths and weaknesses, so going hybrid is not wrong, it is necessary or at least more efficient.
(The thought DXR would be the silver bullet and moving the responsibility to hardware vendors could be a similar mistake - remember how GPUs initially killed many real time graphics innovations.)

One of NVIDIA's presentations linked above talks about those types of optimizations. I think it's the one with Morgan McGuire.

Couldn't find it, but those things are nothing new. My point is that implementing them leads to different algorithms than path tracing. Even OTOY - at the moment - targets realtime production, not realtime for consumers?
From that perspective doing those optimizations makes little sense, and reading the older Brigade paper implies they do classical pathtracing and try to optimize as good as possible.

... i'm confused by denoising results, but camera always moves slowly. Maybe denoising is just trading noise vs. fading/popping artifacts if some action happens?

Note that i'm not against realtime path tracing in general. I consider to implement something similar to add high frequency details that my algorithm lacks.

 

[jlippo]

GDC talk video.
Ray Tracing in Games with NVIDIA RTX (Presented by NVIDIA)

 

[OCASM]

You started with the 'arrogance'. You asserted as fact...

"Limit Octane to the uses and quality of the RTX demos and it could be running at 60fps in current hardware."​

The argument then was about the factual basis for such assertions, of which there is none beyond your gut feeling that you know what Octane is doing and you know what RTX is doing. If you want to reign in your enthusiasm and talk about the actual 'next-gen' features of Octane and compare/contrast them to the actual implementations of RTX, please do so - that's exactly what this forum is for. Otherwise, expect to irk a lot of developers with grandiose, unsubstantiated talk of 'next-gen engines' as you compare chalk to cheese.

For example, hypothetically, a non-realtime engine could spend half a second creating and optimising a sophisticated spatial representation of the scene to further accelerate ray tracing, where an engine operating in a < 33ms time slice can't and has to take different shortcuts to hit the realtime target.

It's not based on gut feeling but in the data currently available and an understanding of the relationship between spp, resolution and performance.

According to the NVIDIA presentation about their demo, they are using 1spp for direct shadows, 2 spp for AO and 1 spp for reflections. As far as we know that's running at 1080p @ 30fps. The OTOY demo was running at 1080 @ 1fps but at 50spp. Reduce that to 1 or 2 spp (I'd be fine with only 1) and you get a massive speed boost. Also consider that the RTX demos are mostly rasterized with only the aforementioned effects being raytraced. Why? Because doing full path tracing would be substantially slower. Well, the Octane demo is doing full path tracing. Limit it to only those effects and you get another massive speed up.

And what if you severely limit the ray distance for your diffuse GI and calculate the reflections at half-res like the SEED demo? Well you get even better performance.

And of course, the most obvious thing is that the RTX demos are optimized for the custom hardware of the Voltas. The Octane demo isn't. According to Jules Urbach, their AI denoiser doesn't yet make use of the tensor cores but once it does it should run an order of magnitude faster.

One thing I'd like to revise is the "on current hardware" part. When I said it it wasn't known what the GPUs used for the Octane demos were. It was later clarified that they are two Voltas. Ultimately I think that's good because it makes the comparison with the RTX demos fairer.

Everyone is interested in photorealistic realtime graphics, we have the same goal. But ruling out everything different than path tracing could be a big mistake.
Waiting year after year until hardware becomes strong enough while increasing resolution and frequency demands negate this is one option - making smaller steps at inferior video game quality another.
We need to be open to alternatives, and we need to keep working on improving them. Each has its strengths and weaknesses, so going hybrid is not wrong, it is necessary or at least more efficient.
(The thought DXR would be the silver bullet and moving the responsibility to hardware vendors could be a similar mistake - remember how GPUs initially killed many real time graphics innovations.)

Well Otoy obviously wants the highest quality possible, that's why they don't showcase the tech with demos at 1spp. They're main focus throughout the years has been rendering for movies and things like that so it makes sense. I on the other hand don't mind a quality of 1spp because even though it pales in comparison to movies it would be a major leap over current game graphics. Now, with their RNDR SDK I think it will be possible to make hybrids too.

Couldn't find it, but those things are nothing new. My point is that implementing them leads to different algorithms than path tracing. Even OTOY - at the moment - targets realtime production, not realtime for consumers?
From that perspective doing those optimizations makes little sense, and reading the older Brigade paper implies they do classical pathtracing and try to optimize as good as possible.

... i'm confused by denoising results, but camera always moves slowly. Maybe denoising is just trading noise vs. fading/popping artifacts if some action happens?

Note that i'm not against realtime path tracing in general. I consider to implement something similar to add high frequency details that my algorithm lacks.

I guess if they're using spatiotemporal filtering, noise would be more noticeable with faster camera motions.

 

[Deleted member 2197]

YouTube's 'VRMA Virtual Reality Media' shows a video of Disney's upcoming Star Wars flight simulator that is powered by Unreal Engine 4. This simulator makes use of real-time raytracing, the video shown used eight Nvidia Quadro P6000 24GB GDDR5X cards, which go for 6000 bucks each.
...
It will bring players into the cockpit of the Millennium Falcon, where they can fire the blasters of the ship and prepare the ship for jumping to hyperspace. To show this in real time, Disney paused the demo and then moved around the camera. Thanks to Microsoft's DirectX Raytracing API , the demo can run in 4k - real-time raytracing in 4k.
....
Shaky video of the last minute or so of a session at GTC 2018 where Disney showed off what Real Time Ray tracing of Star Wars looks like with 8 Nvidia GPU's. Only 8 GPUS. This is possible thanks to AI Denoising technology. Note this is not a movie, this is live raytracing, or live rendering of a lightfield, the holy grail of computing. The session was called: S8414 -

http://www.guru3d.com/news-story/vi...-star-wars-looks-like-with-8-nvidia-gpus.html

 

[jlippo]

Has there been information on what exactly was ray traced on the ride?

 

[snarfbot]

When is the ride opening?

 

[DavidGraham]

Testing for DXR fallback layer available in latest Windows 10 update

This March Microsoft announced DirectX Raytracing (DXR), an extension to DirectX 12 API - DXR will provide a standard API for hardware and software accelerated ray tracing under DirectX. Microsoft also released D3D12 Raytracing Fallback Layer, a library that emulates the DirectX Raytracing API on devices without native driver/hardware support. The Fallback Layer is a thin layer on top of DirectX shared as an open source library via Microsoft's official GitHub repo. The Fallback Layer uses Compute Shaders to implement DXR functionalities. For the Sponza sample we've selected a viewpoint to generate as much reflection rays as possible. This test has two different modes, the first mode uses a fully-raytraced pass that shoots primary rays for diffuse lights and recursively fires shadow rays, the second mode utilises reflection rays only to create a shiny perfect mirror ground plane. The Procedural sample uses special intersection shaders to create analytic/volumetric geometry and iso-surfaces - typical effects found in shadertoy demos.

 

[willardjuice]

I just wanted to note that you shouldn't draw any real conclusions from the fallback layer. It is not meant to be performant in anyway, but rather has a focus on being "correct" above all else.

 

[comprodigy]

Testing for DXR fallback layer available in latest Windows 10 update

This March Microsoft announced DirectX Raytracing (DXR), an extension to DirectX 12 API - DXR will provide a standard API for hardware and software accelerated ray tracing under DirectX. Microsoft also released D3D12 Raytracing Fallback Layer, a library that emulates the DirectX Raytracing API on devices without native driver/hardware support. The Fallback Layer is a thin layer on top of DirectX shared as an open source library via Microsoft's official GitHub repo. The Fallback Layer uses Compute Shaders to implement DXR functionalities. For the Sponza sample we've selected a viewpoint to generate as much reflection rays as possible. This test has two different modes, the first mode uses a fully-raytraced pass that shoots primary rays for diffuse lights and recursively fires shadow rays, the second mode utilises reflection rays only to create a shiny perfect mirror ground plane. The Procedural sample uses special intersection shaders to create analytic/volumetric geometry and iso-surfaces - typical effects found in shadertoy demos.

I'm wondering if you could give me some help compiling this. I've tried a few different things with no luck. I've downloaded the latest build, the latest W10 SDK, copied over the binaries into the sample folder, but every time I go to build I get an exit with exit code 1 from the precompile batch file. Any tricks coming to mind? I'm running a gtx 1080 on the latest drivers.

 

[Woking-34]

I'm wondering if you could give me some help compiling this. I've tried a few different things with no luck. I've downloaded the latest build, the latest W10 SDK, copied over the binaries into the sample folder, but every time I go to build I get an exit with exit code 1 from the precompile batch file. Any tricks coming to mind? I'm running a gtx 1080 on the latest drivers.

I was able to build and run the samples, make sure that you have "Developer Mode" enabled.

 

[Jupiter]

https://www.ea.com/seed/news/seed-dd18-presentation-slides-raytracing