18,700
edits
Graphics: Difference between revisions
adding LOD section
m (copy-edit on existing material) |
(adding LOD section) |
||
| Line 1: | Line 1: | ||
Here are explanations of various aspects of Oni's graphical code. | |||
==Environment mapping== | ==Environment mapping== | ||
| Line 53: | Line 53: | ||
:Just a side note: the ray-casting feature which 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 still need to be complemented with the standard [[wikipedia:Scanline_rendering|scanline rendering]] and [[wikipedia:Rasterisation|rasterisation]] approaches for performance reasons. | :Just a side note: the ray-casting feature which 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 still need to be complemented with the standard [[wikipedia:Scanline_rendering|scanline rendering]] and [[wikipedia:Rasterisation|rasterisation]] approaches for performance reasons. | ||
Pease acknowledges that even ray-casting 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 (pictured, right) and then appear a moment later: because the rays didn't hit them on the first pass. A distant face in the environment 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 ray-casting 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 (pictured, right) and then appear a moment later: because the rays didn't hit them on the first pass. A distant face in the environment 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. | ||
==LOD== | |||
Oni uses the graphics quality slider in Options to help determine what level of detail (LOD) at which to render characters. Each character has up to 5 LODs, though one 3D model can be used in as many of the 5 slots as desired. The first step in determining which LOD to draw each character at is to consult [[XML:ONCC#<LODConstants>|this table]] found in the character's ONCC. | |||
After that distance-from-camera filter is applied, Oni counts the total polygons of all characters in the scene (henceforth "TPCS"). If TPCS is not above the maximum polys allow by the game's graphics quality level ("GQMP"), the game then experiments with raising the LOD of all characters by 1, stopping when it would pass GQMP. If TPCS is starting off above GQMP, it lowers all characters' LOD by 1 until it gets below that limit. | |||
Next, iterating over each character from closest to farthest, the LOD of that character is raised by 1 as long as this won't raise TPCS over GQMP. Thus Oni seeks towards the maximum detail level that it can use for each character, prioritizing the closest ones. As a special consideration, if the closest character is below Medium LOD, it is raised to Medium regardless of GQMP, and the second-closest character is raised to Low if it was Super-Low. | |||
Once the desired LOD is determined for a character, they will be switched to it immediately if they are not standing still (which would make the switch too noticeable). If they are moving, the game waits several frames to make sure the new LOD is continuously being requested by the above algorithms and then they are switched. The goal is to avoid a character rapidly switching back and forth between LODs. | |||
After all the above considerations, if a cutscene is playing, every character is guaranteed a minimum LOD of Low so that no one will be rendered at Super-Low detail. | |||
[[Category:Engine docs]] | [[Category:Engine docs]] | ||