4 ms·

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. Rasteri

by 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

by wtracy 8y ago

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