mirror of
https://github.com/godotengine/godot-docs.git
synced 2026-01-05 22:09:56 +03:00
Merge pull request #6941 from Calinou/remove-gles2-references
Remove references to removed GLES2 backend
This commit is contained in:
@@ -9,20 +9,9 @@ This page lists common issues encountered when using Godot and possible solution
|
||||
|
||||
.. seealso::
|
||||
|
||||
See :ref:`doc_using_the_web_editor` for caveats specific to the HTML5 version
|
||||
See :ref:`doc_using_the_web_editor` for caveats specific to the Web version
|
||||
of the Godot editor.
|
||||
|
||||
Everything I do in the editor or project manager appears delayed by one frame
|
||||
-----------------------------------------------------------------------------
|
||||
|
||||
This is a `known bug <https://github.com/godotengine/godot/issues/23069>`__ on
|
||||
Intel graphics drivers on Windows. Updating to the latest graphics driver
|
||||
version *provided by Intel* should fix the issue.
|
||||
|
||||
You should use the graphics driver provided by Intel rather than the one
|
||||
provided by your desktop or laptop's manufacturer because their version is often
|
||||
outdated.
|
||||
|
||||
The editor runs slowly and uses all my CPU and GPU resources, making my computer noisy
|
||||
--------------------------------------------------------------------------------------
|
||||
|
||||
@@ -49,7 +38,12 @@ The editor stutters and flickers on my variable refresh rate monitor (G-Sync/Fre
|
||||
--------------------------------------------------------------------------------------
|
||||
|
||||
This is a `known issue <https://github.com/godotengine/godot/issues/38219>`__.
|
||||
There are two workarounds for this:
|
||||
Variable refresh rate monitors need to adjust their gamma curves continuously to
|
||||
emit a consistent amount of light over time. This can cause flicker to appear in
|
||||
dark areas of the image when the refresh rate varies a lot, which occurs as
|
||||
the Godot editor only redraws when necessary.
|
||||
|
||||
There are several workarounds for this:
|
||||
|
||||
- Enable **Interface > Editor > Update Continuously** in the Editor Settings. Keep in mind
|
||||
this will increase power usage and heat/noise emissions since the editor will
|
||||
@@ -59,36 +53,29 @@ There are two workarounds for this:
|
||||
*microseconds* between frames to render. Higher values will make the editor
|
||||
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.
|
||||
|
||||
The grid disappears and meshes turn black when I rotate the 3D camera in the editor
|
||||
-----------------------------------------------------------------------------------
|
||||
|
||||
This is a `known bug <https://github.com/godotengine/godot/issues/30330>`__ on
|
||||
Intel graphics drivers on Windows.
|
||||
|
||||
The only workaround, for now, is to switch to the GLES2 renderer. You can switch
|
||||
the renderer in the top-right corner of the editor or the Project Settings.
|
||||
|
||||
If you use a computer allowing you to switch your graphics card, like NVIDIA
|
||||
Optimus, you can use the dedicated graphics card to run Godot.
|
||||
- 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
|
||||
increase input lag or result in crushed blacks.
|
||||
- If using an OLED display, use the **Black (OLED)** editor theme preset in the
|
||||
Editor Settings. This hides VRR flicker thanks to OLED's perfect black levels.
|
||||
|
||||
The editor or project takes a very long time to start
|
||||
-----------------------------------------------------
|
||||
|
||||
This is a `known bug <https://github.com/godotengine/godot/issues/20566>`__ on
|
||||
When using one of the the Vulkan-based renderers (Forward+ or Forward Mobile),
|
||||
the first startup is expected to be relatively long. This is because shaders
|
||||
need to be compiled before they can be cached. Shaders also need to be cached
|
||||
again after updating Godot, after updating graphics drivers or after switching
|
||||
graphics cards.
|
||||
|
||||
If the issue persists after the first startup, this is a
|
||||
`known bug <https://github.com/godotengine/godot/issues/20566>`__ on
|
||||
Windows when you have specific USB peripherals connected. In particular,
|
||||
Corsair's iCUE software seems to cause this bug. Try updating your USB
|
||||
peripherals' drivers to their latest version. If the bug persists, you need to
|
||||
disconnect the specific peripheral before opening the editor. You can then
|
||||
connect the peripheral again.
|
||||
|
||||
Editor tooltips in the Inspector and Node docks blink when they're displayed
|
||||
----------------------------------------------------------------------------
|
||||
|
||||
This is a `known issue <https://github.com/godotengine/godot/issues/32990>`__
|
||||
caused by the third-party Stardock Fences application on Windows.
|
||||
The only known workaround is to disable Stardock Fences while using Godot.
|
||||
|
||||
The Godot editor appears frozen after clicking the system console
|
||||
-----------------------------------------------------------------
|
||||
|
||||
@@ -111,18 +98,6 @@ default values in the NVIDIA Control Panel.
|
||||
To disable this overlay on Linux, open ``nvidia-settings``, go to **X Screen 0 >
|
||||
OpenGL Settings** then uncheck **Enable Graphics API Visual Indicator**.
|
||||
|
||||
The project window appears blurry, unlike the editor
|
||||
----------------------------------------------------
|
||||
|
||||
Unlike the editor, the project isn't marked as DPI-aware by default. This is
|
||||
done to improve performance, especially on integrated graphics, where rendering
|
||||
3D scenes in hiDPI is slow.
|
||||
|
||||
To resolve this, open **Project > Project Settings**, make sure **Advanced
|
||||
Settings** is active, and enable **Display >
|
||||
Window > DPI > Allow hiDPI**. On top of that, make sure your project is
|
||||
configured to support :ref:`multiple resolutions <doc_multiple_resolutions>`.
|
||||
|
||||
The project window doesn't appear centered when I run the project
|
||||
-----------------------------------------------------------------
|
||||
|
||||
|
||||
@@ -21,16 +21,20 @@ parameters and then adding randomness to them.
|
||||
Particle nodes
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
Godot provides two different nodes for 2D particles, :ref:`class_GPUParticles2D` and
|
||||
:ref:`class_CPUParticles2D`.
|
||||
GPUParticles2D is more advanced and uses the GPU to process particle effects, but that limits
|
||||
it to higher end graphics API, and in our case to the GLES3 renderer. For projects using
|
||||
the GLES2 backend, CPUParticles2D is a CPU-driven option with near feature parity with
|
||||
GPUParticles2D, but lesser performance. While GPUParticles2D is configured via a
|
||||
:ref:`class_ParticleProcessMaterial` (and optionally with a custom shader), the matching options
|
||||
are provided via node properties in CPUParticles2D (with the exception of the trail settings).
|
||||
You can convert a GPUParticles2D node into a CPUParticles2D node by clicking on the node in the
|
||||
inspector, and selecting "Convert to CPUParticles2D" in the "Particles" menu of the toolbar.
|
||||
Godot provides two different nodes for 2D particles, :ref:`class_GPUParticles2D`
|
||||
and :ref:`class_CPUParticles2D`. GPUParticles2D is more advanced and uses the
|
||||
GPU to process particle effects. CPUParticles2D is a CPU-driven option with
|
||||
near-feature parity with GPUParticles2D, but lower performance when using large
|
||||
amounts of particles. On the other hand, CPUParticles2D may perform better on
|
||||
low-end systems or in GPU-bottlenecked situations.
|
||||
|
||||
While GPUParticles2D is configured via a :ref:`class_ParticleProcessMaterial`
|
||||
(and optionally with a custom shader), the matching options are provided via
|
||||
node properties in CPUParticles2D (with the exception of the trail settings).
|
||||
|
||||
You can convert a GPUParticles2D node into a CPUParticles2D node by clicking on
|
||||
the node in the inspector, and selecting **Particles > Convert to
|
||||
CPUParticles2D** in the toolbar at the top of the 3D editor viewport.
|
||||
|
||||
.. image:: img/particles_convert.png
|
||||
|
||||
|
||||
@@ -33,23 +33,28 @@ without affecting the source file.
|
||||
Color banding
|
||||
-------------
|
||||
|
||||
When using the GLES3 or Vulkan renderers, Godot's 3D engine renders internally
|
||||
in HDR. However, the rendering output will be tonemapped to a low dynamic range
|
||||
so it can be displayed on the screen. This can result in visible banding,
|
||||
especially when using untextured materials. This can also be seen in 2D projects
|
||||
when using smooth gradient textures.
|
||||
When using the Forward+ or Forward Mobile rendering methods, Godot's 3D engine
|
||||
renders internally in HDR. However, the rendering output will be tonemapped to a
|
||||
low dynamic range so it can be displayed on the screen. This can result in
|
||||
visible banding, especially when using untextured materials. For performance
|
||||
reasons, color precision is also lower when using the Forward Mobile rendering
|
||||
method compared to Forward+.
|
||||
|
||||
When using the Compatibility rendering method, HDR is not used and the color
|
||||
precision is the lowest of all rendering methods. This also applies to 2D
|
||||
rendering, where banding may be visible when using smooth gradient textures.
|
||||
|
||||
There are two main ways to alleviate banding:
|
||||
|
||||
- Enable **Use Debanding** in the Project Settings. This applies a
|
||||
fullscreen debanding shader as a post-processing effect and is very cheap.
|
||||
Fullscreen debanding is only supported when using the GLES3 or Vulkan renderers.
|
||||
It also requires HDR to be enabled in the Project Settings (which is the default).
|
||||
- Alternatively, bake some noise into your textures. This is mainly effective in 2D,
|
||||
e.g. for vignetting effects. In 3D, you can also use a
|
||||
`custom debanding shader <https://github.com/fractilegames/godot-gles2-debanding-material>`__
|
||||
to be applied on your *materials*. This technique works even if your project is
|
||||
rendered in LDR, which means it will work when using the GLES2 renderer.
|
||||
- If using the Forward+ or Forward Mobile rendering methods, enable **Use
|
||||
Debanding** in the advanced Project Settings. This applies a fullscreen debanding
|
||||
shader as a post-processing effect and is very cheap.
|
||||
- Alternatively, bake some noise into your textures. This is mainly effective in
|
||||
2D, e.g. for vignetting effects. In 3D, you can also use a `custom debanding
|
||||
shader <https://github.com/fractilegames/godot-gles2-debanding-material>`__ to
|
||||
be applied on your *materials*. This technique works even if your project is
|
||||
rendered with low color precision, which means it will work when using the
|
||||
Mobile and Compatibility rendering methods.
|
||||
|
||||
.. seealso::
|
||||
|
||||
|
||||
@@ -3,11 +3,6 @@
|
||||
2D skeletons
|
||||
============
|
||||
|
||||
.. warning::
|
||||
|
||||
There are known issues with 2D skeletons on mobile and web platforms with the GLES2 renderer. We
|
||||
recommend using the GLES3 renderer if your project relies on Skeleton2D for now.
|
||||
|
||||
Introduction
|
||||
------------
|
||||
|
||||
|
||||
@@ -30,8 +30,8 @@ proper threading support is added.
|
||||
|
||||
**Mobile browsers are currently not supported.**
|
||||
|
||||
The web editor supports both the GLES3 and GLES2 renderers, although GLES2 is
|
||||
recommended for better performance and compatibility with old/low-end hardware.
|
||||
The web editor only supports the Compatibility rendering method, as there is no
|
||||
stable way to run Vulkan applications on the web yet.
|
||||
|
||||
.. note::
|
||||
|
||||
|
||||
@@ -39,20 +39,13 @@ in the user's browser.
|
||||
WebGL version
|
||||
-------------
|
||||
|
||||
Depending on your choice of renderer, Godot can target WebGL 1.0 (*GLES2*) or
|
||||
WebGL 2.0 (*GLES3*).
|
||||
Godot 4.0 and later can only target WebGL 2.0 (using the Compatibility rendering
|
||||
method). There is no stable way to run Vulkan applications on the web yet.
|
||||
|
||||
WebGL 1.0 is the recommended option if you want your project to be supported
|
||||
on all browsers with the best performance.
|
||||
|
||||
Godot's GLES3 renderer targets high end devices, and the performance using
|
||||
WebGL 2.0 can be subpar. Some features are also not supported in WebGL 2.0
|
||||
specifically.
|
||||
|
||||
Additionally, while most browsers support WebGL 2.0, this is not yet the case
|
||||
for **Safari**. WebGL 2.0 support is coming in Safari 15 for macOS, and is not
|
||||
available yet for any **iOS** browser (all WebKit-based like Safari).
|
||||
See `Can I use WebGL 2.0 <https://caniuse.com/webgl2>`__ for details.
|
||||
See `Can I use WebGL 2.0 <https://caniuse.com/webgl2>`__ for a list of browser
|
||||
versions supporting WebGL 2.0. Note that Safari has several issues with WebGL
|
||||
2.0 support that other browsers don't have, so we recommend using a
|
||||
Chromium-based browser or Firefox if possible.
|
||||
|
||||
.. _doc_javascript_export_options:
|
||||
|
||||
@@ -200,12 +193,6 @@ The default HTML page does not display the boot splash while loading. However,
|
||||
the image is exported as a PNG file, so :ref:`custom HTML pages <doc_customizing_html5_shell>`
|
||||
can display it.
|
||||
|
||||
Shader language limitations
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
When exporting a GLES2 project to HTML5, WebGL 1.0 will be used. WebGL 1.0
|
||||
doesn't support dynamic loops, so shaders using those won't work there.
|
||||
|
||||
Serving the files
|
||||
-----------------
|
||||
|
||||
|
||||
@@ -274,8 +274,8 @@ but attempting to port it to mobile at the last minute is a recipe for disaster.
|
||||
|
||||
In general, you should design your game for the lowest common denominator, then
|
||||
add optional enhancements for more powerful platforms. For example, you may want
|
||||
to use the GLES2 backend for both desktop and mobile platforms where you target
|
||||
both.
|
||||
to use the Compatibility rendering method for both desktop and mobile platforms
|
||||
where you target both.
|
||||
|
||||
Mobile/tiled renderers
|
||||
======================
|
||||
|
||||
@@ -229,7 +229,7 @@ to loop over all the instances and set their transform to a random position.
|
||||
Running this script will place the fish in random positions in a box around the position of the
|
||||
MultiMeshInstance3D.
|
||||
|
||||
.. note:: If performance is an issue for you, try running the scene with GLES2 or with fewer fish.
|
||||
.. note:: If performance is an issue for you, try running the scene with fewer fish.
|
||||
|
||||
Notice how all the fish are all in the same position in their swim cycle? It makes them look very
|
||||
robotic. The next step is to give each fish a different position in the swim cycle so the entire
|
||||
|
||||
@@ -13,9 +13,6 @@ To make each instance move in an interesting way, we will use a
|
||||
:ref:`GPUParticles3D <class_GPUParticles3D>` node. Particles take advantage of GPU acceleration
|
||||
by computing and setting the per-instance information in a :ref:`Shader <class_Shader>`.
|
||||
|
||||
.. note:: Particles are not available in GLES2, instead use :ref:`CPUParticles3D <class_CPUParticles3D>`,
|
||||
which do the same thing as Particles, but do not benefit from GPU acceleration.
|
||||
|
||||
First create a Particles node. Then, under "Draw Passes" set the Particle's "Draw Pass 1" to your
|
||||
:ref:`Mesh <class_Mesh>`. Then under "Process Material" create a new
|
||||
:ref:`ShaderMaterial <class_ShaderMaterial>`.
|
||||
|
||||
@@ -20,8 +20,15 @@ to the fragment shader for pixel-processing. Because of this, transform feedback
|
||||
shaders can build on themselves each run, unlike other shaders that discard the
|
||||
data they have calculated once they draw to the frame buffer.
|
||||
|
||||
.. note:: Particle shaders are only available in the GLES3 backend. If you need
|
||||
particles in GLES2, use :ref:`CPUParticles3D <class_CPUParticles3D>`.
|
||||
.. note::
|
||||
|
||||
Particle shaders are only available with GPU-based particle nodes
|
||||
(:ref:`class_GPUParticles2D` and :ref:`class_GPUParticles3D`).
|
||||
|
||||
CPU-based particle nodes (:ref:`class_CPUParticles2D` and
|
||||
:ref:`class_CPUParticles3D`) are *rendered* on the GPU (which means they can
|
||||
use custom CanvasItem or Spatial shaders), but their motion is *simulated*
|
||||
on the CPU.
|
||||
|
||||
Render modes
|
||||
^^^^^^^^^^^^
|
||||
|
||||
@@ -548,11 +548,6 @@ larger the epsilon value should be.
|
||||
See `floating-point-gui.de <https://floating-point-gui.de/>`__ for more
|
||||
information.
|
||||
|
||||
.. warning::
|
||||
|
||||
When exporting a GLES2 project to HTML5, WebGL 1.0 will be used. WebGL 1.0
|
||||
doesn't support dynamic loops, so shaders using those won't work there.
|
||||
|
||||
Discarding
|
||||
----------
|
||||
|
||||
@@ -875,7 +870,7 @@ table of the corresponding types:
|
||||
+----------------------+-------------------------+------------------------------------------------------------+
|
||||
| **samplerCubeArray** | **CubemapArray** | |
|
||||
+----------------------+-------------------------+------------------------------------------------------------+
|
||||
|
||||
|
||||
.. note:: Be careful when setting shader uniforms from GDScript, no error will
|
||||
be thrown if the type does not match. Your shader will just exhibit
|
||||
undefined behavior.
|
||||
|
||||
@@ -170,8 +170,9 @@ shader, this value can be used as desired.
|
||||
+----------------------------------------+--------------------------------------------------------+
|
||||
| in vec3 **CAMERA_DIRECTION_WORLD** | Camera world space direction. |
|
||||
+----------------------------------------+--------------------------------------------------------+
|
||||
| in bool **OUTPUT_IS_SRGB** | ``true`` when calculations happen in sRGB color space |
|
||||
| | (``true`` in GLES2, ``false`` in GLES3). |
|
||||
| in bool **OUTPUT_IS_SRGB** | ``true`` when output is in sRGB color space |
|
||||
| | (this is ``true`` in the Compatibility renderer, |
|
||||
| | ``false`` in Forward+ and Forward Mobile). |
|
||||
+----------------------------------------+--------------------------------------------------------+
|
||||
| in int **INSTANCE_ID** | Instance ID for instancing. |
|
||||
+----------------------------------------+--------------------------------------------------------+
|
||||
@@ -259,7 +260,8 @@ these properties, and if you don't write to them, Godot will optimize away the c
|
||||
+----------------------------------------+--------------------------------------------------------------------------------------------------+
|
||||
| in vec2 **POINT_COORD** | Point Coordinate for drawing points with POINT_SIZE. |
|
||||
+----------------------------------------+--------------------------------------------------------------------------------------------------+
|
||||
| in bool **OUTPUT_IS_SRGB** | ``true`` when calculations happen in sRGB color space (``true`` in GLES2, ``false`` in GLES3). |
|
||||
| in bool **OUTPUT_IS_SRGB** | ``true`` when output is in sRGB color space (this is ``true`` in the Compatibility renderer, |
|
||||
| | ``false`` in Forward+ and Forward Mobile). |
|
||||
+----------------------------------------+--------------------------------------------------------------------------------------------------+
|
||||
| in mat4 **MODEL_MATRIX** | Model space to world space transform. |
|
||||
+----------------------------------------+--------------------------------------------------------------------------------------------------+
|
||||
@@ -442,8 +444,9 @@ If you want the lights to add together, add the light contribution to ``DIFFUSE_
|
||||
+-----------------------------------+----------------------------------------------------+
|
||||
| in float **ROUGHNESS** | Roughness. |
|
||||
+-----------------------------------+----------------------------------------------------+
|
||||
| in bool **OUTPUT_IS_SRGB** | ``true`` when calculations happen in sRGB color |
|
||||
| | space (``true`` in GLES2, ``false`` in GLES3). |
|
||||
| in bool **OUTPUT_IS_SRGB** | ``true`` when output is in sRGB color space |
|
||||
| | (this is ``true`` in the Compatibility renderer, |
|
||||
| | ``false`` in Forward+ and Forward Mobile). |
|
||||
+-----------------------------------+----------------------------------------------------+
|
||||
| out vec3 **DIFFUSE_LIGHT** | Diffuse light result. |
|
||||
+-----------------------------------+----------------------------------------------------+
|
||||
|
||||
@@ -11,7 +11,7 @@ auto-formatting tools.
|
||||
Since the Godot shader language is close to C-style languages and GLSL, this
|
||||
guide is inspired by Godot's own GLSL formatting. You can view an example of a
|
||||
GLSL file in Godot's source code
|
||||
`here <https://github.com/godotengine/godot/blob/master/drivers/gles2/shaders/copy.glsl>`__.
|
||||
`here <https://github.com/godotengine/godot/blob/master/drivers/gles3/shaders/copy.glsl>`__.
|
||||
|
||||
Style guides aren't meant as hard rulebooks. At times, you may not be able to
|
||||
apply some of the guidelines below. When that happens, use your best judgment,
|
||||
|
||||
@@ -152,8 +152,3 @@ The ``Switch`` node returns a vector if the boolean condition is ``true`` or
|
||||
boolean, all components of the vector should be above zero.
|
||||
|
||||
.. image:: img/vs_switch.png
|
||||
|
||||
.. note::
|
||||
|
||||
The ``Switch`` node is only available on the GLES3 backed. If you are
|
||||
targeting GLES2 devices, you cannot use ``switch`` statements.
|
||||
|
||||
Reference in New Issue
Block a user