4 ms·

> in a few years it's going to replace the great majority of rasterization use-cases altogether There's no ground to be (so) sure of that. Given the current h

> in a few years it's going to replace the great majority of rasterization use-cases altogether There's no ground to be (so) sure of that. Given the current high cost, and more or less subtle effect, the prediction is uncertain, although very desirable. If in "the future" there will be a way to make RT cheap, definitely, it will be the way (I'd be very happy of that). If not, it will be another option, as it doesn't make sense to shove everybody's throat a feature that sucks 30/50% of the framerate. Additionally, as of now, we're talking about typically 30/50% of performance loss just for a single RT effect - eg. Metro Exodus uses it only for Global illumination, while Battlefield uses it only for reflections. What's going to be the performance hit for games using multiple RT effects?

_bxg1 8y ago
There's nothing about raytracing as a technique that puts a hard ceiling on efficiency/cost reduction. Any new technology is going to be expensive at first, and then presuming there's demand, will be made exponentially cheaper. Quake 2 has already been made to ditch rasterization altogether and use only raytracing: https://www.nvidia.com/en-us/geforce/news/quake-ii-rtx-ray-tracing-vulkan-vkray-geforce-rtx/ https://www.nvidia.com/en-us/geforce/news/quake-ii-rtx-ray-t... It was the rasterization state of the art 22 years ago. So I'd say it will take a maximum of another 22 years to render today's AAA geometries in real-time with raytracing. Though given how much more money there is today in the gaming industry, plus the way AI augments that curve, I would take a guess that it'll be closer to 5 years.
- Dylan16807 8y ago
  On any particular card it's still a tradeoff. If you can bake lighting in to 90% of the scene and get a much more complex visual at the same framerate, you'll do that no matter how fast the card is. (Unless the game is very low-spec or you really can't spare the time.)
  - _bxg1 8y ago
    It depends where the development resources are allocated. Game studios have a huge incentive to support the progression of raytracing technology, because achieving today's visuals without it requires an insane rat's nest of hacks and special-case smoke and mirrors. It's hard to overstate how much cheaper AAA games will become to produce when all of that can be circumvented. The fact that games will also look better is just a bonus.
    - Dylan16807 8y ago
      Considering how much time is spent right now adapting broken code to broken drivers, I'm not going to hold my breath about people saving money by avoiding insane rat's nests.
- fwip 8y ago
  Chips aren't getting better as fast as they were 22 years ago. Raytracing has been "just around the corner" for at least a decade. Remember Quake Wars? https://en.wikipedia.org/wiki/Quake_Wars:_Ray_Traced https://en.wikipedia.org/wiki/Quake_Wars:_Ray_Traced
  - dTal 8y ago
    Eh, so was VR. Sooner or later, "just around the corner" actually arrives. I actually think the speed plateau is going to make life very interesting. If we want to keep seeing improvements, we need to become smarter. It's getting more and more worthwhile making dedicated silicon to accomplish tasks, rather than just waiting a few years. We're probably near the peak of what we can do with traditional graphics - we've used every trick in the book and we're running out of transistors to throw at the problem. We need new approaches.
wtracy 8y ago
Within our lifetimes, I expect we are going to see games than run faster raytraced than rasterized. Why? Raytracing doesn't pay a penalty for overdraw. Rasterization time increases linearly with scene complexity, while raytracing time (with the proper acceleration structures in place) increases logarithmically. We're eventually going to see open world games that are only possible via raytracing.
- Rusky 8y ago
  Rasterization already makes heavy use of similar acceleration structures to avoid overdraw.
- magicalhippo 8y ago
  > Rasterization time increases linearly with scene complexity, while raytracing time (with the proper acceleration structures in place) increases logarithmically. Raytracing scales logarithmically due to the log(n) behavior of the ray-triangle acceleration structure, typically a tree or trie structure of some sort (f.ex. kd-tree, octree, qbvh). Constructing the acceleration structure has a cost K(n), so the true cost for rendering a frame is O(n) = log(n) + K(n). The problem then is that if your mesh is dynamic, you'll have to reconstruct the structure for each frame. For things like kd-trees, K(n) = n*log(n), killing the log(n) search benefit. Typically one would use a hierarchy of acceleration structures where on the top level you have one structure which contains the bounding boxes for each of the objects in the scene. Each object then has it's own acceleration structure, which can be different depending on if the object is a static mesh or a dynamic mesh. When ray-tracing one first traverses the top-level structure, and for each bounding-box hit, one traverses the candidate object's acceleration structure. Creating the top-level structure is then fast due to low n. For static meshes, such as terrain, the acceleration structure can be pre-built or built during loading of the scene, where a few seconds can often be afforded, resulting in zero per-frame cost. The key difficulty is with dense, highly dynamic meshes, such as character meshes. Due to the advanced animation of character meshes these days[1], pre-computing the acceleration structure isn't really feasible for the full mesh (though temporal coherency might perhaps be exploited here). At least that's that was the state some 10 years ago when I last fiddled with this. Sadly I haven't had time to catch up much, though glancing over some DirectX 12 material it seems the above is pretty accurate for how DX12 does it at least. [1]: Old (2006) but very illustrative example from Crysis: https://www.youtube.com/watch?v=0JFYt8kGYhM https://www.youtube.com/watch?v=0JFYt8kGYhM

_bxg1 8y ago

There's nothing about raytracing as a technique that puts a hard ceiling on efficiency/cost reduction. Any new technology is going to be expensive at first, and then presuming there's demand, will be made exponentially cheaper. Quake 2 has already been made to ditch rasterization altogether and use only raytracing: https://www.nvidia.com/en-us/geforce/news/quake-ii-rtx-ray-tracing-vulkan-vkray-geforce-rtx/ https://www.nvidia.com/en-us/geforce/news/quake-ii-rtx-ray-t... It was the rasterization state of the art 22 years ago. So I'd say it will take a maximum of another 22 years to render today's AAA geometries in real-time with raytracing. Though given how much more money there is today in the gaming industry, plus the way AI augments that curve, I would take a guess that it'll be closer to 5 years.

Dylan16807 8y ago
On any particular card it's still a tradeoff. If you can bake lighting in to 90% of the scene and get a much more complex visual at the same framerate, you'll do that no matter how fast the card is. (Unless the game is very low-spec or you really can't spare the time.)
- _bxg1 8y ago
  It depends where the development resources are allocated. Game studios have a huge incentive to support the progression of raytracing technology, because achieving today's visuals without it requires an insane rat's nest of hacks and special-case smoke and mirrors. It's hard to overstate how much cheaper AAA games will become to produce when all of that can be circumvented. The fact that games will also look better is just a bonus.
  - Dylan16807 8y ago
    Considering how much time is spent right now adapting broken code to broken drivers, I'm not going to hold my breath about people saving money by avoiding insane rat's nests.
fwip 8y ago
Chips aren't getting better as fast as they were 22 years ago. Raytracing has been "just around the corner" for at least a decade. Remember Quake Wars? https://en.wikipedia.org/wiki/Quake_Wars:_Ray_Traced https://en.wikipedia.org/wiki/Quake_Wars:_Ray_Traced
- dTal 8y ago
  Eh, so was VR. Sooner or later, "just around the corner" actually arrives. I actually think the speed plateau is going to make life very interesting. If we want to keep seeing improvements, we need to become smarter. It's getting more and more worthwhile making dedicated silicon to accomplish tasks, rather than just waiting a few years. We're probably near the peak of what we can do with traditional graphics - we've used every trick in the book and we're running out of transistors to throw at the problem. We need new approaches.

wtracy 8y ago

Within our lifetimes, I expect we are going to see games than run faster raytraced than rasterized. Why? Raytracing doesn't pay a penalty for overdraw. Rasterization time increases linearly with scene complexity, while raytracing time (with the proper acceleration structures in place) increases logarithmically. We're eventually going to see open world games that are only possible via raytracing.

Rusky 8y ago
Rasterization already makes heavy use of similar acceleration structures to avoid overdraw.
magicalhippo 8y ago
> Rasterization time increases linearly with scene complexity, while raytracing time (with the proper acceleration structures in place) increases logarithmically. Raytracing scales logarithmically due to the log(n) behavior of the ray-triangle acceleration structure, typically a tree or trie structure of some sort (f.ex. kd-tree, octree, qbvh). Constructing the acceleration structure has a cost K(n), so the true cost for rendering a frame is O(n) = log(n) + K(n). The problem then is that if your mesh is dynamic, you'll have to reconstruct the structure for each frame. For things like kd-trees, K(n) = n*log(n), killing the log(n) search benefit. Typically one would use a hierarchy of acceleration structures where on the top level you have one structure which contains the bounding boxes for each of the objects in the scene. Each object then has it's own acceleration structure, which can be different depending on if the object is a static mesh or a dynamic mesh. When ray-tracing one first traverses the top-level structure, and for each bounding-box hit, one traverses the candidate object's acceleration structure. Creating the top-level structure is then fast due to low n. For static meshes, such as terrain, the acceleration structure can be pre-built or built during loading of the scene, where a few seconds can often be afforded, resulting in zero per-frame cost. The key difficulty is with dense, highly dynamic meshes, such as character meshes. Due to the advanced animation of character meshes these days[1], pre-computing the acceleration structure isn't really feasible for the full mesh (though temporal coherency might perhaps be exploited here). At least that's that was the state some 10 years ago when I last fiddled with this. Sadly I haven't had time to catch up much, though glancing over some DirectX 12 material it seems the above is pretty accurate for how DX12 does it at least. [1]: Old (2006) but very illustrative example from Crysis: https://www.youtube.com/watch?v=0JFYt8kGYhM https://www.youtube.com/watch?v=0JFYt8kGYhM