Jump to content

Graphics: Difference between revisions

No change in size ,  7 March 2021
m
link fixes
m (link fixes)
m (link fixes)
Line 52: Line 52:
It's an original algorithm that achieves both view frustum and occlusion culling. During each frame (i.e. 60 times per second), 20 rays are shot from the camera into the environment, distributed randomly in the frustum. Along the path of each ray, the engine first determines the relevant leaf node of the oct-tree (either by navigating the oct-tree or using the information on the neighbors of the previously traversed leaf node), then the ray is tested for collision with non-transparent environment quads intersecting that node (if the ray is stopped by a quad, then its further path is ignored). An overview of the algorithm is presented in the following paper:<br>
It's an original algorithm that achieves both view frustum and occlusion culling. During each frame (i.e. 60 times per second), 20 rays are shot from the camera into the environment, distributed randomly in the frustum. Along the path of each ray, the engine first determines the relevant leaf node of the oct-tree (either by navigating the oct-tree or using the information on the neighbors of the previously traversed leaf node), then the ray is tested for collision with non-transparent environment quads intersecting that node (if the ray is stopped by a quad, then its further path is ignored). An overview of the algorithm is presented in the following paper:<br>
[http://oni.bungie.org/archives/brent_gdc00.html An Algorithm for Hidden Surface Complexity Reduction and Collision Detection Based On Oct Trees] (figure 1 and 2 are mixed up) by [[Credits|Brent H. Pease]]
[http://oni.bungie.org/archives/brent_gdc00.html An Algorithm for Hidden Surface Complexity Reduction and Collision Detection Based On Oct Trees] (figure 1 and 2 are mixed up) by [[Credits|Brent H. Pease]]
:Just a sidenote: the ray-casting engine that handles occlusion/frustum is not to be confused with the common term "[[wikipedia:Ray_casting_(graphics)|ray-tracing]]", a CG rendering method where a ray is cast for every rendered pixel, achieving a high degree of photorealism. This method is very CPU-intensive and is typically used only for still images, short video sequences or CG movies such as Pixar's ''Cars''. Implementations of real-time ray tracing for gaming are underway, but can not yet compete with the standard [[wikipedia:Scanline_rendering|scanline rendering]] and [[wikipedia:rasterisation|rasterisation]] approaches.
:Just a sidenote: the ray-casting engine that handles occlusion/frustum is not to be confused with the common term "[[wikipedia:Ray_tracing_(graphics)|ray-tracing]]", a CG rendering method where a ray is cast for every rendered pixel, achieving a high degree of photorealism. This method is very CPU-intensive and is typically used only for still images, short video sequences or CG movies such as Pixar's ''Cars''. Implementations of real-time ray tracing for gaming are underway, but can not yet compete with the standard [[wikipedia:Scanline_rendering|scanline rendering]] and [[wikipedia:Rasterisation|rasterisation]] approaches.
Pease acknowledges that even occlusion testing was too CPU-intensive until they lowered the number of rays being emitted and started altering their emission angles even when the camera remained still, in order to catch any polygons that the first emission of rays missed; this is why distant polygons, when suddenly revealed by the camera, sometimes are culled at first and then appear a moment later (pictured, right): because the rays didn't hit them on the first pass. More generally, a distant object can be accidentally culled if it's only visible through a narrow slit, because the rays have a low probability of passing through the slit and hitting the objects behind it. A similar problem occurs when modders experiment with outdoor levels that have uneven ground (natural terrain): many of the ground polygons will be culled, making the map look like there are holes everywhere.
Pease acknowledges that even occlusion testing was too CPU-intensive until they lowered the number of rays being emitted and started altering their emission angles even when the camera remained still, in order to catch any polygons that the first emission of rays missed; this is why distant polygons, when suddenly revealed by the camera, sometimes are culled at first and then appear a moment later (pictured, right): because the rays didn't hit them on the first pass. More generally, a distant object can be accidentally culled if it's only visible through a narrow slit, because the rays have a low probability of passing through the slit and hitting the objects behind it. A similar problem occurs when modders experiment with outdoor levels that have uneven ground (natural terrain): many of the ground polygons will be culled, making the map look like there are holes everywhere.


[[Category:Engine docs]]
[[Category:Engine docs]]