Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 8 additions & 0 deletions tutorials/3d/3d_rendering_limitations.rst
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
7 changes: 4 additions & 3 deletions tutorials/performance/optimizing_3d_performance.rst
Original file line number Diff line number Diff line change
Expand Up @@ -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`.
Expand Down
14 changes: 11 additions & 3 deletions tutorials/physics/large_world_coordinates.rst
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down Expand Up @@ -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
Expand All @@ -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.
Expand Down
Loading