mirror of
https://github.com/stan220/godot-docs.git
synced 2026-09-08 19:29:06 +00:00
Standardize RST header syntax
This commit is contained in:
tetrapod00
@@ -18,7 +18,7 @@ quality-of-life features. Accordingly, most features available in GLSL are
|
||||
available in Godot's shading language.
|
||||
|
||||
Shader programs
|
||||
^^^^^^^^^^^^^^^
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
In GLSL, each shader uses a separate program. You have one program for the
|
||||
vertex shader and one for the fragment shader. In Godot, you have a single
|
||||
@@ -30,7 +30,7 @@ fragment and vertex shaders in one file. In GLSL, the vertex and fragment
|
||||
programs cannot share variables except when varyings are used.
|
||||
|
||||
Vertex attributes
|
||||
^^^^^^^^^^^^^^^^^
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
In GLSL, you can pass in per-vertex information using attributes and have the
|
||||
flexibility to pass in as much or as little as you want. In Godot, you have a
|
||||
@@ -39,7 +39,7 @@ set number of input attributes, including ``VERTEX`` (position), ``COLOR``,
|
||||
of the documentation comes with a complete list of its vertex attributes.
|
||||
|
||||
gl_Position
|
||||
^^^^^^^^^^^
|
||||
~~~~~~~~~~~
|
||||
|
||||
``gl_Position`` receives the final position of a vertex specified in the vertex
|
||||
shader. It is specified by the user in clip space. Typically, in GLSL, the model
|
||||
@@ -56,7 +56,7 @@ to ``mat4(1.0)`` in order to nullify the final transform from view space to clip
|
||||
space.
|
||||
|
||||
Varyings
|
||||
^^^^^^^^
|
||||
~~~~~~~~
|
||||
|
||||
Varyings are a type of variable that can be passed from the vertex shader to the
|
||||
fragment shader. In modern GLSL (3.0 and up), varyings are defined with the
|
||||
@@ -64,7 +64,7 @@ fragment shader. In modern GLSL (3.0 and up), varyings are defined with the
|
||||
defined with ``out`` in the vertex shader and ``in`` inside the fragment shader.
|
||||
|
||||
Main
|
||||
^^^^
|
||||
~~~~
|
||||
|
||||
In GLSL, each shader program looks like a self-contained C-style program.
|
||||
Accordingly, the main entry point is ``main``. If you are copying a vertex
|
||||
@@ -72,7 +72,7 @@ shader, rename ``main`` to ``vertex`` and if you are copying a fragment shader,
|
||||
rename ``main`` to ``fragment``.
|
||||
|
||||
Macros
|
||||
^^^^^^
|
||||
~~~~~~
|
||||
|
||||
The :ref:`Godot shader preprocessor<doc_shader_preprocessor>` supports the following macros:
|
||||
|
||||
@@ -82,7 +82,7 @@ The :ref:`Godot shader preprocessor<doc_shader_preprocessor>` supports the follo
|
||||
* ``#pragma disable_preprocessor``, which disables preprocessing for the rest of the file
|
||||
|
||||
Variables
|
||||
^^^^^^^^^
|
||||
~~~~~~~~~
|
||||
|
||||
GLSL has many built-in variables that are hard-coded. These variables are not
|
||||
uniforms, so they are not editable from the main program.
|
||||
@@ -106,14 +106,14 @@ uniforms, so they are not editable from the main program.
|
||||
.. _glsl_coordinates:
|
||||
|
||||
Coordinates
|
||||
^^^^^^^^^^^
|
||||
~~~~~~~~~~~
|
||||
|
||||
``gl_FragCoord`` in GLSL and ``FRAGCOORD`` in the Godot shading language use the
|
||||
same coordinate system. If using UV in Godot, the y-coordinate will be flipped
|
||||
upside down.
|
||||
|
||||
Precision
|
||||
^^^^^^^^^
|
||||
~~~~~~~~~
|
||||
|
||||
In GLSL, you can define the precision of a given type (float or int) at the top
|
||||
of the shader with the ``precision`` keyword. In Godot, you can set the
|
||||
@@ -133,13 +133,13 @@ Shadertoy does not give the user full control over the shader. It handles all
|
||||
the input and uniforms and only lets the user write the fragment shader.
|
||||
|
||||
Types
|
||||
^^^^^
|
||||
~~~~~
|
||||
|
||||
Shadertoy uses the webgl spec, so it runs a slightly different version of GLSL.
|
||||
However, it still has the regular types, including constants and macros.
|
||||
|
||||
mainImage
|
||||
^^^^^^^^^
|
||||
~~~~~~~~~
|
||||
|
||||
The main point of entry to a Shadertoy shader is the ``mainImage`` function.
|
||||
``mainImage`` has two parameters, ``fragColor`` and ``fragCoord``, which
|
||||
@@ -149,7 +149,7 @@ them as parameters yourself. Anything in the ``mainImage`` function should be
|
||||
copied into the ``fragment`` function when porting to Godot.
|
||||
|
||||
Variables
|
||||
^^^^^^^^^
|
||||
~~~~~~~~~
|
||||
|
||||
In order to make writing fragment shaders straightforward and easy, Shadertoy
|
||||
handles passing a lot of helpful information from the main program into the
|
||||
@@ -187,7 +187,7 @@ what they can pass in as a substitute.
|
||||
+---------------------+---------+------------------------+-----------------------------------------------------+
|
||||
|
||||
Coordinates
|
||||
^^^^^^^^^^^
|
||||
~~~~~~~~~~~
|
||||
|
||||
``fragCoord`` behaves the same as ``gl_FragCoord`` in :ref:`GLSL
|
||||
<glsl_coordinates>` and ``FRAGCOORD`` in Godot.
|
||||
@@ -206,21 +206,21 @@ Shaders provides a `page <https://thebookofshaders.com/04>`_ on running shaders
|
||||
in various frameworks.
|
||||
|
||||
Types
|
||||
^^^^^
|
||||
~~~~~
|
||||
|
||||
The Book of Shaders uses the webgl spec, so it runs a slightly different version
|
||||
of GLSL. However, it still has the regular types, including constants and
|
||||
macros.
|
||||
|
||||
Main
|
||||
^^^^
|
||||
~~~~
|
||||
|
||||
The entry point for a Book of Shaders fragment shader is ``main``, just like in
|
||||
GLSL. Everything written in a Book of Shaders ``main`` function should be copied
|
||||
into Godot's ``fragment`` function.
|
||||
|
||||
Variables
|
||||
^^^^^^^^^
|
||||
~~~~~~~~~
|
||||
|
||||
The Book of Shaders sticks closer to plain GLSL than Shadertoy does. It also
|
||||
implements fewer uniforms than Shadertoy.
|
||||
@@ -240,7 +240,7 @@ implements fewer uniforms than Shadertoy.
|
||||
+---------------------+---------+------------------------+-----------------------------------------------------+
|
||||
|
||||
Coordinates
|
||||
^^^^^^^^^^^
|
||||
~~~~~~~~~~~
|
||||
|
||||
The Book of Shaders uses the same coordinate system as
|
||||
:ref:`GLSL <glsl_coordinates>`.
|
||||
|
||||
@@ -136,7 +136,7 @@ Each shader type has different render modes. See the reference for each shader
|
||||
type for a complete list of render modes.
|
||||
|
||||
Vertex processor
|
||||
^^^^^^^^^^^^^^^^
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
The ``vertex()`` processing function is called once for every vertex in
|
||||
``spatial`` and ``canvas_item`` shaders.
|
||||
@@ -151,7 +151,7 @@ data yourself; see the :ref:`Spatial shader doc <doc_spatial_shader>` for an
|
||||
example.
|
||||
|
||||
Fragment processor
|
||||
^^^^^^^^^^^^^^^^^^
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The ``fragment()`` processing function is used to set up the Godot material
|
||||
parameters per pixel. This code runs on every visible pixel the object or
|
||||
@@ -170,7 +170,7 @@ code out. Therefore, you will not waste calculations on the effects that you do
|
||||
not use.
|
||||
|
||||
Light processor
|
||||
^^^^^^^^^^^^^^^
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
The ``light()`` processor runs per pixel too, and it runs once for every light
|
||||
that affects the object. It does not run if no lights affect the object. It
|
||||
|
||||
@@ -4,7 +4,7 @@ Screen-reading shaders
|
||||
======================
|
||||
|
||||
Introduction
|
||||
~~~~~~~~~~~~
|
||||
------------
|
||||
|
||||
It is often desired to make a shader that reads from the same
|
||||
screen to which it's writing. 3D APIs, such as OpenGL or DirectX, make this very
|
||||
@@ -18,7 +18,7 @@ to a back-buffer and then read from it while drawing. Godot provides a
|
||||
few tools that make this process easy.
|
||||
|
||||
Screen texture
|
||||
~~~~~~~~~~~~~~
|
||||
--------------
|
||||
|
||||
Godot :ref:`doc_shading_language` has a special texture to access the already
|
||||
rendered contents of the screen. It is used by specifying a hint when declaring
|
||||
@@ -51,7 +51,7 @@ you.
|
||||
as with the ``0.0`` LOD parameter.
|
||||
|
||||
Screen texture example
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
----------------------
|
||||
|
||||
The screen texture can be used for many things. There is a
|
||||
special demo for *Screen Space Shaders*, that you can download to see
|
||||
@@ -79,7 +79,7 @@ and saturation:
|
||||
}
|
||||
|
||||
Behind the scenes
|
||||
~~~~~~~~~~~~~~~~~
|
||||
-----------------
|
||||
|
||||
While this seems magical, it's not. In 2D, when ``hint_screen_texture`` is first
|
||||
found in a node that is about to be drawn, Godot does a full-screen copy to a
|
||||
@@ -125,7 +125,7 @@ with a camera in the same position as your object, and then use the
|
||||
:ref:`Viewport's <class_Viewport>` texture instead of the screen texture.
|
||||
|
||||
Back-buffer logic
|
||||
~~~~~~~~~~~~~~~~~
|
||||
-----------------
|
||||
|
||||
So, to make it clearer, here's how the backbuffer copying logic works in 2D in
|
||||
Godot:
|
||||
@@ -148,7 +148,7 @@ Godot:
|
||||
|
||||
|
||||
Depth texture
|
||||
~~~~~~~~~~~~~
|
||||
-------------
|
||||
|
||||
For 3D shaders, it's also possible to access the screen depth buffer. For this,
|
||||
the ``hint_depth_texture`` hint is used. This texture is not linear; it must be
|
||||
@@ -167,7 +167,7 @@ The following code retrieves the 3D position below the pixel being drawn:
|
||||
}
|
||||
|
||||
Normal-roughness texture
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
------------------------
|
||||
|
||||
.. note::
|
||||
|
||||
@@ -189,7 +189,7 @@ roughness of objects rendered in the depth prepass. The normal is stored in the
|
||||
screen_normal = screen_normal * 2.0 - 1.0;
|
||||
|
||||
Redefining screen textures
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
--------------------------
|
||||
|
||||
The screen texture hints (``hint_screen_texture``, ``hint_depth_texture``, and
|
||||
``hint_normal_roughness_texture``) can be used with multiple uniforms. For
|
||||
|
||||
@@ -11,7 +11,7 @@ CanvasItem shaders contain fewer built-in variables and functionality than
|
||||
with vertex, fragment, and light processor functions.
|
||||
|
||||
Render modes
|
||||
^^^^^^^^^^^^
|
||||
------------
|
||||
|
||||
+---------------------------------+----------------------------------------------------------------------+
|
||||
| Render mode | Description |
|
||||
@@ -39,14 +39,14 @@ Render modes
|
||||
+---------------------------------+----------------------------------------------------------------------+
|
||||
|
||||
Built-ins
|
||||
^^^^^^^^^
|
||||
---------
|
||||
|
||||
Values marked as ``in`` are read-only. Values marked as ``out`` can optionally be written to and will
|
||||
not necessarily contain sensible values. Values marked as ``inout`` provide a sensible default
|
||||
value, and can optionally be written to. Samplers cannot be written to so they are not marked.
|
||||
|
||||
Global built-ins
|
||||
^^^^^^^^^^^^^^^^
|
||||
----------------
|
||||
|
||||
Global built-ins are available everywhere, including custom functions.
|
||||
|
||||
@@ -73,7 +73,7 @@ Global built-ins are available everywhere, including custom functions.
|
||||
+-------------------+------------------------------------------------------------------------------------------+
|
||||
|
||||
Vertex built-ins
|
||||
^^^^^^^^^^^^^^^^
|
||||
----------------
|
||||
|
||||
Vertex data (``VERTEX``) is presented in local space (pixel coordinates, relative to the Node2D's origin).
|
||||
If not written to, these values will not be modified and be passed through as they came.
|
||||
@@ -148,7 +148,7 @@ is usually:
|
||||
|
||||
|
||||
Fragment built-ins
|
||||
^^^^^^^^^^^^^^^^^^
|
||||
------------------
|
||||
|
||||
COLOR and TEXTURE
|
||||
~~~~~~~~~~~~~~~~~
|
||||
@@ -261,7 +261,7 @@ it to the ``NORMAL_MAP`` property. Godot will handle converting it for use in 2D
|
||||
+---------------------------------------------+---------------------------------------------------------------+
|
||||
|
||||
Light built-ins
|
||||
^^^^^^^^^^^^^^^
|
||||
---------------
|
||||
|
||||
Light processor functions work differently in Godot 4.x than they did in Godot
|
||||
3.x. In Godot 4.x all lighting is done during the regular draw pass. In other
|
||||
@@ -332,7 +332,7 @@ Below is an example of a light shader that takes a CanvasItem's normal map into
|
||||
+----------------------------------+------------------------------------------------------------------------------+
|
||||
|
||||
SDF functions
|
||||
^^^^^^^^^^^^^
|
||||
-------------
|
||||
|
||||
There are a few additional functions implemented to sample an automatically
|
||||
generated Signed Distance Field texture. These functions available for the ``fragment()``
|
||||
|
||||
@@ -19,14 +19,14 @@ every froxel that is touched by an axis aligned bounding box of the associated
|
||||
touch a given :ref:`FogVolume <class_FogVolume>` will still be used.
|
||||
|
||||
Built-ins
|
||||
^^^^^^^^^
|
||||
---------
|
||||
|
||||
Values marked as ``in`` are read-only. Values marked as ``out`` can optionally
|
||||
be written to and will not necessarily contain sensible values. Samplers cannot
|
||||
be written to so they are not marked.
|
||||
|
||||
Global built-ins
|
||||
^^^^^^^^^^^^^^^^
|
||||
----------------
|
||||
|
||||
Global built-ins are available everywhere, including in custom functions.
|
||||
|
||||
@@ -54,7 +54,7 @@ Global built-ins are available everywhere, including in custom functions.
|
||||
+-----------------------------------+------------------------------------------------------------------------------------------+
|
||||
|
||||
Fog built-ins
|
||||
^^^^^^^^^^^^^
|
||||
-------------
|
||||
|
||||
All of the output values of fog volumes overlap one another. This allows
|
||||
:ref:`FogVolumes <class_FogVolume>` to be rendered efficiently as they can all
|
||||
|
||||
@@ -28,7 +28,7 @@ take place over multiple frames.
|
||||
on the CPU.
|
||||
|
||||
Render modes
|
||||
^^^^^^^^^^^^
|
||||
------------
|
||||
|
||||
+--------------------------+-------------------------------------------+
|
||||
| Render mode | Description |
|
||||
@@ -43,14 +43,14 @@ Render modes
|
||||
+--------------------------+-------------------------------------------+
|
||||
|
||||
Built-ins
|
||||
^^^^^^^^^
|
||||
---------
|
||||
|
||||
Values marked as ``in`` are read-only. Values marked as ``out`` can optionally be written to and will
|
||||
not necessarily contain sensible values. Values marked as ``inout`` provide a sensible default
|
||||
value, and can optionally be written to. Samplers cannot be written to so they are not marked.
|
||||
|
||||
Global built-ins
|
||||
^^^^^^^^^^^^^^^^
|
||||
----------------
|
||||
|
||||
Global built-ins are available everywhere, including custom functions.
|
||||
|
||||
@@ -76,7 +76,7 @@ Global built-ins are available everywhere, including custom functions.
|
||||
+-------------------+------------------------------------------------------------------------------------------+
|
||||
|
||||
Start and Process built-ins
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
---------------------------
|
||||
|
||||
These properties can be accessed from both the ``start()`` and ``process()`` functions.
|
||||
|
||||
@@ -133,7 +133,7 @@ These properties can be accessed from both the ``start()`` and ``process()`` fun
|
||||
to ``true``. In a ShaderMaterial, access it with the ``COLOR`` variable.
|
||||
|
||||
Start built-ins
|
||||
^^^^^^^^^^^^^^^
|
||||
---------------
|
||||
|
||||
+---------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
|
||||
| Built-in | Description |
|
||||
@@ -150,7 +150,7 @@ Start built-ins
|
||||
+---------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
|
||||
|
||||
Process built-ins
|
||||
^^^^^^^^^^^^^^^^^
|
||||
-----------------
|
||||
|
||||
+------------------------------------+-------------------------------------------------------------------------------------------------------+
|
||||
| Built-in | Description |
|
||||
@@ -167,7 +167,7 @@ Process built-ins
|
||||
+------------------------------------+-------------------------------------------------------------------------------------------------------+
|
||||
|
||||
Process functions
|
||||
^^^^^^^^^^^^^^^^^
|
||||
-----------------
|
||||
|
||||
``emit_subparticle()`` is currently the only custom function supported by
|
||||
particles shaders. It allows users to add a new particle with specified
|
||||
|
||||
@@ -30,7 +30,7 @@ Directives
|
||||
----------
|
||||
|
||||
General syntax
|
||||
^^^^^^^^^^^^^^
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
- Preprocessor directives do not use brackets (``{}``), but can use parentheses.
|
||||
- Preprocessor directives **never** end with semicolons (with the exception of ``#define``,
|
||||
@@ -40,7 +40,7 @@ General syntax
|
||||
the preprocessor statement.
|
||||
|
||||
#define
|
||||
^^^^^^^
|
||||
~~~~~~~
|
||||
|
||||
**Syntax:** ``#define <identifier> [replacement_code]``.
|
||||
|
||||
@@ -110,7 +110,7 @@ Defining a ``#define`` for an identifier that is already defined results in an
|
||||
error. To prevent this, use ``#undef <identifier>``.
|
||||
|
||||
#undef
|
||||
^^^^^^
|
||||
~~~~~~
|
||||
|
||||
**Syntax:** ``#undef identifier``
|
||||
|
||||
@@ -138,7 +138,7 @@ The ``#undef`` directive may be used to cancel a previously defined ``#define``
|
||||
Without ``#undef`` in the above example, there would be a macro redefinition error.
|
||||
|
||||
#if
|
||||
^^^
|
||||
~~~
|
||||
|
||||
**Syntax:** ``#if <condition>``
|
||||
|
||||
@@ -232,7 +232,7 @@ high amounts of :abbr:`VGPRs (Vector General-Purpose Register)` (which can be ca
|
||||
having too many branches) can still slow down shader execution significantly.
|
||||
|
||||
#elif
|
||||
^^^^^
|
||||
~~~~~
|
||||
|
||||
The ``#elif`` directive stands for "else if" and checks the condition passed if
|
||||
the above ``#if`` evaluated to ``false``. ``#elif`` can only be used within an
|
||||
@@ -267,7 +267,7 @@ Like with ``#if``, the ``defined()`` preprocessor function can be used:
|
||||
#endif
|
||||
|
||||
#ifdef
|
||||
^^^^^^
|
||||
~~~~~~
|
||||
|
||||
**Syntax:** ``#ifdef <identifier>``
|
||||
|
||||
@@ -303,7 +303,7 @@ than two branches:
|
||||
#endif // This ends `SHADOW_QUALITY_HIGH`'s branch.
|
||||
|
||||
#ifndef
|
||||
^^^^^^^
|
||||
~~~~~~~
|
||||
|
||||
**Syntax:** ``#ifndef <identifier>``
|
||||
|
||||
@@ -327,7 +327,7 @@ where ``#ifdef`` would never match, and vice versa.
|
||||
#endif
|
||||
|
||||
#else
|
||||
^^^^^
|
||||
~~~~~
|
||||
|
||||
**Syntax:** ``#else``
|
||||
|
||||
@@ -349,14 +349,14 @@ Defines the optional block which is included when the previously defined ``#if``
|
||||
}
|
||||
|
||||
#endif
|
||||
^^^^^^
|
||||
~~~~~~
|
||||
|
||||
**Syntax:** ``#endif``
|
||||
|
||||
Used as terminator for the ``#if``, ``#ifdef``, ``#ifndef`` or subsequent ``#else`` directives.
|
||||
|
||||
#error
|
||||
^^^^^^
|
||||
~~~~~~
|
||||
|
||||
**Syntax:** ``#error <message>``
|
||||
|
||||
@@ -374,7 +374,7 @@ defined value.
|
||||
#endif
|
||||
|
||||
#include
|
||||
^^^^^^^^
|
||||
~~~~~~~~
|
||||
|
||||
**Syntax:** ``#include "path"``
|
||||
|
||||
@@ -440,7 +440,7 @@ Example base shader (using the include file we created above):
|
||||
}
|
||||
|
||||
#pragma
|
||||
^^^^^^^
|
||||
~~~~~~~
|
||||
|
||||
**Syntax:** ``#pragma value``
|
||||
|
||||
@@ -463,7 +463,7 @@ Built-in defines
|
||||
----------------
|
||||
|
||||
Current renderer
|
||||
^^^^^^^^^^^^^^^^
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
Since Godot 4.4, you can check which renderer is currently used with the built-in
|
||||
defines ``CURRENT_RENDERER``, ``RENDERER_COMPATIBILITY``, ``RENDERER_MOBILE``,
|
||||
|
||||
@@ -102,7 +102,7 @@ and the :ref:`radiance size <class_Sky_property_radiance_size>` to get the
|
||||
desired balance between performance and visual fidelity.
|
||||
|
||||
Render modes
|
||||
^^^^^^^^^^^^
|
||||
------------
|
||||
|
||||
Subpasses allow you to do more expensive calculations at a lower resolution
|
||||
to speed up your shaders. For example the following code renders clouds at
|
||||
@@ -137,14 +137,14 @@ a lower resolution than the rest of the sky:
|
||||
+--------------------------+-----------------------------------------------------------------------+
|
||||
|
||||
Built-ins
|
||||
^^^^^^^^^
|
||||
---------
|
||||
|
||||
Values marked as ``in`` are read-only. Values marked as ``out`` can optionally
|
||||
be written to and will not necessarily contain sensible values. Samplers cannot
|
||||
be written to so they are not marked.
|
||||
|
||||
Global built-ins
|
||||
^^^^^^^^^^^^^^^^
|
||||
----------------
|
||||
|
||||
Global built-ins are available everywhere, including in custom functions.
|
||||
|
||||
@@ -194,7 +194,7 @@ There are 4 ``LIGHTX`` lights, accessed as ``LIGHT0``, ``LIGHT1``, ``LIGHT2``, a
|
||||
+---------------------------------+--------------------------------------------------------------------------------------------------------------------------+
|
||||
|
||||
Sky built-ins
|
||||
^^^^^^^^^^^^^
|
||||
-------------
|
||||
|
||||
+-------------------------------+-------------------------------------------------------------------------------------------------+
|
||||
| Built-in | Description |
|
||||
|
||||
@@ -9,7 +9,7 @@ Spatial shaders are highly configurable with different render modes and differen
|
||||
write vertex, fragment, and light processor functions to affect how objects are drawn.
|
||||
|
||||
Render modes
|
||||
^^^^^^^^^^^^
|
||||
------------
|
||||
For visual examples of these render modes, see :ref:`Standard Material 3D and ORM Material 3D<doc_standard_material_3d>`.
|
||||
|
||||
+-------------------------------+------------------------------------------------------------------------------------------------------+
|
||||
@@ -87,14 +87,14 @@ For visual examples of these render modes, see :ref:`Standard Material 3D and OR
|
||||
+-------------------------------+------------------------------------------------------------------------------------------------------+
|
||||
|
||||
Built-ins
|
||||
^^^^^^^^^
|
||||
---------
|
||||
|
||||
Values marked as ``in`` are read-only. Values marked as ``out`` can optionally be written to and will
|
||||
not necessarily contain sensible values. Values marked as ``inout`` provide a sensible default
|
||||
value, and can optionally be written to. Samplers cannot be written to so they are not marked.
|
||||
|
||||
Global built-ins
|
||||
^^^^^^^^^^^^^^^^
|
||||
----------------
|
||||
|
||||
Global built-ins are available everywhere, including custom functions.
|
||||
|
||||
@@ -126,7 +126,7 @@ Global built-ins are available everywhere, including custom functions.
|
||||
+-----------------------------+-----------------------------------------------------------------------------------------------------+
|
||||
|
||||
Vertex built-ins
|
||||
^^^^^^^^^^^^^^^^
|
||||
----------------
|
||||
|
||||
Vertex data (``VERTEX``, ``NORMAL``, ``TANGENT``, and ``BITANGENT``) are presented in model space
|
||||
(also called local space). If not written to, these values will not be modified and be
|
||||
@@ -268,7 +268,7 @@ shader, this value can be used as desired.
|
||||
``INV_VIEW_MATRIX`` is the matrix used for rendering the object in that pass, unlike ``MAIN_CAM_INV_VIEW_MATRIX``, which is the matrix of the camera in the scene. In the shadow pass, ``INV_VIEW_MATRIX``'s view is based on the camera that is located at the position of the light.
|
||||
|
||||
Fragment built-ins
|
||||
^^^^^^^^^^^^^^^^^^
|
||||
------------------
|
||||
|
||||
The default use of a Godot fragment processor function is to set up the material properties of your object
|
||||
and to let the built-in renderer handle the final shading. However, you are not required to use all
|
||||
@@ -421,7 +421,7 @@ these properties, and if you don't write to them, Godot will optimize away the c
|
||||
for more information and ways to avoid issues.
|
||||
|
||||
Light built-ins
|
||||
^^^^^^^^^^^^^^^
|
||||
---------------
|
||||
|
||||
Writing light processor functions is completely optional. You can skip the ``light()`` function by using
|
||||
the ``unshaded`` render mode. If no light function is written, Godot will use the material properties
|
||||
|
||||
@@ -157,7 +157,7 @@ Below are some special nodes that are worth knowing about. The list is not
|
||||
exhaustive and might be expanded with more nodes and examples.
|
||||
|
||||
Expression node
|
||||
+++++++++++++++
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
The ``Expression`` node allows you to write Godot Shading Language (GLSL-like)
|
||||
expressions inside your visual shaders. The node has buttons to add any amount
|
||||
@@ -175,7 +175,7 @@ procedures, and use all the power of text-based shaders, such as loops, the
|
||||
.. image:: img/vs_expression2.png
|
||||
|
||||
Reroute node
|
||||
++++++++++++
|
||||
~~~~~~~~~~~~
|
||||
|
||||
The ``Reroute`` node is used purely for organizational purposes. In a complicated
|
||||
shader with many nodes you may find that the paths between nodes can make
|
||||
@@ -191,7 +191,7 @@ appears.
|
||||
.. image:: img/vs_reroute_handle.webp
|
||||
|
||||
Fresnel node
|
||||
++++++++++++
|
||||
~~~~~~~~~~~~
|
||||
|
||||
The ``Fresnel`` node is designed to accept normal and view vectors and produces
|
||||
a scalar which is the saturated dot product between them. Additionally, you can
|
||||
@@ -201,7 +201,7 @@ adding a rim-like lighting effect to objects.
|
||||
.. image:: img/vs_fresnel.webp
|
||||
|
||||
Boolean node
|
||||
++++++++++++
|
||||
~~~~~~~~~~~~
|
||||
|
||||
The ``Boolean`` node can be converted to ``Scalar`` or ``Vector`` to represent
|
||||
``0`` or ``1`` and ``(0, 0, 0)`` or ``(1, 1, 1)`` respectively. This property
|
||||
@@ -210,7 +210,7 @@ can be used to enable or disable some effect parts with one click.
|
||||
.. image:: img/vs_boolean.gif
|
||||
|
||||
If node
|
||||
+++++++
|
||||
~~~~~~~
|
||||
|
||||
The ``If`` node allows you to setup a vector which will be returned the result
|
||||
of the comparison between ``a`` and ``b``. There are three vectors which can be
|
||||
@@ -221,7 +221,7 @@ comparison threshold – by default it is equal to the minimal value, i.e.
|
||||
.. image:: img/vs_if.png
|
||||
|
||||
Switch node
|
||||
+++++++++++
|
||||
~~~~~~~~~~~
|
||||
|
||||
The ``Switch`` node returns a vector if the boolean condition is ``true`` or
|
||||
``false``. ``Boolean`` was introduced above. If you convert a vector to a true
|
||||
|
||||
@@ -130,7 +130,7 @@ other functions or to assign values to ``COLOR`` directly.
|
||||
.. image:: img/UV.png
|
||||
|
||||
Using ``TEXTURE`` built-in
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The default fragment function reads from the set Sprite2D texture and displays it.
|
||||
|
||||
@@ -159,7 +159,7 @@ this variable. Use them to redraw the Sprite2D with the texture.
|
||||
.. image:: img/blue-tex.png
|
||||
|
||||
Uniform input
|
||||
^^^^^^^^^^^^^
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
Uniform input is used to pass data into a shader that will be the same across
|
||||
the entire shader.
|
||||
@@ -191,7 +191,7 @@ declared. If you change the value in the editor, it will overwrite the default
|
||||
value you provided in the shader.
|
||||
|
||||
Interacting with shaders from code
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
You can change uniforms from code using the function ``set_shader_parameter()``
|
||||
which is called on the node's material resource. With a Sprite2D node, the
|
||||
|
||||
Reference in New Issue
Block a user