diff --git a/tutorials/3d/3d_rendering_limitations.rst b/tutorials/3d/3d_rendering_limitations.rst index b3d5fef7e81..c5383872267 100644 --- a/tutorials/3d/3d_rendering_limitations.rst +++ b/tutorials/3d/3d_rendering_limitations.rst @@ -77,6 +77,14 @@ two different objects end up on the same buffer value, then Z-fighting will occur. This will materialize as textures flickering back and forth as the camera moves or rotates. +.. note:: + + The Forward+ rendering method uses a technique called *reverse-z buffer* that + cancels out the risk of visible Z-fighting in most situations. This allows + rendering both nearby any (very) far away geometry by pushing the Camera node's + **Far** property to (very) large values, while keeping the **Near** property to + its defaults. + To make the depth buffer more precise over the rendered area, you should *increase* the Camera node's **Near** property. However, be careful: if you set it too high, players will be able to see through nearby geometry. You should diff --git a/tutorials/performance/optimizing_3d_performance.rst b/tutorials/performance/optimizing_3d_performance.rst index 19b48580f47..3cf95271c19 100644 --- a/tutorials/performance/optimizing_3d_performance.rst +++ b/tutorials/performance/optimizing_3d_performance.rst @@ -157,9 +157,10 @@ Large worlds If you are making large worlds, there are different considerations than what you may be familiar with from smaller games. -Large worlds may need to be built in tiles that can be loaded on demand as you -move around the world. This can prevent memory use from getting out of hand, and -also limit the processing needed to the local area. +Even though Godot has the ability to render any far away geometry, large worlds may +need to be built in tiles that can be loaded on demand as you move around the world. +This can prevent memory use from getting out of hand, and also limit the processing +needed to the local area. There may also be rendering and physics glitches due to floating point error in large worlds. This can be resolved using :ref:`doc_large_world_coordinates`. diff --git a/tutorials/physics/large_world_coordinates.rst b/tutorials/physics/large_world_coordinates.rst index b09b080fbc3..87c370254b6 100644 --- a/tutorials/physics/large_world_coordinates.rst +++ b/tutorials/physics/large_world_coordinates.rst @@ -44,7 +44,7 @@ The range and precision (minimum step between two exponent intervals) are determined by the floating-point number type. The *theoretical* range allows extremely high values to be stored in single-precision floats, but with very low precision. In practice, a floating-point type that cannot represent all integer -values is not very useful. At extreme values, precision becomes so low that the +values is not always useful. At extreme values, precision becomes so low that the number cannot even distinguish two separate *integer* values from each other. This is the range where individual integer values can be represented in a @@ -152,8 +152,10 @@ Who are large world coordinates for? ------------------------------------ Large world coordinates are typically required for 3D space or planetary-scale -simulation games. This extends to games that require supporting *very* fast -movement speeds, but also very slow *and* precise movements at times. +simulation games when they involve both very large distances or object sizes +*and* small and precise positions at the same time. This extends to games that +require supporting *very* fast movement speeds, but also very slow *and* precise +movements at times. On the other hand, it's important to only use large world coordinates when actually required (for performance reasons). Large world coordinates are usually @@ -164,6 +166,12 @@ actually required (for performance reasons). Large world coordinates are usually - Games with large worlds, but split into different levels with loading sequences in between. You can center each level portion around the world origin to avoid precision issues without a performance penalty. +- Games with large-scale worlds, involving only large objects and speeds. + As long as you don't need small-scale control over the world, you can stick to + single-precision coordinates. This also means that you can keep using real scale + physical distance and speed units, even in (very) large worlds. +- Games with (very) far away geometry that the player can never reach. You can + increase the Camera node's **Far** property enough to get that geometry rendered. - Open world games with a *playable on-foot area* not exceeding 8192×8192 meters (centered around the world origin). As shown in the above table, the level of precision remains acceptable within that range, even for a first-person game.