mirror of
https://github.com/godotengine/godot-docs.git
synced 2026-01-05 22:09:56 +03:00
Add commas before "but" throughout documentation
This commit is contained in:
@@ -190,7 +190,7 @@ game with them, as either open- or closed-source.
|
|||||||
To see how support for your SDK of choice could still be provided, look at the
|
To see how support for your SDK of choice could still be provided, look at the
|
||||||
Plugins question below.
|
Plugins question below.
|
||||||
|
|
||||||
If you know of a third-party SDK that is not supported by Godot but that offers
|
If you know of a third-party SDK that is not supported by Godot, but that offers
|
||||||
free and open source integration, consider starting the integration work yourself.
|
free and open source integration, consider starting the integration work yourself.
|
||||||
Godot is not owned by one person; it belongs to the community, and it grows along
|
Godot is not owned by one person; it belongs to the community, and it grows along
|
||||||
with ambitious community contributors like you.
|
with ambitious community contributors like you.
|
||||||
|
|||||||
@@ -167,7 +167,7 @@ who design software) to actually understand all future user needs. Trying to
|
|||||||
write very flexible structures that cater to many use cases at once is often a
|
write very flexible structures that cater to many use cases at once is often a
|
||||||
mistake.
|
mistake.
|
||||||
|
|
||||||
We may come up with something we believe is brilliant but later find out that
|
We may come up with something we believe is brilliant, but later find out that
|
||||||
users will never even use half of it or that they require features that don't
|
users will never even use half of it or that they require features that don't
|
||||||
quite fit into our original design, forcing us to either throw it away
|
quite fit into our original design, forcing us to either throw it away
|
||||||
or make it even more complex.
|
or make it even more complex.
|
||||||
|
|||||||
@@ -35,7 +35,7 @@ fine. If you plan to contribute regularly, however, we strongly advise that you
|
|||||||
set up clang-format locally to check and automatically fix all your commits.
|
set up clang-format locally to check and automatically fix all your commits.
|
||||||
|
|
||||||
.. warning:: Godot's code style should *not* be applied to third-party code,
|
.. warning:: Godot's code style should *not* be applied to third-party code,
|
||||||
i.e. that is included in Godot's source tree but was not written
|
i.e. that is included in Godot's source tree, but was not written
|
||||||
specifically for our project. Such code usually comes from
|
specifically for our project. Such code usually comes from
|
||||||
different upstream projects with their own style guides (or lack
|
different upstream projects with their own style guides (or lack
|
||||||
thereof), and don't want to introduce differences that would make
|
thereof), and don't want to introduce differences that would make
|
||||||
@@ -65,7 +65,7 @@ Pre-commit hook
|
|||||||
^^^^^^^^^^^^^^^
|
^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
For ease of use, we provide hooks for Git with the `pre-commit <https://pre-commit.com/>`__
|
For ease of use, we provide hooks for Git with the `pre-commit <https://pre-commit.com/>`__
|
||||||
Python framework that will run clang-format automatically on all your commits with the
|
Python framework that will run clang-format automatically on all your commits with the
|
||||||
correct version of clang-format.
|
correct version of clang-format.
|
||||||
To set up:
|
To set up:
|
||||||
|
|
||||||
@@ -77,7 +77,7 @@ To set up:
|
|||||||
|
|
||||||
You can also run the hook manually with ``pre-commit run``.
|
You can also run the hook manually with ``pre-commit run``.
|
||||||
|
|
||||||
.. note::
|
.. note::
|
||||||
|
|
||||||
Previously, we supplied a hook in the folder ``misc/hooks``. If you copied the
|
Previously, we supplied a hook in the folder ``misc/hooks``. If you copied the
|
||||||
script manually, these hooks should still work, but symlinks will be broken.
|
script manually, these hooks should still work, but symlinks will be broken.
|
||||||
@@ -382,7 +382,7 @@ instead.
|
|||||||
// ...
|
// ...
|
||||||
}
|
}
|
||||||
|
|
||||||
For member variables, don't use Javadoc-style comments but use single-line comments instead:
|
For member variables, don't use Javadoc-style comments, but use single-line comments instead:
|
||||||
|
|
||||||
.. code-block:: cpp
|
.. code-block:: cpp
|
||||||
|
|
||||||
|
|||||||
@@ -133,7 +133,7 @@ All builds are optimized. Each mode means:
|
|||||||
|
|
||||||
The editor is enabled by default in all PC targets (Linux, Windows, macOS),
|
The editor is enabled by default in all PC targets (Linux, Windows, macOS),
|
||||||
disabled for everything else. Disabling the editor produces a binary that can
|
disabled for everything else. Disabling the editor produces a binary that can
|
||||||
run projects but does not include the editor or the Project Manager.
|
run projects, but does not include the editor or the Project Manager.
|
||||||
|
|
||||||
::
|
::
|
||||||
|
|
||||||
@@ -403,7 +403,7 @@ To perform an SCU build, use the ``scu_build=yes`` SCons option.
|
|||||||
regular build prior to submitting the PR. This is because SCU builds
|
regular build prior to submitting the PR. This is because SCU builds
|
||||||
by nature include headers from earlier ``.cpp`` files in the
|
by nature include headers from earlier ``.cpp`` files in the
|
||||||
translation unit, therefore won't catch all the includes you will
|
translation unit, therefore won't catch all the includes you will
|
||||||
need in a regular build. The CI will catch these errors but it will
|
need in a regular build. The CI will catch these errors, but it will
|
||||||
usually be faster to catch them on a local build on your machine.
|
usually be faster to catch them on a local build on your machine.
|
||||||
|
|
||||||
Export templates
|
Export templates
|
||||||
|
|||||||
@@ -53,7 +53,7 @@ Segmentation slowly creates holes that are too small for most common
|
|||||||
allocations, so that memory is wasted. There is a lot of literature
|
allocations, so that memory is wasted. There is a lot of literature
|
||||||
about heap and segmentation, so this topic will not be developed
|
about heap and segmentation, so this topic will not be developed
|
||||||
further here. Modern operating systems use paged memory, which helps
|
further here. Modern operating systems use paged memory, which helps
|
||||||
mitigate the problem of segmentation but doesn't solve it.
|
mitigate the problem of segmentation, but doesn't solve it.
|
||||||
|
|
||||||
However, in many studies and tests, it is shown that given enough
|
However, in many studies and tests, it is shown that given enough
|
||||||
memory, if the maximum allocation size is below a given threshold in
|
memory, if the maximum allocation size is below a given threshold in
|
||||||
|
|||||||
@@ -53,7 +53,7 @@ Classes are registered by calling:
|
|||||||
Registering it will allow the class to be instanced by scripts, code, or
|
Registering it will allow the class to be instanced by scripts, code, or
|
||||||
creating them again when deserializing.
|
creating them again when deserializing.
|
||||||
|
|
||||||
Registering as virtual is the same but it can't be instanced.
|
Registering as virtual is the same, but it can't be instanced.
|
||||||
|
|
||||||
.. code-block:: cpp
|
.. code-block:: cpp
|
||||||
|
|
||||||
@@ -63,7 +63,7 @@ Object-derived classes can override the static function
|
|||||||
``static void _bind_methods()``. When one class is registered, this
|
``static void _bind_methods()``. When one class is registered, this
|
||||||
static function is called to register all the object methods,
|
static function is called to register all the object methods,
|
||||||
properties, constants, etc. It's only called once. If an Object derived
|
properties, constants, etc. It's only called once. If an Object derived
|
||||||
class is instanced but has not been registered, it will be registered as
|
class is instanced, but has not been registered, it will be registered as
|
||||||
virtual automatically.
|
virtual automatically.
|
||||||
|
|
||||||
Inside ``_bind_methods``, there are a couple of things that can be done.
|
Inside ``_bind_methods``, there are a couple of things that can be done.
|
||||||
@@ -148,7 +148,7 @@ For example:
|
|||||||
|
|
||||||
This is an integer property named "amount". The hint is a range, and the range
|
This is an integer property named "amount". The hint is a range, and the range
|
||||||
goes from 0 to 49 in steps of 1 (integers). It is only usable for the editor
|
goes from 0 to 49 in steps of 1 (integers). It is only usable for the editor
|
||||||
(editing the value visually) but won't be serialized.
|
(editing the value visually), but won't be serialized.
|
||||||
|
|
||||||
Another example:
|
Another example:
|
||||||
|
|
||||||
|
|||||||
@@ -120,7 +120,7 @@ If you run into errors, you may try the following command:
|
|||||||
|
|
||||||
If you get a ``MemoryError`` or ``EOFError``, you can remove the ``classes/`` folder and
|
If you get a ``MemoryError`` or ``EOFError``, you can remove the ``classes/`` folder and
|
||||||
run ``make`` again.
|
run ``make`` again.
|
||||||
This will drop the class references from the final HTML documentation but will keep the
|
This will drop the class references from the final HTML documentation, but will keep the
|
||||||
rest intact.
|
rest intact.
|
||||||
|
|
||||||
.. important::
|
.. important::
|
||||||
|
|||||||
@@ -89,7 +89,7 @@ and to log in to use it. Once logged in, you can propose change like so:
|
|||||||
|
|
||||||
4. At the bottom of the web page, summarize the changes you made and click the
|
4. At the bottom of the web page, summarize the changes you made and click the
|
||||||
button **Propose file change**. Make sure to replace the placeholder "Update file.rst"
|
button **Propose file change**. Make sure to replace the placeholder "Update file.rst"
|
||||||
by a short but clear one-line description, as this is the commit title.
|
by a short, but clear one-line description, as this is the commit title.
|
||||||
|
|
||||||
5. On the following screens, click the **Create pull request** button until you
|
5. On the following screens, click the **Create pull request** button until you
|
||||||
see a message like *Username wants to merge 1 commit into godotengine:master
|
see a message like *Username wants to merge 1 commit into godotengine:master
|
||||||
|
|||||||
@@ -215,7 +215,7 @@ video resolution will vary depending on the source's aspect ratio.
|
|||||||
|
|
||||||
.. tip::
|
.. tip::
|
||||||
|
|
||||||
If the video was recorded with an audio track but this audio track is not
|
If the video was recorded with an audio track, but this audio track is not
|
||||||
necessary, consider stripping it by adding the ``-an`` option to the FFmpeg
|
necessary, consider stripping it by adding the ``-an`` option to the FFmpeg
|
||||||
command line (before the output file name). This will reduce file size and
|
command line (before the output file name). This will reduce file size and
|
||||||
also ensure audio controls don't show up on the video when played in a
|
also ensure audio controls don't show up on the video when played in a
|
||||||
|
|||||||
@@ -137,7 +137,7 @@ Write as few adjectives and adverbs as possible. Only use them if they
|
|||||||
add key information to the description.
|
add key information to the description.
|
||||||
|
|
||||||
**Don't** use redundant or meaningless adverbs. Words that lengthen the
|
**Don't** use redundant or meaningless adverbs. Words that lengthen the
|
||||||
documentation but don't add any information:
|
documentation, but don't add any information:
|
||||||
|
|
||||||
::
|
::
|
||||||
|
|
||||||
|
|||||||
@@ -12,7 +12,7 @@ Pull request review process
|
|||||||
wanting to know how to ensure that their PR is merged.
|
wanting to know how to ensure that their PR is merged.
|
||||||
|
|
||||||
From a high level, the ideal life cycle of a pull request looks like the
|
From a high level, the ideal life cycle of a pull request looks like the
|
||||||
following:
|
following:
|
||||||
|
|
||||||
1. A contributor opens a PR that fixes a specific problem (optimally closing
|
1. A contributor opens a PR that fixes a specific problem (optimally closing
|
||||||
a GitHub `issue <https://github.com/godotengine/godot>`_ or implementing
|
a GitHub `issue <https://github.com/godotengine/godot>`_ or implementing
|
||||||
@@ -33,9 +33,9 @@ following:
|
|||||||
|
|
||||||
This document will explain steps 2, 3, 4, and 5 in more detail. For a more
|
This document will explain steps 2, 3, 4, and 5 in more detail. For a more
|
||||||
detailed explanation of the pull request workflow please see the :ref:`pull
|
detailed explanation of the pull request workflow please see the :ref:`pull
|
||||||
request workflow document <doc_pr_workflow>`.
|
request workflow document <doc_pr_workflow>`.
|
||||||
|
|
||||||
.. note::
|
.. note::
|
||||||
In practice these steps may blend together. Oftentimes maintainers will
|
In practice these steps may blend together. Oftentimes maintainers will
|
||||||
provide comments on code style and code quality at the same time and will
|
provide comments on code style and code quality at the same time and will
|
||||||
approve a pull request for both.
|
approve a pull request for both.
|
||||||
@@ -160,7 +160,7 @@ As you review pull requests, keep the Godot `Code of Conduct
|
|||||||
|
|
||||||
* Always assume positive intent from others.
|
* Always assume positive intent from others.
|
||||||
|
|
||||||
* Feedback is always welcome but keep your criticism constructive.
|
* Feedback is always welcome, but keep your criticism constructive.
|
||||||
|
|
||||||
Here are some things to avoid as you iterate on a pull request with a
|
Here are some things to avoid as you iterate on a pull request with a
|
||||||
contributor:
|
contributor:
|
||||||
@@ -178,7 +178,7 @@ contributor:
|
|||||||
areas and in performance-sensitive areas than it is in editor code for
|
areas and in performance-sensitive areas than it is in editor code for
|
||||||
example.
|
example.
|
||||||
|
|
||||||
* **Expanding the scope of a pull request.**
|
* **Expanding the scope of a pull request.**
|
||||||
|
|
||||||
Providing context or related/similar issues or proposals that may be fixed
|
Providing context or related/similar issues or proposals that may be fixed
|
||||||
similarly can be helpful, but adding a "may as well fix that thing over there
|
similarly can be helpful, but adding a "may as well fix that thing over there
|
||||||
@@ -253,7 +253,7 @@ Merging pull requests
|
|||||||
In general, pull requests should only be merged by members of the production
|
In general, pull requests should only be merged by members of the production
|
||||||
team or team leaders for pull requests in their area of the engine. For example,
|
team or team leaders for pull requests in their area of the engine. For example,
|
||||||
the networking team leader could merge a networking pull request that doesn't
|
the networking team leader could merge a networking pull request that doesn't
|
||||||
substantially change non-networking sections of code.
|
substantially change non-networking sections of code.
|
||||||
|
|
||||||
In practice it is best to wait for a member of the production team to merge the
|
In practice it is best to wait for a member of the production team to merge the
|
||||||
pull request as they keep a close eye on the entire codebase and will likely
|
pull request as they keep a close eye on the entire codebase and will likely
|
||||||
@@ -275,7 +275,7 @@ steps yourself.
|
|||||||
Production team members should ensure that the right people look at a pull
|
Production team members should ensure that the right people look at a pull
|
||||||
request before it is merged. In some cases this may require multiple people to
|
request before it is merged. In some cases this may require multiple people to
|
||||||
weigh in. In other cases, only one substantive approval is needed before the
|
weigh in. In other cases, only one substantive approval is needed before the
|
||||||
code can be merged.
|
code can be merged.
|
||||||
|
|
||||||
In general, try not to merge things based on one review alone, especially if it
|
In general, try not to merge things based on one review alone, especially if it
|
||||||
is your own. Get a second opinion from another maintainer, and make sure all the
|
is your own. Get a second opinion from another maintainer, and make sure all the
|
||||||
|
|||||||
@@ -174,7 +174,7 @@ that looks in the ``direction`` direction.
|
|||||||
|
|
||||||
Then, we update the velocity. We have to calculate the ground velocity and the
|
Then, we update the velocity. We have to calculate the ground velocity and the
|
||||||
fall speed separately. Be sure to go back one tab so the lines are inside the
|
fall speed separately. Be sure to go back one tab so the lines are inside the
|
||||||
``_physics_process()`` function but outside the condition we just wrote above.
|
``_physics_process()`` function, but outside the condition we just wrote above.
|
||||||
|
|
||||||
.. tabs::
|
.. tabs::
|
||||||
.. code-tab:: gdscript GDScript
|
.. code-tab:: gdscript GDScript
|
||||||
|
|||||||
@@ -271,7 +271,7 @@ released.
|
|||||||
it's important to keep in mind that ``play()`` isn't applied instantly.
|
it's important to keep in mind that ``play()`` isn't applied instantly.
|
||||||
Instead, it's applied the next time the :ref:`AnimationPlayer <class_AnimationPlayer>` is processed.
|
Instead, it's applied the next time the :ref:`AnimationPlayer <class_AnimationPlayer>` is processed.
|
||||||
This may end up being on the next frame, causing a 'glitch' frame,
|
This may end up being on the next frame, causing a 'glitch' frame,
|
||||||
where the property change was applied but the animation was not.
|
where the property change was applied, but the animation was not.
|
||||||
If this turns out to be a problem, after calling ``play()``, you can call ``advance(0)``
|
If this turns out to be a problem, after calling ``play()``, you can call ``advance(0)``
|
||||||
to update the animation immediately.
|
to update the animation immediately.
|
||||||
|
|
||||||
|
|||||||
@@ -45,7 +45,7 @@ resizing or stretching the screen. This transform is used internally (as
|
|||||||
described in :ref:`doc_multiple_resolutions`), but can also be manually set
|
described in :ref:`doc_multiple_resolutions`), but can also be manually set
|
||||||
on each viewport.
|
on each viewport.
|
||||||
|
|
||||||
Input events are multiplied by this transform but lack the ones above. To
|
Input events are multiplied by this transform, but lack the ones above. To
|
||||||
convert InputEvent coordinates to local CanvasItem coordinates, the
|
convert InputEvent coordinates to local CanvasItem coordinates, the
|
||||||
:ref:`CanvasItem.make_input_local() <class_CanvasItem_method_make_input_local>`
|
:ref:`CanvasItem.make_input_local() <class_CanvasItem_method_make_input_local>`
|
||||||
function was added for convenience.
|
function was added for convenience.
|
||||||
|
|||||||
@@ -246,7 +246,7 @@ Example 1: drawing a custom shape
|
|||||||
|
|
||||||
We will now use the custom drawing functionality of the Godot Engine to draw
|
We will now use the custom drawing functionality of the Godot Engine to draw
|
||||||
something that Godot doesn't provide functions for. We will recreate the Godot
|
something that Godot doesn't provide functions for. We will recreate the Godot
|
||||||
logo but with code- only using drawing functions.
|
logo, but with code- only using drawing functions.
|
||||||
|
|
||||||
You will have to code a function to perform this and draw it yourself.
|
You will have to code a function to perform this and draw it yourself.
|
||||||
|
|
||||||
|
|||||||
@@ -499,7 +499,7 @@ own, the effect may not be that noticeable, which is intended.
|
|||||||
Instead, :abbr:`SSIL (Screen-Space Indirect Lighting)` is meant to be used as a
|
Instead, :abbr:`SSIL (Screen-Space Indirect Lighting)` is meant to be used as a
|
||||||
*complement* to other global illumination techniques such as VoxelGI, SDFGI and
|
*complement* to other global illumination techniques such as VoxelGI, SDFGI and
|
||||||
LightmapGI. :abbr:`SSIL (Screen-Space Indirect Lighting)` also provides
|
LightmapGI. :abbr:`SSIL (Screen-Space Indirect Lighting)` also provides
|
||||||
a subtle ambient occlusion effect, similar to SSAO but with less detail.
|
a subtle ambient occlusion effect, similar to SSAO, but with less detail.
|
||||||
|
|
||||||
This feature only provides indirect lighting. It is not a full global illumination
|
This feature only provides indirect lighting. It is not a full global illumination
|
||||||
solution. This makes it different from screen-space global illumination (SSGI)
|
solution. This makes it different from screen-space global illumination (SSGI)
|
||||||
|
|||||||
@@ -160,12 +160,12 @@ at the cost of decreased performance.
|
|||||||
all" settings. To achieve the best visuals, you may need to use different
|
all" settings. To achieve the best visuals, you may need to use different
|
||||||
shadow bias values on a per-light basis.
|
shadow bias values on a per-light basis.
|
||||||
|
|
||||||
**Note on Appearance Changes**: When enabling shadows on a light, be aware that the light's
|
**Note on Appearance Changes**: When enabling shadows on a light, be aware that the light's
|
||||||
appearance might change compared to when it's rendered without shadows in the compatibility
|
appearance might change compared to when it's rendered without shadows in the compatibility
|
||||||
renderer. Due to limitations with older mobile devices, shadows are implemented using a multi-pass
|
renderer. Due to limitations with older mobile devices, shadows are implemented using a multi-pass
|
||||||
rendering approach so lights with shadows are rendered in sRGB space instead of linear space.
|
rendering approach so lights with shadows are rendered in sRGB space instead of linear space.
|
||||||
This change in rendering space can sometimes drastically alter the light's appearance. To achieve a similar
|
This change in rendering space can sometimes drastically alter the light's appearance. To achieve a similar
|
||||||
appearance to an unshadowed light, you may need to adjust the light's energy setting.
|
appearance to an unshadowed light, you may need to adjust the light's energy setting.
|
||||||
|
|
||||||
Directional light
|
Directional light
|
||||||
-----------------
|
-----------------
|
||||||
@@ -208,10 +208,10 @@ receive low-resolution shadows that may appear blocky.
|
|||||||
To fix this, a technique named *Parallel Split Shadow Maps* (PSSM) is used.
|
To fix this, a technique named *Parallel Split Shadow Maps* (PSSM) is used.
|
||||||
This splits the view frustum in 2 or 4 areas. Each area gets its own shadow map.
|
This splits the view frustum in 2 or 4 areas. Each area gets its own shadow map.
|
||||||
This allows small areas close to the viewer to have the same shadow resolution
|
This allows small areas close to the viewer to have the same shadow resolution
|
||||||
as a huge, far-away area. When shadows are enabled for DirectionalLight3D, the
|
as a huge, far-away area. When shadows are enabled for DirectionalLight3D, the
|
||||||
default shadow mode is PSSM with 4 splits. In scenarios where an object is large
|
default shadow mode is PSSM with 4 splits. In scenarios where an object is large
|
||||||
enough to appear in all four splits, it results in increased draw calls. Specifically,
|
enough to appear in all four splits, it results in increased draw calls. Specifically,
|
||||||
such an object will be rendered five times in total: once for each of the four shadow
|
such an object will be rendered five times in total: once for each of the four shadow
|
||||||
splits and once for the final scene rendering. This can impact performance, understanding
|
splits and once for the final scene rendering. This can impact performance, understanding
|
||||||
this behavior is important for optimizing your scene and managing performance expectations.
|
this behavior is important for optimizing your scene and managing performance expectations.
|
||||||
|
|
||||||
@@ -535,7 +535,7 @@ not use mipmaps, which makes them faster to render. However, projectors will
|
|||||||
look grainy at distance. **Nearest/Linear Mipmaps** will look smoother at a
|
look grainy at distance. **Nearest/Linear Mipmaps** will look smoother at a
|
||||||
distance, but projectors will look blurry when viewed from oblique angles. This
|
distance, but projectors will look blurry when viewed from oblique angles. This
|
||||||
can be resolved by using **Nearest/Linear Mipmaps Anisotropic**, which is the
|
can be resolved by using **Nearest/Linear Mipmaps Anisotropic**, which is the
|
||||||
highest-quality mode but also the most expensive.
|
highest-quality mode, but also the most expensive.
|
||||||
|
|
||||||
If your project has a pixel art style, consider setting the filter to one of the
|
If your project has a pixel art style, consider setting the filter to one of the
|
||||||
**Nearest** values so that projectors use nearest-neighbor filtering. Otherwise,
|
**Nearest** values so that projectors use nearest-neighbor filtering. Otherwise,
|
||||||
|
|||||||
@@ -148,14 +148,14 @@ independently from other viewports.
|
|||||||
The default mesh LOD threshold of 1 pixel is tuned to look *perceptually*
|
The default mesh LOD threshold of 1 pixel is tuned to look *perceptually*
|
||||||
lossless; it provides a significant performance gain with an unnoticeable loss
|
lossless; it provides a significant performance gain with an unnoticeable loss
|
||||||
in quality. Higher values will make LOD transitions happen sooner when the
|
in quality. Higher values will make LOD transitions happen sooner when the
|
||||||
camera moves away, resulting in higher performance but lower quality.
|
camera moves away, resulting in higher performance, but lower quality.
|
||||||
|
|
||||||
If you need to perform per-object adjustments to mesh LOD, you can adjust how
|
If you need to perform per-object adjustments to mesh LOD, you can adjust how
|
||||||
aggressive LOD transitions should be by adjusting the **LOD Bias** property on
|
aggressive LOD transitions should be by adjusting the **LOD Bias** property on
|
||||||
any node that inherits from GeometryInstance3D. Values *above* ``1.0`` will make
|
any node that inherits from GeometryInstance3D. Values *above* ``1.0`` will make
|
||||||
LOD transitions happen later than usual (resulting in higher quality but lower
|
LOD transitions happen later than usual (resulting in higher quality, but lower
|
||||||
performance). Values *below* ``1.0`` will make LOD transitions happen sooner than
|
performance). Values *below* ``1.0`` will make LOD transitions happen sooner than
|
||||||
usual (resulting in lower quality but higher performance).
|
usual (resulting in lower quality, but higher performance).
|
||||||
|
|
||||||
Additionally, ReflectionProbe nodes have their own **Mesh LOD Threshold** property
|
Additionally, ReflectionProbe nodes have their own **Mesh LOD Threshold** property
|
||||||
that can be adjusted to improve rendering performance when the reflection probe
|
that can be adjusted to improve rendering performance when the reflection probe
|
||||||
|
|||||||
@@ -240,7 +240,7 @@ textures should be filtered. **Nearest/Linear** does not use mipmaps. However,
|
|||||||
decals will look grainy at a distance. **Nearest/Linear Mipmaps** will look
|
decals will look grainy at a distance. **Nearest/Linear Mipmaps** will look
|
||||||
smoother at a distance, but decals will look blurry when viewed from oblique
|
smoother at a distance, but decals will look blurry when viewed from oblique
|
||||||
angles. This can be resolved by using **Nearest/Linear Mipmaps Anisotropic**,
|
angles. This can be resolved by using **Nearest/Linear Mipmaps Anisotropic**,
|
||||||
which provides the highest quality but is also slower to render.
|
which provides the highest quality, but is also slower to render.
|
||||||
|
|
||||||
If your project has a pixel art style, consider setting the filter to one of the
|
If your project has a pixel art style, consider setting the filter to one of the
|
||||||
**Nearest** values so that decals use nearest-neighbor filtering. Otherwise,
|
**Nearest** values so that decals use nearest-neighbor filtering. Otherwise,
|
||||||
|
|||||||
@@ -37,12 +37,12 @@ density map linked at the bottom of this page:
|
|||||||
|
|
||||||
.. figure:: img/variable_rate_shading_textured_enabled.webp
|
.. figure:: img/variable_rate_shading_textured_enabled.webp
|
||||||
:align: center
|
:align: center
|
||||||
:alt: Variable rate shading enabled in textured scene (lower quality but higher performance)
|
:alt: Variable rate shading enabled in textured scene (lower quality, but higher performance)
|
||||||
|
|
||||||
Variable rate shading enabled in textured scene (lower quality but higher performance)
|
Variable rate shading enabled in textured scene (lower quality, but higher performance)
|
||||||
|
|
||||||
When used in scenes with low-frequency detail (such as scenes with a
|
When used in scenes with low-frequency detail (such as scenes with a
|
||||||
stylized/low-poly aesthetic), it's possible to achieve similar performance gains
|
stylized/low-poly aesthetic), it's possible to achieve similar performance gains,
|
||||||
but with less reduction in visual quality:
|
but with less reduction in visual quality:
|
||||||
|
|
||||||
.. figure:: img/variable_rate_shading_untextured_disabled.webp
|
.. figure:: img/variable_rate_shading_untextured_disabled.webp
|
||||||
@@ -53,9 +53,9 @@ but with less reduction in visual quality:
|
|||||||
|
|
||||||
.. figure:: img/variable_rate_shading_untextured_enabled.webp
|
.. figure:: img/variable_rate_shading_untextured_enabled.webp
|
||||||
:align: center
|
:align: center
|
||||||
:alt: Variable rate shading enabled in untextured scene (lower quality but higher performance)
|
:alt: Variable rate shading enabled in untextured scene (lower quality, but higher performance)
|
||||||
|
|
||||||
Variable rate shading enabled in untextured scene (lower quality but higher performance)
|
Variable rate shading enabled in untextured scene (lower quality, but higher performance)
|
||||||
|
|
||||||
Hardware support
|
Hardware support
|
||||||
----------------
|
----------------
|
||||||
|
|||||||
@@ -15,7 +15,7 @@ On this page, you'll learn:
|
|||||||
|
|
||||||
.. seealso::
|
.. seealso::
|
||||||
|
|
||||||
If you only need meshes to become less detailed over distance but don't have
|
If you only need meshes to become less detailed over distance, but don't have
|
||||||
manually authored LOD meshes, consider relying on automatic
|
manually authored LOD meshes, consider relying on automatic
|
||||||
:ref:`doc_mesh_lod` instead.
|
:ref:`doc_mesh_lod` instead.
|
||||||
|
|
||||||
|
|||||||
@@ -142,11 +142,11 @@ and quality:
|
|||||||
for better performance.
|
for better performance.
|
||||||
- **Rendering > Environment > Volumetric Fog > Volume Depth:** Number of slices
|
- **Rendering > Environment > Volumetric Fog > Volume Depth:** Number of slices
|
||||||
to use along the depth of the froxel buffer for volumetric fog. A lower number
|
to use along the depth of the froxel buffer for volumetric fog. A lower number
|
||||||
will be more efficient but may result in artifacts appearing during camera
|
will be more efficient, but may result in artifacts appearing during camera
|
||||||
movement.
|
movement.
|
||||||
- **Rendering > Environment > Volumetric Fog > Use Filter:** Enables filtering
|
- **Rendering > Environment > Volumetric Fog > Use Filter:** Enables filtering
|
||||||
of the volumetric fog effect prior to integration. This substantially blurs
|
of the volumetric fog effect prior to integration. This substantially blurs
|
||||||
the fog which reduces fine details but also smooths out harsh edges and
|
the fog which reduces fine details, but also smooths out harsh edges and
|
||||||
aliasing artifacts. Disable when more detail is required.
|
aliasing artifacts. Disable when more detail is required.
|
||||||
|
|
||||||
.. note::
|
.. note::
|
||||||
@@ -159,7 +159,7 @@ Using fog volumes for local volumetric fog
|
|||||||
------------------------------------------
|
------------------------------------------
|
||||||
|
|
||||||
Sometimes, you want fog to be constrained to specific areas. Conversely, you may
|
Sometimes, you want fog to be constrained to specific areas. Conversely, you may
|
||||||
want to have global volumetric fog but fog should be excluded from certain
|
want to have global volumetric fog, but fog should be excluded from certain
|
||||||
areas. Both approaches can be followed using FogVolume nodes.
|
areas. Both approaches can be followed using FogVolume nodes.
|
||||||
|
|
||||||
Here's a quick start guide to using FogVolumes:
|
Here's a quick start guide to using FogVolumes:
|
||||||
|
|||||||
@@ -25,11 +25,11 @@ There are several ways to improve performance and battery life:
|
|||||||
which can be up to 4 times faster.
|
which can be up to 4 times faster.
|
||||||
- Open the Editor Settings and increase the value of **Low Processor Mode Sleep (µsec)**
|
- Open the Editor Settings and increase the value of **Low Processor Mode Sleep (µsec)**
|
||||||
to ``33000`` (30 FPS). This value determines the amount of *microseconds*
|
to ``33000`` (30 FPS). This value determines the amount of *microseconds*
|
||||||
between frames to render. Higher values will make the editor feel less reactive
|
between frames to render. Higher values will make the editor feel less reactive,
|
||||||
but will help decrease CPU and GPU usage significantly.
|
but will help decrease CPU and GPU usage significantly.
|
||||||
- If you have a node that causes the editor to redraw continuously (such as
|
- If you have a node that causes the editor to redraw continuously (such as
|
||||||
particles), hide it and show it using a script in the ``_ready()`` method.
|
particles), hide it and show it using a script in the ``_ready()`` method.
|
||||||
This way, it will be hidden in the editor but will still be visible in the
|
This way, it will be hidden in the editor, but will still be visible in the
|
||||||
running project.
|
running project.
|
||||||
|
|
||||||
The editor stutters and flickers on my variable refresh rate monitor (G-Sync/FreeSync)
|
The editor stutters and flickers on my variable refresh rate monitor (G-Sync/FreeSync)
|
||||||
@@ -49,7 +49,7 @@ There are several workarounds for this:
|
|||||||
alleviate this, you can increase **Low Processor Mode Sleep (µsec)** to
|
alleviate this, you can increase **Low Processor Mode Sleep (µsec)** to
|
||||||
``33000`` (30 FPS) in the Editor Settings. This value determines the amount of
|
``33000`` (30 FPS) in the Editor Settings. This value determines the amount of
|
||||||
*microseconds* between frames to render. Higher values will make the editor
|
*microseconds* between frames to render. Higher values will make the editor
|
||||||
feel less reactive but will help decrease CPU and GPU usage significantly.
|
feel less reactive, but will help decrease CPU and GPU usage significantly.
|
||||||
- Alternatively, disable variable refresh rate on your monitor or in the graphics driver.
|
- Alternatively, disable variable refresh rate on your monitor or in the graphics driver.
|
||||||
- VRR flicker can be reduced on some displays using the **VRR Control** or
|
- VRR flicker can be reduced on some displays using the **VRR Control** or
|
||||||
**Fine Tune Dark Areas** options in your monitor's OSD. These options may
|
**Fine Tune Dark Areas** options in your monitor's OSD. These options may
|
||||||
|
|||||||
Reference in New Issue
Block a user