So in that case is this going to be a "G-Sync"/"Freesync" or "Gameworks"/"No, I like my framerates" thing? If developers begin supporting the RTX hardware is there a way AMD can get on board, or is this another one of NVidia's patented industry hurting moves?
For games most will access the functionality via the new DirectX ray tracing APIs (or perhaps the Vulkan equivalent in the future) so there's nothing stopping AMD or Intel from adding hardware to accelerate those APIs too.
Ah, excellent. Then I support this future. I thought this would be a gameworks version 2.0 problem.
I'd say that it is rather obvious that ray tracing is not a new thing, since it is simulates how light physically behaves. I consider this 3d rendering as a spectrum: rasterization requires little computation but has little to do with physics. Ray tracing is what requires a lot of computation and has everything to do with physics. Somewhere in between are hybrid methods: rasterization with ray tracing components adde…
> since it is simulates how light physically behaves. I think ray tracing is at best an ad-hoc model for light that produces nice results, but physically based it isn't.
It's physically based, it's just not a complete simulation of all the physics involved. It's at least as physically based as most rigid body, cloth or fluid physics simulation.
So in that case is this going to be a "G-Sync"/"Freesync" or "Gameworks"/"No, I like my framerates" thing? If developers begin supporting the RTX hardware is there a way AMD can get on board, or is this another one of NVidia's patented industry hurting moves?
I can't answer the question, but I'm curious how you think NVIDIA should have introduced real time raytracing to the industry? They can make it proprietary at the API level, or proprietary at the ISA level, but at some point you're stuck with the fact that their hardware can do something AMD's cannot. Is it industry hurting to make the GPU they sell have any exposed new capability, other than making the same old thin…
NVidia actively denies others the ability to interact with their "Gsync" platform - an AMD card will never be able to take advantage of a Gsync monitor. I'm getting the answer that this is a Vulkan/DirectX Api, and assuming that's the case, that's great. But if it was a proprietary API (like Gameworks), that could only possibly run on proprietary hardware, I'd have a problem. As long as everyone can leverage those API calls at the same time I'm perfectly happy.
Dedicated hardware to accelerate BVH traversal and ray triangle intersections. Previous GPU accelerated ray tracing implementations have just used existing hardware for programmable shaders for these but that hardware isn't ideally suited to the task.
So in that case is this going to be a "G-Sync"/"Freesync" or "Gameworks"/"No, I like my framerates" thing? If developers begin supporting the RTX hardware is there a way AMD can get on board, or is this another one of NVidia's patented industry hurting moves?
I'd say that it is rather obvious that ray tracing is not a new thing, since it is simulates how light physically behaves. I consider this 3d rendering as a spectrum: rasterization requires little computation but has little to do with physics. Ray tracing is what requires a lot of computation and has everything to do with physics. Somewhere in between are hybrid methods: rasterization with ray tracing components adde…
> For instance, pure rasterization cannot do shadows. Well... the technique that you describe (shadow mapping) is actually pure rasterization it just requires more than one rasterization pass. This also ignores the fact that there are other techniques for getting shadows in rasterizing renderers (stencil volumes and other stuff that is rather considered historical today). I get your point that rasterization doesn't s…
SSS has been done with point clouds for a long time. Only recently have films switched to ray tracing for SSS.
Games these days implement SSS in screen space using rasterisation, no rays tracing either.
> since it is simulates how light physically behaves. I think ray tracing is at best an ad-hoc model for light that produces nice results, but physically based it isn't.
It's physically based, it's just not a complete simulation of all the physics involved. It's at least as physically based as most rigid body, cloth or fluid physics simulation.
Radiosity would qualify better as `based on physics` than ray tracing, but can't do things like mirrors. I could live with classifying ray tracing as `geometry based`, like Newton studied mirrors.
(You could do something that uses ray tracing to determine what's visible and what isn't and radiosity to determine the colour, but that's an entirely different story).
Dedicated hardware to accelerate BVH traversal and ray triangle intersections. Previous GPU accelerated ray tracing implementations have just used existing hardware for programmable shaders for these but that hardware isn't ideally suited to the task.
So in that case is this going to be a "G-Sync"/"Freesync" or "Gameworks"/"No, I like my framerates" thing? If developers begin supporting the RTX hardware is there a way AMD can get on board, or is this another one of NVidia's patented industry hurting moves?
Developers support RTX via DirectX's DXR raytracing API. AMD can put whatever hardware they want on their cards to accelerate those calls and implement the appropriate drivers.
That's because it's a moving goalpost. Pixar keeps increasing the quality to take advantage of faster hardware and better algorithms. We'll never be close to getting today's real-time Pixar-quality until Pixar rendering is good enough that they stop meaningfully improving it. What we can have is yesterday's Pixar quality rendering in-game.
That should be a new goal post: can it render a pixar film in real-time. e.g. Do we have a Toy Story capable card yet? (Note: I know offline rendering and real-time raster rendering we use in GPU's are completely different methods. But there is a point where the raster trickery can catch up and match the offline stuff.)
Today's GPU are probably much closer to what Renderman was doing back when Toy Story was made than you think. They used an algorithm called REYES, which has nothing to do with raytracing and in fact can only barely be made to combine with ray tracing at all [1]. It was completely thrown out of Renderman only on the last couple of years for that reason.
REYES really is an early take on rasterization with tesselation, designed for hardware with extreme memory constraints. Although the actual tesselation algorithm works differently from GPU hardware tesselation, the basic idea of tesselating dynamically to the required level of detail for the current frame carried over intonthe hardware.
It's physically based, it's just not a complete simulation of all the physics involved. It's at least as physically based as most rigid body, cloth or fluid physics simulation.
Radiosity would qualify better as `based on physics` than ray tracing, but can't do things like mirrors. I could live with classifying ray tracing as `geometry based`, like Newton studied mirrors. (You could do something that uses ray tracing to determine what's visible and what isn't and radiosity to determine the colour, but that's an entirely different story).
What is your qualm with calling ray-tracing physically based? Don't most models even include transmissivity and refraction?
I mean, unless you're expecting them to calculate absorption/re-emission at every bounce...
It's physically based, it's just not a complete simulation of all the physics involved. It's at least as physically based as most rigid body, cloth or fluid physics simulation.
Radiosity would qualify better as `based on physics` than ray tracing, but can't do things like mirrors. I could live with classifying ray tracing as `geometry based`, like Newton studied mirrors. (You could do something that uses ray tracing to determine what's visible and what isn't and radiosity to determine the colour, but that's an entirely different story).
All rendering is an attempt to solve the rendering equation which is very much physically based. Whitted ray tracing is doing a lot of simplification but path tracing (which is closer to what people are talking about doing in real time with new hardware) is a pretty principled attempt to solve the rendering equation via Monte Carlo methods. I don't see how that's not physically based. The definitive book on this stuff is literally called "Physically Based Rendering" https://pbrt.org/