Graphics - Revision history

Iritscen: /* LOD */ wording

2026-03-21T15:17:55Z

LOD: wording

← Older revision		Revision as of 15:17, 21 March 2026
Line 66:		Line 66:
	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.		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 character polys in the scene ("MCPS") which is allowed by the game's graphics quality setting, the game then experiments with raising the LOD of all characters one level at a time, stopping when it would pass MCPS. If ~~TPCS~~ is starting off above MCPS, it lowers all characters' LOD one level at a time until it gets below that limit.		After that distance-from-camera filter is applied, Oni counts the total character polygons in the scene (henceforth "TCPS"). If TCPS is not above the maximum character polys in the scene ("MCPS") which is allowed by the game's graphics quality setting, the game then experiments with raising the LOD of all characters one level at a time, stopping when it would pass MCPS. If TCPS is starting off above MCPS, the engine lowers all characters' LOD one level at a time until it gets below that limit.

	For reference, here is the table of MCPS by graphics quality level: (1500, 2200, 3000, 3400, 4000). Note that there is no consideration ~~at all for~~ how many <u>environmental</u> polys are in the scene.		For reference, here is the table of MCPS by graphics quality level: (1500, 2200, 3000, 3400, 4000). Note that there is no consideration of how many <u>environmental</u> polys are in the scene.

	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 MCPS. 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 MCPS, and the second-closest character is raised to Low if it was Super-Low.		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 TCPS over MCPS. 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 MCPS, 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.		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, one more: 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.		After all the above considerations, there is one more: 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]]

Iritscen: let's not rely on the image to tell the user what the coordinate system is

2025-10-03T14:41:27Z

let's not rely on the image to tell the user what the coordinate system is

← Older revision		Revision as of 14:41, 3 October 2025
Line 3:		Line 3:
	==Coordinate system==		==Coordinate system==
	[[Image:3D coordinate systems with Oni added.jpg\|right\|300px]]		[[Image:3D coordinate systems with Oni added.jpg\|right\|300px]]
	When compared with other game engines, Oni's coordinate system is not so unusual, however it has a difference of opinion with Blender on the subject of which axis is up. Since Blender is now the 3D modeler most commonly used by modders, recent versions of our modding tool [[OniSplit]] have offered an argument, -blender, for converting between axis conventions automatically. Note that Oni has a BSL command, <tt>am_show_axes</tt>, for showing the world axes as a handy reference, except that it's ''wrong'', showing a lefthanded Z-up system, only used by Unreal Engine.		In Oni's world, the Y axis is up, the X axis extends rightward, and the Z axis is depth, or "forward". This is referred to as a righthanded Y-up system, with the "hand" referring to a conventional mnemonic aid for keeping track of axes, pictured on the right. When compared with other game engines, Oni's coordinate system is not unusual, however it has a difference of opinion with Blender on the subject of which axis is up. Since Blender is now the 3D modeler most commonly used by modders, recent versions of our modding tool [[OniSplit]] have offered an argument, -blender, for converting between axis conventions automatically. Note that Oni has a BSL command, <tt>am_show_axes</tt>, for showing the world axes as a handy reference, except that it's ''wrong'', showing a lefthanded Z-up system, only used by Unreal Engine.

	==Environment mapping==		==Environment mapping==

Iritscen: better lede

2025-10-02T22:48:56Z

better lede

← Older revision		Revision as of 22:48, 2 October 2025
Line 1:		Line 1:
	Here we explain various aspects of Oni's graphical code.		Here we explain various aspects of Oni's graphical code, with introductions to basic computer graphics concepts and links to further reading.

	==Coordinate system==		==Coordinate system==

Iritscen: added "Coordinate system" section

2025-10-02T22:47:50Z

added "Coordinate system" section

← Older revision		Revision as of 22:47, 2 October 2025
Line 1:		Line 1:
	Here we explain various aspects of Oni's graphical code.		Here we explain various aspects of Oni's graphical code.

			==Coordinate system==
			[[Image:3D coordinate systems with Oni added.jpg\|right\|300px]]
			When compared with other game engines, Oni's coordinate system is not so unusual, however it has a difference of opinion with Blender on the subject of which axis is up. Since Blender is now the 3D modeler most commonly used by modders, recent versions of our modding tool [[OniSplit]] have offered an argument, -blender, for converting between axis conventions automatically. Note that Oni has a BSL command, <tt>am_show_axes</tt>, for showing the world axes as a handy reference, except that it's ''wrong'', showing a lefthanded Z-up system, only used by Unreal Engine.

	==Environment mapping==		==Environment mapping==

Iritscen: minor rewrite and formatting touch-up of FOV section

2025-10-02T22:28:01Z

minor rewrite and formatting touch-up of FOV section

← Older revision		Revision as of 22:28, 2 October 2025
Line 28:		Line 28:

	;Field of view (FOV)		;Field of view (FOV)
	:Oni defines the vertical field-of-view (FOV), i.e., the angle between the top and bottom planes of the frustum as measured at the camera's location, and its default value is 45°. On a 4:3 screen, the corresponding horizontal viewing angle is ~~'''~~2 * arctan(4/3 * tan(45° / 2)) = 57.~~8224°~~'''		:Oni defines the vertical field-of-view (FOV), i.e., the angle between the top and bottom planes of the frustum as measured at the camera's location, and its default value is 45°. On a 4:3 screen, the corresponding horizontal viewing angle is <tt>2 * arctan(4/3 * tan(45° / 2)) = '''57.8°'''</tt>.

	;Widescreen FOV		;Widescreen FOV
	:On a 16:9 or 16:10 screen, the horizontal viewing angle for a vertical FOV of 45° is larger: ~~'''~~2 * arctan(16/9 * tan(45° / 2)) = 72.~~73435°~~''' and ~~'''~~2 * arctan(16/10 * tan(45° / 2)) = 67.~~0682°~~''', respectively. This causes ~~insufficient frustum culling~~ in some of Oni's cutscenes ~~(intro sequences~~ of {{C\|2}}, {{C\|11}}, and {{C\|14}} ~~for example~~). A quick way to fix this is to bring the horizontal viewing angle down to the ~~supposed~~ '''57.~~8224°~~''' during the cutscene: the 4:3 viewport will then effectively be trimmed vertically rather than extended sideways. On 16:9 and 16:10 screens, the corrected vertical FOV will be ~~'''~~2 * arctan(3/4 * tan(45° / 2)) = 34.~~515877°~~'' and ''2 * arctan(5/6 * tan(45° / 2)) = 38.~~0871°~~''', respectively. Remember to set it back to 45° after the cutscene to fully enjoy the extended viewport. (Note that the [[AE]] contains widescreen patches for some of ~~these~~ cutscenes.)		:On a 16:9 or 16:10 screen, the horizontal viewing angle for a vertical FOV of 45° is larger: <tt>2 * arctan(16/9 * tan(45° / 2)) = '''72.7°'''</tt> and <tt>2 * arctan(16/10 * tan(45° / 2)) = '''67.1°'''</tt>, respectively. This causes objects to show up in some of Oni's cutscenes which aren't meant to be seen, for example the opening cutscenes of {{C\|2}}, {{C\|11}}, and {{C\|14}} (the camera even becomes blocked by a wall in Ch. 2). A quick way to fix this is to bring the horizontal viewing angle down to the intended '''57.8°''' during the cutscene: the 4:3 viewport will then effectively be trimmed vertically rather than extended sideways. On 16:9 and 16:10 screens, the corrected vertical FOV will be <tt>2 * arctan(3/4 * tan(45° / 2)) = '''34.5°'''</tt> and <tt>2 * arctan(5/6 * tan(45° / 2)) = '''38.1°'''</tt>, respectively. Remember to set it back to 45° after the cutscene to fully enjoy the extended viewport. (Note that the [[Anniversary Edition]] contains widescreen patches for some of the affected cutscenes, making this unnecessary.)

	==Occlusion==		==Occlusion==

Iritscen: general review and minor rewrite of Occlusion section

2025-10-02T22:18:22Z

general review and minor rewrite of Occlusion section

Show changes

Vortice: Update notice w/ summary

2025-01-22T22:33:32Z

Update notice w/ summary

← Older revision		Revision as of 22:33, 22 January 2025
Line 1:		Line 1:
			{{update\|This article contains links to the now defunct Oni Central Forum. Sections: Occlusion -> Raycasting}}
	Here are explanations of various aspects of Oni's graphical code.		Here are explanations of various aspects of Oni's graphical code.

Iritscen: link fixes

2022-09-18T14:16:10Z

link fixes

← Older revision		Revision as of 14:16, 18 September 2022
Line 8:		Line 8:
	:See [[BSL:Frustum_and_fog]] on how to alter fog using [[BSL]].		:See [[BSL:Frustum_and_fog]] on how to alter fog using [[BSL]].
	:''In mid-to-late 1990s games, when processing power was not enough to render far viewing distances, clipping was employed. However, the effect could be very distracting since bits and pieces of [objects] would flicker in and out of view instantly; by applying a medium-ranged fog, the clipped polygons would fade in more realistically from the haze.'' — [[wp:Distance fog\|"Distance fog"]], Wikipedia		:''In mid-to-late 1990s games, when processing power was not enough to render far viewing distances, clipping was employed. However, the effect could be very distracting since bits and pieces of [objects] would flicker in and out of view instantly; by applying a medium-ranged fog, the clipped polygons would fade in more realistically from the haze.'' — [[wp:Distance fog\|"Distance fog"]], Wikipedia
	:''For more technical information on fog and on frustum-based space (or whatever it's called), see [https://~~docs~~.microsoft.com/en-us/previous-versions//ms537113(v=vs.85)?redirectedfrom=MSDN here] and [https://~~docs~~.microsoft.com/en-us/windows/win32/direct3d9/pixel-fog?redirectedfrom=MSDN here] and [https://web.archive.org/web/20130520191527/http://cs.fit.edu/~wds/classes/graphics/PTOC/ptoc/ elsewhere].		:''For more technical information on fog and on frustum-based space (or whatever it's called), see [https://learn.microsoft.com/en-us/previous-versions/ms537113(v=vs.85)?redirectedfrom=MSDN here] and [https://learn.microsoft.com/en-us/windows/win32/direct3d9/pixel-fog?redirectedfrom=MSDN here] and [https://web.archive.org/web/20130520191527/http://cs.fit.edu/~wds/classes/graphics/PTOC/ptoc/ elsewhere].

	The frustum (see below) defines a set of coordinates in which the near plane is at <tt>Z = 0</tt> and the far plane at <tt>Z = 1</tt> (<tt>X = -1</tt> and <tt>X = 1</tt> correspond to the left and right side of the frustum; the top and bottom of the frustum are planes with <tt>Y = -a</tt> and <tt>Y = a</tt>, with <tt>a</tt> the aspect ratio of the screen).		The frustum (see below) defines a set of coordinates in which the near plane is at <tt>Z = 0</tt> and the far plane at <tt>Z = 1</tt> (<tt>X = -1</tt> and <tt>X = 1</tt> correspond to the left and right side of the frustum; the top and bottom of the frustum are planes with <tt>Y = -a</tt> and <tt>Y = a</tt>, with <tt>a</tt> the aspect ratio of the screen).

Iritscen: fixing WP redirect; other link tweaks

2022-06-28T01:54:06Z

fixing WP redirect; other link tweaks

← Older revision		Revision as of 01:54, 28 June 2022
Line 2:		Line 2:

	==Environment mapping==		==Environment mapping==
	:Wikipedia: [[~~wikipedia~~:~~Environment~~ mapping\|Environment mapping]]		:Wikipedia: [[wp:Reflection mapping\|Environment mapping]]
	It's a technique to simulate reflectivity: the diffuse texture is mapped using regular texture coordinates (UVs), and there's an additional texture layer, the UVs for which are generated from the vertex normals and the orientation of the object in space (and, ideally, the orientation of the camera). While env mapping is the most advanced shader in Oni, it's about the worst implementation of env mapping there ever was (the projection is planar and the camera angle is not taken into account at all).		It's a technique to simulate reflectivity: the diffuse texture is mapped using regular texture coordinates (UVs), and there's an additional texture layer, the UVs for which are generated from the vertex normals and the orientation of the object in space (and, ideally, the orientation of the camera). While env mapping is the most advanced shader in Oni, it's about the worst implementation of env mapping there ever was (the projection is planar and the camera angle is not taken into account at all).

	==Fog==		==Fog==
	:See [[BSL:Frustum_and_fog]] on how to alter fog using [[BSL]].		:See [[BSL:Frustum_and_fog]] on how to alter fog using [[BSL]].
	:''In mid-to-late 1990s games, when processing power was not enough to render far viewing distances, clipping was employed. However, the effect could be very distracting since bits and pieces of [objects] would flicker in and out of view instantly; by applying a medium-ranged fog, the clipped polygons would fade in more realistically from the haze.'' — [[~~wikipedia~~:~~Distance_fog~~\|"Distance fog"]], Wikipedia		:''In mid-to-late 1990s games, when processing power was not enough to render far viewing distances, clipping was employed. However, the effect could be very distracting since bits and pieces of [objects] would flicker in and out of view instantly; by applying a medium-ranged fog, the clipped polygons would fade in more realistically from the haze.'' — [[wp:Distance fog\|"Distance fog"]], Wikipedia
	:''For more technical information on fog and on frustum-based space (or whatever it's called), see [https://docs.microsoft.com/en-us/previous-versions//ms537113(v=vs.85)?redirectedfrom=MSDN here] and [https://docs.microsoft.com/en-us/windows/win32/direct3d9/pixel-fog?redirectedfrom=MSDN here] and [https://web.archive.org/web/20130520191527/http://cs.fit.edu/~wds/classes/graphics/PTOC/ptoc/ elsewhere].		:''For more technical information on fog and on frustum-based space (or whatever it's called), see [https://docs.microsoft.com/en-us/previous-versions//ms537113(v=vs.85)?redirectedfrom=MSDN here] and [https://docs.microsoft.com/en-us/windows/win32/direct3d9/pixel-fog?redirectedfrom=MSDN here] and [https://web.archive.org/web/20130520191527/http://cs.fit.edu/~wds/classes/graphics/PTOC/ptoc/ elsewhere].

Line 25:		Line 25:
	==Frustum==		==Frustum==
	:See [[BSL:Frustum_and_fog\|Frustum and fog]] on how to alter the far clip plane and field-of-view (FOV) using [[BSL]].		:See [[BSL:Frustum_and_fog\|Frustum and fog]] on how to alter the far clip plane and field-of-view (FOV) using [[BSL]].
	:''In 3D computer graphics, the viewing frustum or view frustum is the region of space in the modeled world that may appear on the screen; it is the field of view of the notional camera. The exact shape of this region varies depending on what kind of camera lens is being simulated, but typically it is a frustum of a rectangular pyramid (hence the name). The planes that cut the frustum perpendicular to the viewing direction are called the near plane and the far plane. Objects closer to the camera than the near plane or beyond the far plane are not drawn.'' — [[~~wikipedia~~:~~Viewing_frustum~~\|"Viewing frustum"]], Wikipedia		:''In 3D computer graphics, the viewing frustum or view frustum is the region of space in the modeled world that may appear on the screen; it is the field of view of the notional camera. The exact shape of this region varies depending on what kind of camera lens is being simulated, but typically it is a frustum of a rectangular pyramid (hence the name). The planes that cut the frustum perpendicular to the viewing direction are called the near plane and the far plane. Objects closer to the camera than the near plane or beyond the far plane are not drawn.'' — [[wp:Viewing frustum\|"Viewing frustum"]], Wikipedia

	;Field of view (FOV)		;Field of view (FOV)
Line 47:		Line 47:

	;Ray-casting		;Ray-casting
	:Wikipedia: [[~~wikipedia~~:~~Ray_casting~~\|Ray casting]]		:Wikipedia: [[wp:Ray casting\|Ray casting]]
	[[Image:Ray-casting failure.jpg\|thumb\|right\|If you've ever thought that you briefly saw flashes of color while turning the camera, now you know why. Wherever a polygon is not rendered, the level's skybox will be visible.]]		[[Image:Ray-casting failure.jpg\|thumb\|right\|If you've ever thought that you briefly saw flashes of color while turning the camera, now you know why. Wherever a polygon is not rendered, the level's skybox will be visible.]]

	It's an original algorithm that achieves both view frustum and occlusion culling. During each frame, 16-20 rays (depending on graphics quality) 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), and 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). Quads thus detected with collision will be drawn. An overview of the algorithm is presented in the paper [http://oni.bungie.org/archives/brent_gdc00.html An Algorithm for Hidden Surface Complexity Reduction and Collision Detection Based On Oct Trees] by [[Credits\|Brent H. Pease]] (note that figure 1 and 2 are mixed up).		It's an original algorithm that achieves both view frustum and occlusion culling. During each frame, 16-20 rays (depending on graphics quality) 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), and 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). Quads thus detected with collision will be drawn. An overview of the algorithm is presented in the paper [http://oni.bungie.org/archives/brent_gdc00.html An Algorithm for Hidden Surface Complexity Reduction and Collision Detection Based On Oct Trees] by [[Credits\|Brent H. Pease]] (note that figure 1 and 2 are mixed up).
	: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 "[[wp: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 [[wp:Scanline rendering\|scanline rendering]] and [[wp: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.

Iritscen: LOD wording, poly count table

2021-10-21T22:15:55Z

LOD wording, poly count table

← Older revision		Revision as of 22:15, 21 October 2021
Line 7:		Line 7:
	==Fog==		==Fog==
	:See [[BSL:Frustum_and_fog]] on how to alter fog using [[BSL]].		:See [[BSL:Frustum_and_fog]] on how to alter fog using [[BSL]].
	:''In mid-to-late 1990s games, when processing power was not enough to render far viewing distances, clipping was employed. However, the effect could be very distracting since bits and pieces of [objects] would flicker in and out of view instantly; by applying a medium-ranged fog, the clipped polygons would fade in more realistically from the haze.'' -- [[wikipedia:Distance_fog\|"Distance fog"]], Wikipedia		:''In mid-to-late 1990s games, when processing power was not enough to render far viewing distances, clipping was employed. However, the effect could be very distracting since bits and pieces of [objects] would flicker in and out of view instantly; by applying a medium-ranged fog, the clipped polygons would fade in more realistically from the haze.'' — [[wikipedia:Distance_fog\|"Distance fog"]], Wikipedia
	:''For more technical information on fog and on frustum-based space (or whatever it's called), see [https://docs.microsoft.com/en-us/previous-versions//ms537113(v=vs.85)?redirectedfrom=MSDN here] and [https://docs.microsoft.com/en-us/windows/win32/direct3d9/pixel-fog?redirectedfrom=MSDN here] and [https://web.archive.org/web/20130520191527/http://cs.fit.edu/~wds/classes/graphics/PTOC/ptoc/ elsewhere].		:''For more technical information on fog and on frustum-based space (or whatever it's called), see [https://docs.microsoft.com/en-us/previous-versions//ms537113(v=vs.85)?redirectedfrom=MSDN here] and [https://docs.microsoft.com/en-us/windows/win32/direct3d9/pixel-fog?redirectedfrom=MSDN here] and [https://web.archive.org/web/20130520191527/http://cs.fit.edu/~wds/classes/graphics/PTOC/ptoc/ elsewhere].

Line 57:		Line 57:
	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.		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.		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 character polys in the scene ("MCPS") which is allowed by the game's graphics quality setting, the game then experiments with raising the LOD of all characters one level at a time, stopping when it would pass MCPS. If TPCS is starting off above MCPS, it lowers all characters' LOD one level at a time 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.		For reference, here is the table of MCPS by graphics quality level: (1500, 2200, 3000, 3400, 4000). Note that there is no consideration at all for how many <u>environmental</u> polys are in the scene.

			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 MCPS. 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 MCPS, 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.		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.		After all the above considerations, one more: 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]]