mirror of
https://github.com/godotengine/godot-docs.git
synced 2026-01-05 22:09:56 +03:00
Misc heading fixes
This commit is contained in:
@@ -155,8 +155,8 @@ that is incompatible with the `open license <https://opensource.org/licenses/MIT
|
||||
provided by Godot. That being said, FBX support could still be provided by third parties
|
||||
as a plugin. (See Plugins question above.)
|
||||
|
||||
Will [Insert closed SDK such as PhysX, GameWorks, etc.] be supported in Godot?
|
||||
------------------------------------------------------------------------------
|
||||
Will [insert closed SDK such as FMOD, GameWorks, etc.] be supported in Godot?
|
||||
-----------------------------------------------------------------------------
|
||||
|
||||
The aim of Godot is to create a free and open-source MIT-licensed engine that
|
||||
is modular and extendable. There are no plans for the core engine development
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
.. _doc_docs_writing_guidelines:
|
||||
|
||||
Docs writing guidelines
|
||||
=============================
|
||||
=======================
|
||||
|
||||
The Godot community is rich and international. Users come from all
|
||||
around the world. Some of them are young, and many aren't native English
|
||||
@@ -35,7 +35,6 @@ There are 3 rules to describe classes:
|
||||
7 rules for a clear english
|
||||
---------------------------
|
||||
|
||||
|
||||
Use the direct voice
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@@ -229,7 +228,7 @@ If you need to repeat the same variable name 3 or 4 times, you probably
|
||||
need to rephrase your description.
|
||||
|
||||
Use 's to show possession
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Avoid "The milk **of** the cow". It feels unnatural in English. Write "The cow's
|
||||
milk" instead.
|
||||
@@ -336,7 +335,7 @@ For boolean member variables, always use ``if true`` and/or
|
||||
``if false``, to stay explicit. ``Controls whether or not`` may be
|
||||
ambiguous and won't work for every member variable.
|
||||
|
||||
Also surround boolean values, variable names and methods with [code][/code].
|
||||
Also surround boolean values, variable names and methods with ``[code][/code]``.
|
||||
|
||||
**Do** start with "if true":
|
||||
|
||||
@@ -346,10 +345,10 @@ Also surround boolean values, variable names and methods with [code][/code].
|
||||
If [code]true[/code] the timer will automatically start when it enters the scene tree. Default value: [code]false[/code].
|
||||
|
||||
|
||||
Use [code] around arguments
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
Use ``[code]`` around arguments
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
In the class reference, always surround arguments with [code][/code]. In the documentation and in Godot, it will display like ``this``. When you edit XML files in the Godot repository, replace existing arguments written like 'this' or \`this\` with [code]this[/code].
|
||||
In the class reference, always surround arguments with ``[code][/code]``. In the documentation and in Godot, it will display like ``this``. When you edit XML files in the Godot repository, replace existing arguments written like 'this' or \`this\` with ``[code]this[/code]``.
|
||||
|
||||
|
||||
Common vocabulary to use in godot's docs
|
||||
@@ -386,7 +385,7 @@ class names, which you can't fold, are ``Classes`` e.g. the
|
||||
``properties``. E.g. ``position`` or ``modulate color`` are both
|
||||
``properties``.
|
||||
|
||||
Image Contribution guidelines
|
||||
Image contribution guidelines
|
||||
-----------------------------
|
||||
|
||||
A significant part of the documentation is images, and there are several important
|
||||
|
||||
@@ -75,7 +75,7 @@ Run configuration:
|
||||
|
||||
.. image:: img/qtcreator-run-command.png
|
||||
|
||||
Updating Sources after pulling latest commits
|
||||
Updating sources after pulling latest commits
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
As a developer you usually want to frequently pull the latest commits
|
||||
@@ -178,7 +178,7 @@ That's it! Now you should be good to go :)
|
||||
Xcode
|
||||
-----
|
||||
|
||||
Project Setup
|
||||
Project setup
|
||||
^^^^^^^^^^^^^
|
||||
|
||||
- Create an Xcode external build project anywhere
|
||||
@@ -227,7 +227,7 @@ Add Godot Source to the Project:
|
||||
- Grab a cup of coffee... Maybe make something to eat, too
|
||||
- You should have jump to definition, auto completion, and full syntax highlighting when it is done.
|
||||
|
||||
Scheme Setup
|
||||
Scheme setup
|
||||
^^^^^^^^^^^^
|
||||
|
||||
Edit Build Scheme of External Build Target:
|
||||
@@ -295,6 +295,4 @@ To create them:
|
||||
|
||||
- You can now start Debug process again to test that everything works.
|
||||
|
||||
- If build phase fails, check console for hints. On Linux it's most likely that some dependencies are missing. Check :ref:`Compiling for X11 (Linux, \*BSD) <doc_compiling_for_x11>`
|
||||
|
||||
|
||||
- If the build phase fails, check console for hints. On Linux it's most likely that some dependencies are missing. Check :ref:`Compiling for X11 (Linux, \*BSD) <doc_compiling_for_x11>`
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
.. _doc_gdscript:
|
||||
|
||||
GDScript
|
||||
========
|
||||
GDScript basics
|
||||
===============
|
||||
|
||||
Introduction
|
||||
------------
|
||||
|
||||
@@ -19,7 +19,7 @@ palette from where you can drag and drop all sorts of information to the script
|
||||
.. image:: img/visual_script2.png
|
||||
|
||||
|
||||
Creating a Script
|
||||
Creating a script
|
||||
-----------------
|
||||
|
||||
Creating scripts works the same as with other scripting languages: Select any node in the scene
|
||||
@@ -39,7 +39,7 @@ Finally, the Script Editor will open, allowing you to start editing the visual s
|
||||
.. image:: img/visual_script5.png
|
||||
|
||||
|
||||
Adding a Function
|
||||
Adding a function
|
||||
-----------------
|
||||
|
||||
Unlike other visual scripting implementations, Visual Scripting in Godot is heavily based on functions.
|
||||
@@ -52,7 +52,7 @@ A single script can contain many functions, each of which will have a canvas of
|
||||
|
||||
There are three main ways to add functions in a script:
|
||||
|
||||
Overriding a Virtual Function
|
||||
Overriding a virtual function
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Most types of nodes and other types of objects in Godot contain virtual functions. These are functions that
|
||||
@@ -79,7 +79,7 @@ provided:
|
||||
.. image:: img/visual_script9.png
|
||||
|
||||
|
||||
Connecting a Signal to a Function
|
||||
Connecting a signal to a function
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Nodes in a tree emit signals when something happens. Godot uses signals for all sorts of things.
|
||||
@@ -103,7 +103,7 @@ connected to it:
|
||||
.. image:: img/visual_script12.png
|
||||
|
||||
|
||||
Creating a Function Manually
|
||||
Creating a function manually
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The last way to create functions is to do it manually. In general, this is not as common unless you
|
||||
|
||||
@@ -369,7 +369,7 @@ create the life bar. It's the same for the ``Counter``.
|
||||
|
||||
With no extra changes, our Bar is ready to use
|
||||
|
||||
Use Scene Inheritance to create the remaining elements
|
||||
Use scene inheritance to create the remaining elements
|
||||
------------------------------------------------------
|
||||
|
||||
We need two bars that work the same way: they should feature a label on
|
||||
|
||||
@@ -1,9 +1,13 @@
|
||||
Godot-Blender-Exporter
|
||||
======================
|
||||
Blender ESCN exporter
|
||||
=====================
|
||||
|
||||
.. note:: This chapter relates to the blender plugin called "Godot-Blender-Exporter",
|
||||
.. note:: This chapter relates to the Blender plugin called "Godot Blender Exporter",
|
||||
which can be downloaded here: https://github.com/godotengine/godot-blender-exporter
|
||||
|
||||
This plugin can be used to export Blender scenes in a Godot-specific scene format
|
||||
called ESCN, which is similar to TSCN (text format) but will be imported as binary
|
||||
SCN for performance.
|
||||
|
||||
Details on exporting
|
||||
--------------------
|
||||
|
||||
@@ -22,7 +26,7 @@ Details on exporting
|
||||
Disabling specific objects
|
||||
--------------------------
|
||||
|
||||
Sometimes you don't want some objects exported (eg high-res models used for
|
||||
Sometimes you don't want some objects exported (e.g. high-res models used for
|
||||
baking). An object will not be exported if it is not rendered in the scene.
|
||||
This can be set in the outliner:
|
||||
|
||||
|
||||
@@ -34,7 +34,7 @@ Here is a comparative chart.
|
||||
|
||||
In general, what is recommended, is to use WAV for most sound effects, especially those that are short and repetitive, and OGG for music, voice and long sound effects.
|
||||
|
||||
Best Practices
|
||||
Best practices
|
||||
--------------
|
||||
|
||||
Godot 3+ has an amazing bus system with built-in effects. This saves
|
||||
@@ -60,12 +60,10 @@ this.
|
||||
Looping
|
||||
~~~~~~~
|
||||
|
||||
Godot supports looping in the samples (Tools such as Sound Forge or
|
||||
Godot supports looping in the samples (tools such as Sound Forge or
|
||||
Audition can add loop points to wav files). This is useful for sound
|
||||
effects, such as engines, machine guns etc. Ping-pong looping is also
|
||||
supported.
|
||||
|
||||
As an alternative, the import screen has a "loop" option that enables
|
||||
looping for the entire sample when importing.
|
||||
|
||||
|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
Importing 3D scenes
|
||||
===================
|
||||
|
||||
Godot Scene Importer
|
||||
Godot scene importer
|
||||
--------------------
|
||||
|
||||
When dealing with 3D assets, Godot has a flexible and configurable importer.
|
||||
@@ -70,7 +70,7 @@ import a scene with:
|
||||
* External meshes: Where each mesh is saved to a different file. Many users prefer to deal with meshes directly.
|
||||
* External animations: Allowing saved animations to be modified and merged when sources change.
|
||||
* External scenes: Save each of the root nodes of the imported scenes as a separate scene.
|
||||
* Single Scene: A single scene file with everything built in.
|
||||
* Single scene: A single scene file with everything built in.
|
||||
|
||||
.. image:: img/scene_import1.png
|
||||
|
||||
@@ -147,7 +147,7 @@ most 3D DCCs don't have the same material options as those present in Godot.
|
||||
When materials are built-in, they will be lost each time the source scene
|
||||
is modified and re-imported.
|
||||
|
||||
Keep on Reimport
|
||||
Keep On Reimport
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
Once materials are edited to use Godot features, the importer will keep the
|
||||
@@ -207,7 +207,7 @@ External Files
|
||||
Generated meshes and materials can be optionally stored in a subdirectory with the
|
||||
name of the scene.
|
||||
|
||||
Animation Options
|
||||
Animation options
|
||||
-----------------
|
||||
|
||||
Godot provides many options regarding how animation data is dealt with. Some exporters
|
||||
@@ -238,7 +238,6 @@ Storage
|
||||
By default, animations are saved as built-in. It is possible to save them to a file instead. This
|
||||
allows adding custom tracks to the animations and keeping them after a reimport.
|
||||
|
||||
|
||||
Optimizer
|
||||
~~~~~~~~~
|
||||
|
||||
|
||||
@@ -67,7 +67,7 @@ uppercase, to differentiate from other strings). Here's an example:
|
||||
| BYE | Good Bye | Adiós | さようなら |
|
||||
+---------+------------------+----------------+--------------+
|
||||
|
||||
CSV Importer
|
||||
CSV importer
|
||||
------------
|
||||
|
||||
Godot will treat CSV files as translations by default. It will import them
|
||||
|
||||
@@ -117,8 +117,8 @@ in many sections of the project settings.
|
||||
|
||||
.. image:: img/feature_tags4.png
|
||||
|
||||
Customizing Build
|
||||
------------------
|
||||
Customizing the build
|
||||
---------------------
|
||||
|
||||
Feature tags can be used to customize a build process too, by writing a custom **ExportPlugin**.
|
||||
They are also used to specify which shared library is loaded and exported in **GDNative**.
|
||||
|
||||
@@ -8,7 +8,7 @@
|
||||
canvas_layers
|
||||
2d_transforms
|
||||
using_tilemaps
|
||||
custom_drawing_in_2d
|
||||
particle_systems_2d
|
||||
2d_movement
|
||||
2d_lights_and_shadows
|
||||
custom_drawing_in_2d
|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
Part 5
|
||||
======
|
||||
|
||||
Part Overview
|
||||
Part overview
|
||||
-------------
|
||||
|
||||
In this part, we're going to add grenades to the player, give the player the ability to grab and throw objects, and add turrets!
|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
Part 4
|
||||
======
|
||||
|
||||
Part Overview
|
||||
Part overview
|
||||
-------------
|
||||
|
||||
In this part, we will be adding health pickups, ammo pickups, targets the player can destroy, support for joypads, and add the ability to change weapons with the scroll wheel.
|
||||
|
||||
@@ -63,7 +63,7 @@ Feel free to use these assets however you want! All original assets belong to th
|
||||
|
||||
.. tip:: You can find the finished project for each part at the bottom of each part's page
|
||||
|
||||
Part Overview
|
||||
Part overview
|
||||
-------------
|
||||
|
||||
In this part we will be making a first person player that can move around
|
||||
@@ -76,6 +76,7 @@ sprint, look around with a mouse based first person camera, jump into the air, a
|
||||
|
||||
Getting everything ready
|
||||
------------------------
|
||||
|
||||
Launch Godot and open up the project included in the starter assets.
|
||||
|
||||
.. note:: While these assets are not necessarily required to use the scripts provided in this tutorial,
|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
Part 6
|
||||
======
|
||||
|
||||
Part Overview
|
||||
Part overview
|
||||
-------------
|
||||
|
||||
In this part, we're going to add a main menu and pause menu,
|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
Part 3
|
||||
======
|
||||
|
||||
Part Overview
|
||||
Part overview
|
||||
-------------
|
||||
|
||||
In this part, we will be limiting the player's weapons by giving them ammo. We will also
|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
Part 2
|
||||
======
|
||||
|
||||
Part Overview
|
||||
Part overview
|
||||
-------------
|
||||
|
||||
In this part we will be giving our player weapons to play with.
|
||||
|
||||
@@ -54,35 +54,43 @@ Below are descriptions of the options.
|
||||
|
||||
Target Surface
|
||||
++++++++++++++
|
||||
|
||||
The mesh used as the target surface on which to place copies of your
|
||||
source mesh.
|
||||
|
||||
Source Mesh
|
||||
+++++++++++
|
||||
|
||||
The mesh you want duplicated on the target surface.
|
||||
|
||||
Mesh Up Axis
|
||||
++++++++++++
|
||||
|
||||
The axis used as the up axis of the source mesh.
|
||||
|
||||
Random Rotation
|
||||
+++++++++++++++
|
||||
|
||||
Randomizing the rotation around the up axis of the source mesh.
|
||||
|
||||
Random Tilt
|
||||
+++++++++++
|
||||
|
||||
Randomizing the overall rotation of the source mesh.
|
||||
|
||||
Random Scale
|
||||
++++++++++++
|
||||
|
||||
Randomizing the scale of the source mesh.
|
||||
|
||||
Scale
|
||||
+++++
|
||||
|
||||
The scale of the source mesh that will be placed over the target surface.
|
||||
|
||||
Amount
|
||||
++++++
|
||||
|
||||
The amount of mesh instances placed over the target surface.
|
||||
|
||||
Select the target surface. In the tree case, this should be the landscape node.
|
||||
|
||||
@@ -343,7 +343,7 @@ Or you can browse it using the web-interface:
|
||||
|
||||
https://github.com/slapin/godot-skel3d
|
||||
|
||||
Using 3D "bones" to implement Inverse Kinematics
|
||||
Using 3D "bones" to implement inverse kinematics
|
||||
------------------------------------------------
|
||||
|
||||
See :ref:`doc_inverse_kinematics`.
|
||||
|
||||
@@ -197,11 +197,11 @@ Using multiple threads
|
||||
ResourceInteractiveLoader can be used from multiple threads. A couple of
|
||||
things to keep in mind if you attempt it:
|
||||
|
||||
Use a Semaphore
|
||||
Use a semaphore
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
While your thread waits for the main thread to request a new resource,
|
||||
use a Semaphore to sleep (instead of a busy loop or anything similar).
|
||||
use a ``Semaphore`` to sleep (instead of a busy loop or anything similar).
|
||||
|
||||
Not blocking main thread during the polling
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
.. _doc_kinematic_character_2d:
|
||||
|
||||
Kinematic Character (2D)
|
||||
Kinematic character (2D)
|
||||
========================
|
||||
|
||||
Introduction
|
||||
@@ -18,7 +18,7 @@ physics engines (or a lot of patience with trial and error).
|
||||
|
||||
Some physics engines, such as Havok seem to swear by dynamic character
|
||||
controllers as the best option, while others (PhysX) would rather
|
||||
promote the Kinematic one.
|
||||
promote the kinematic one.
|
||||
|
||||
So, what is the difference?:
|
||||
|
||||
@@ -107,7 +107,7 @@ map scene the main one, so it runs when pressing play.
|
||||
|
||||
.. image:: img/kbinstance.png
|
||||
|
||||
Moving the Kinematic character
|
||||
Moving the kinematic character
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Go back to the character scene, and open the script, the magic begins
|
||||
|
||||
@@ -23,7 +23,7 @@ In this guide, you will learn:
|
||||
and collision shape has a direct equivalent in 3D and in most cases
|
||||
they work in much the same way.
|
||||
|
||||
Collision Objects
|
||||
Collision objects
|
||||
-----------------
|
||||
|
||||
Godot offers four kinds of physics bodies, extending :ref:`CollisionObject2D <class_CollisionObject2D>`:
|
||||
@@ -51,7 +51,7 @@ The other three bodies extend :ref:`PhysicsBody2D <class_PhysicsBody2D>`:
|
||||
A body that provides collision detection, but no physics. All movement and
|
||||
collision response must be implemented in code.
|
||||
|
||||
Collision Shapes
|
||||
Collision shapes
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
A physics body can hold any number of :ref:`Shape2D <class_Shape2D>` objects
|
||||
@@ -86,7 +86,7 @@ be run in the :ref:`Node._physics_process() <class_Node_method__physics_process>
|
||||
callback, which is called before each physics step at a constant frame rate
|
||||
(60 times per second by default).
|
||||
|
||||
Collision Layers and Masks
|
||||
Collision layers and masks
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
One of the most powerful, but frequently misunderstood, collision features
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
.. _doc_rigid_body:
|
||||
|
||||
RigidBody
|
||||
==========
|
||||
=========
|
||||
|
||||
What is a rigid body?
|
||||
---------------------
|
||||
@@ -21,7 +21,7 @@ As an example, consider a rigid body that you want to rotate so that it points t
|
||||
|
||||
The fact that you can't use ``set_global_transform()`` or ``look_at()`` methods doesn't mean that you can't have full control of a rigid body. Instead, you can control it by using the ``_integrate_forces()`` callback. In this method, you can add *forces*, apply *impulses*, or set the *velocity* in order to achieve any movement you desire.
|
||||
|
||||
The "Look at" method
|
||||
The "look at" method
|
||||
--------------------
|
||||
|
||||
As described above, using the Spatial node's ``look_at()`` method can't be used each frame to follow a target.
|
||||
|
||||
@@ -29,7 +29,7 @@ precise control over how they move and react.
|
||||
but you must calculate the movement in code. The physics engine will
|
||||
not move a `KinematicBody2D`.
|
||||
|
||||
Movement and Collision
|
||||
Movement and collision
|
||||
----------------------
|
||||
|
||||
When moving a ``KinematicBody2D``, you should not set its ``position`` property
|
||||
|
||||
@@ -370,7 +370,10 @@ use for building. For the purpose of this example, just use
|
||||
we've prepared. We'll cover a more customizable, detailed example on
|
||||
how to use these build files in a subsequent tutorial.
|
||||
|
||||
.. note:: This ``SConstruct`` file was written to be used with the latest godot-cpp master, you may need to make small changes using it with older versions or refer to the ``SConstruct`` file in the Godot 3.0 documentation.
|
||||
.. note:: This ``SConstruct`` file was written to be used with the latest
|
||||
``godot-cpp`` master, you may need to make small changes using it with
|
||||
older versions or refer to the ``SConstruct`` file in the Godot 3.0
|
||||
documentation.
|
||||
|
||||
Once you've downloaded the ``SConstruct`` file, place it in your
|
||||
GDNative module folder besides ``godot-cpp``, ``godot_headers``
|
||||
@@ -818,8 +821,8 @@ We've added a script on our main node and implemented our signal like this:
|
||||
Every second we simply output our position to the console.
|
||||
|
||||
|
||||
NativeScript 1.1 v.s. NativeScript 1.0
|
||||
--------------------------------------
|
||||
NativeScript 1.1 vs NativeScript 1.0
|
||||
------------------------------------
|
||||
|
||||
So far in our example above there doesn't seem to be a lot of difference
|
||||
between the old and new syntax. The class is defined slightly differently
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
.. _doc_migrating_to_godot_shader_language:
|
||||
|
||||
Migrating to Godot shading language
|
||||
===================================
|
||||
Migrating to Godot's shading language
|
||||
=====================================
|
||||
|
||||
Introduction
|
||||
------------
|
||||
@@ -19,7 +19,7 @@ GLSL
|
||||
Godot uses a shading language based on GLSL with the addition of a few quality-of-life features.
|
||||
Accordingly, most features available in GLSL are available in Godot's shading language.
|
||||
|
||||
Shader Programs
|
||||
Shader programs
|
||||
^^^^^^^^^^^^^^^
|
||||
|
||||
In GLSL each shader uses a separate program. You have one program for the vertex shader and one
|
||||
@@ -138,6 +138,7 @@ 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 correspond to ``COLOR`` and ``FRAGCOORD`` in Godot
|
||||
respectively. These parameters are handled automatically in Godot, so you do not need to include them
|
||||
@@ -146,6 +147,7 @@ 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 fragment shader for you. A few of these
|
||||
have no equivalents in Godot because Godot has chosen not to make them available by default.
|
||||
@@ -181,8 +183,8 @@ uniform themself. The description gives the reader a hint about what they can pa
|
||||
|
||||
Coordinates
|
||||
^^^^^^^^^^^
|
||||
``fragCoord`` behaves the same as ``gl_FragCoord`` in :ref:`GLSL <glsl_coordinates>` and ``FRAGCOORD`` in Godot.
|
||||
|
||||
``fragCoord`` behaves the same as ``gl_FragCoord`` in :ref:`GLSL <glsl_coordinates>` and ``FRAGCOORD`` in Godot.
|
||||
|
||||
|
||||
The Book of Shaders
|
||||
@@ -231,4 +233,3 @@ Coordinates
|
||||
^^^^^^^^^^^
|
||||
|
||||
The Book of Shaders uses the same coordinate system as :ref:`GLSL <glsl_coordinates>`.
|
||||
|
||||
|
||||
@@ -17,8 +17,8 @@ The workaround is to make a copy of the screen, or a part of the screen,
|
||||
to a back-buffer and then read from it while drawing. Godot provides a
|
||||
few tools that makes this process easy!
|
||||
|
||||
SCREEN_TEXTURE built-in texture.
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
SCREEN_TEXTURE built-in texture
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Godot :ref:`doc_shading_language` has a special texture, "SCREEN_TEXTURE" (and "DEPTH_TEXTURE" for depth, in case of 3D).
|
||||
It takes as parameter the UV of the screen and returns a vec3 RGB with the color. A
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
.. _doc_canvas_item_shader:
|
||||
|
||||
CanvasItem shaders
|
||||
===================
|
||||
==================
|
||||
|
||||
CanvasItem shaders are used to draw all 2D elements in Godot. These include
|
||||
all nodes that inherit from CanvasItems, and all GUI elements.
|
||||
@@ -10,11 +10,11 @@ CanvasItem shaders contain less built-in variables and functionality than Spatia
|
||||
shaders, but they maintain the same basic structure with vertex, fragment, and
|
||||
light processor functions.
|
||||
|
||||
Render Modes
|
||||
Render modes
|
||||
^^^^^^^^^^^^
|
||||
|
||||
+---------------------------------+----------------------------------------------------------------------+
|
||||
| Render Mode | Description |
|
||||
| Render mode | Description |
|
||||
+=================================+======================================================================+
|
||||
| **blend_mix** | Mix blend mode (alpha is transparency), default. |
|
||||
+---------------------------------+----------------------------------------------------------------------+
|
||||
@@ -33,8 +33,9 @@ Render Modes
|
||||
| **skip_vertex_transform** | VERTEX/NORMAL/etc need to be transformed manually in vertex function.|
|
||||
+---------------------------------+----------------------------------------------------------------------+
|
||||
|
||||
Vertex Built-Ins
|
||||
Vertex built-ins
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
Values marked as "in" are read-only. Values marked as "out" are for optional writing and will
|
||||
not necessarily contain sensible values. Values marked as "inout" provide a sensible default
|
||||
value, and can optionally be written to. Samplers are not subjects of writing and they are
|
||||
@@ -66,7 +67,7 @@ is usually:
|
||||
* **z**: Animation frame.
|
||||
|
||||
+--------------------------------+----------------------------------------------------------------+
|
||||
| Built-In | Description |
|
||||
| Built-in | Description |
|
||||
+================================+================================================================+
|
||||
| in mat4 **WORLD_MATRIX** | Image to World transform. |
|
||||
+--------------------------------+----------------------------------------------------------------+
|
||||
@@ -89,7 +90,7 @@ is usually:
|
||||
| inout float **POINT_SIZE** | Point size for point drawing. |
|
||||
+--------------------------------+----------------------------------------------------------------+
|
||||
|
||||
Fragment Built-Ins
|
||||
Fragment built-ins
|
||||
^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Certain Nodes (for example, :ref:`Sprites <class_Sprite>`) display a texture by default. However,
|
||||
@@ -111,7 +112,7 @@ it to the ``NORMALMAP`` property. Godot will handle converting it for use in 2D
|
||||
NORMALMAP = texture(NORMAL_TEXTURE, UV).rgb;
|
||||
|
||||
+----------------------------------+----------------------------------------------------------------+
|
||||
| Built-In | Description |
|
||||
| Built-in | Description |
|
||||
+==================================+================================================================+
|
||||
| in vec4 **FRAGCOORD** | Fragment coordinate, pixel adjusted. |
|
||||
+----------------------------------+----------------------------------------------------------------+
|
||||
@@ -148,8 +149,8 @@ it to the ``NORMALMAP`` property. Godot will handle converting it for use in 2D
|
||||
| in sampler2D **SCREEN_TEXTURE** | Screen texture, mipmaps contain gaussian blurred versions. |
|
||||
+----------------------------------+----------------------------------------------------------------+
|
||||
|
||||
Light Built-Ins
|
||||
^^^^^^^^^^^^^^^^
|
||||
Light built-ins
|
||||
^^^^^^^^^^^^^^^
|
||||
|
||||
Light processor functions work differently in 2D than they do in 3D. In CanvasItem shaders, the
|
||||
shader is called once for the object being drawn, and then once for each light touching that
|
||||
@@ -160,7 +161,7 @@ that object, this can be useful when you only want the object visible where it i
|
||||
When the shader is on a light pass the ``AT_LIGHT_PASS`` variable will be ``true``.
|
||||
|
||||
+-------------------------------------+-------------------------------------------------------------------------------+
|
||||
| Built-In | Description |
|
||||
| Built-in | Description |
|
||||
+=====================================+===============================================================================+
|
||||
| in vec4 **FRAGCOORD** | Fragment coordinate of pixel center. Origin at lower left. |
|
||||
+-------------------------------------+-------------------------------------------------------------------------------+
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
Shading Reference
|
||||
Shading reference
|
||||
=================
|
||||
|
||||
.. toctree::
|
||||
|
||||
@@ -23,11 +23,11 @@ data they have calculated once they draw to the frame buffer.
|
||||
.. note:: Particle shaders are only available in the GLES3 renderer. If you need
|
||||
particles in GLES2, use :ref:`CPUParticles <class_CPUParticles>`.
|
||||
|
||||
Render Modes
|
||||
Render modes
|
||||
^^^^^^^^^^^^
|
||||
|
||||
+---------------------------------+----------------------------------------------------------------------+
|
||||
| Render Mode | Description |
|
||||
| Render mode | Description |
|
||||
+=================================+======================================================================+
|
||||
| **keep_data** | Do not clear previous data on restart. |
|
||||
+---------------------------------+----------------------------------------------------------------------+
|
||||
@@ -36,8 +36,9 @@ Render Modes
|
||||
| **disable_velocity** | Ignore **VELOCITY** value. |
|
||||
+---------------------------------+----------------------------------------------------------------------+
|
||||
|
||||
Vertex Built-Ins
|
||||
Vertex built-ins
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
Values marked as "in" are read-only. Values marked as "out" are for optional writing and will
|
||||
not necessarily contain sensible values. Values marked as "inout" provide a sensible default
|
||||
value, and can optionally be written to. Samplers are not subjects of writing and they are
|
||||
@@ -47,7 +48,7 @@ In order to use the ``COLOR`` variable in a SpatialMaterial, set ``use_vertex_as
|
||||
to ``true``. In a ShaderMaterial, access it with the ``COLOR`` variable.
|
||||
|
||||
+---------------------------------+-------------------------------------------------------------------------------------+
|
||||
| Built-In | Description |
|
||||
| Built-in | Description |
|
||||
+=================================+=====================================================================================+
|
||||
| inout vec4 **COLOR** | Particle color, can be written to and accessed in mesh's vertex function. |
|
||||
+---------------------------------+-------------------------------------------------------------------------------------+
|
||||
|
||||
@@ -23,7 +23,7 @@ For more advanced shaders you can turn this functionality off using a render_mod
|
||||
This document provides you with some information about shaders, specific to Godot. For a detailed
|
||||
reference of the shading language in Godot see the :ref:`Godot shading language doc<doc_shading_language>`.
|
||||
|
||||
Shader Types
|
||||
Shader types
|
||||
------------
|
||||
|
||||
Instead of supplying a general purpose configuration for all uses (2D, 3D, particles),
|
||||
@@ -44,7 +44,7 @@ Valid types are:
|
||||
|
||||
For detailed information on each shading type see the corresponding reference document.
|
||||
|
||||
Render Modes
|
||||
Render modes
|
||||
------------
|
||||
|
||||
Different shader types support different render modes. They are optional and, if specified, must
|
||||
@@ -62,14 +62,14 @@ Render modes are specified underneath the shader type:
|
||||
Each shader type has a different list of render modes available. See the document for each shader
|
||||
type for a complete list of render modes.
|
||||
|
||||
Processor Functions
|
||||
Processor functions
|
||||
-------------------
|
||||
|
||||
Depending on the shader type, different processor functions may be optionally overridden.
|
||||
For "spatial" and "canvas_item", it is possible to override ``vertex``, ``fragment``, and ``light``.
|
||||
For "particles", only ``vertex`` can be overridden.
|
||||
|
||||
Vertex Processor
|
||||
Vertex processor
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
The ``vertex`` processing function is called once for every vertex in "spatial" and "canvas_item" shaders.
|
||||
@@ -83,7 +83,7 @@ By default Godot will take your vertex information and transform it accordingly
|
||||
undesirable, you can use render modes to to transform the data yourself, see the
|
||||
:ref:`Spatial shader doc <doc_spatial_shader>` for an example of this.
|
||||
|
||||
Fragment Processor
|
||||
Fragment processor
|
||||
^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The ``fragment`` processing function is used to set up the Godot material parameters per pixel. This code
|
||||
@@ -99,7 +99,7 @@ if you do not write a value to ``RIM``, Godot will not calculate rim lighting. D
|
||||
to see if ``RIM`` is used, if not it cuts all the corresponding code out. Therefore, you will not
|
||||
waste calculations on effects that you do not use.
|
||||
|
||||
Light Processor
|
||||
Light processor
|
||||
^^^^^^^^^^^^^^^
|
||||
|
||||
The ``light`` processor runs per pixel too, but also runs for every light that affects the object
|
||||
|
||||
@@ -175,8 +175,8 @@ Keep in mind that some architectures (mainly mobile) benefit a lot from this, bu
|
||||
to find out more. In all honesty though, mobile drivers are buggy so to stay out of trouble make simple
|
||||
shaders without specifying precision unless you *really* need to.
|
||||
|
||||
Operators:
|
||||
----------
|
||||
Operators
|
||||
---------
|
||||
|
||||
Godot shading language supports the same set of operators as GLSL ES 3.0. Below is the list of them in precedence order:
|
||||
|
||||
@@ -208,7 +208,7 @@ Godot shading language supports the same set of operators as GLSL ES 3.0. Below
|
||||
| 12 (lowest) | logical inclusive or | **||** |
|
||||
+-------------+-----------------------+--------------------+
|
||||
|
||||
Flow Control
|
||||
Flow control
|
||||
------------
|
||||
|
||||
Godot Shading language supports the most common types of flow control:
|
||||
@@ -237,7 +237,7 @@ Keep in mind that, in modern GPUs, an infinite loop can exist and can freeze you
|
||||
Godot can't protect you from this, so be careful to not make this mistake!
|
||||
|
||||
Discarding
|
||||
-----------
|
||||
----------
|
||||
|
||||
Fragment and light functions can use the **discard** keyword. If used, the fragment is discarded and nothing is written.
|
||||
|
||||
@@ -421,7 +421,7 @@ Uniforms can also be assigned default values:
|
||||
uniform vec4 some_vector = vec4(0.0);
|
||||
uniform vec4 some_color : hint_color = vec4(1.0);
|
||||
|
||||
Built-in Functions
|
||||
Built-in functions
|
||||
------------------
|
||||
|
||||
A large number of built-in functions are supported, conforming mostly to GLSL ES 3.0.
|
||||
@@ -606,4 +606,3 @@ When vec_type (float), vec_int_type, vec_uint_type, vec_bool_type nomenclature i
|
||||
+-----------------------------------------------------------------------------------------------+------------------------------------------------+
|
||||
| vec_type **fwidth** ( vec_type ) | Sum of absolute derivative in x and y |
|
||||
+-----------------------------------------------------------------------------------------------+------------------------------------------------+
|
||||
|
||||
|
||||
@@ -1,18 +1,18 @@
|
||||
.. _doc_spatial_shader:
|
||||
|
||||
Spatial shaders
|
||||
================
|
||||
===============
|
||||
|
||||
Spatial shaders are used for shading 3D objects. They are the most complex type of shader Godot offers.
|
||||
Spatial shaders are highly configurable with different render modes and different rendering options
|
||||
(e.g. Subsurface Scattering, Transmission, Ambient Occlusion, Rim lighting etc). Users can optionally
|
||||
write vertex, fragment, and light processor functions to affect how objects are drawn.
|
||||
|
||||
Render Modes
|
||||
Render modes
|
||||
^^^^^^^^^^^^
|
||||
|
||||
+---------------------------------+-----------------------------------------------------------------------+
|
||||
| Render Mode | Description |
|
||||
| Render mode | Description |
|
||||
+=================================+=======================================================================+
|
||||
| **blend_mix** | Mix blend mode (alpha is transparency), default. |
|
||||
+---------------------------------+-----------------------------------------------------------------------+
|
||||
@@ -67,7 +67,7 @@ Render Modes
|
||||
| **vertex_lighting** | Use vertex-based lighting. |
|
||||
+---------------------------------+-----------------------------------------------------------------------+
|
||||
|
||||
Vertex Built-Ins
|
||||
Vertex built-ins
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
Values marked as "in" are read-only. Values marked as "out" are for optional writing and will
|
||||
@@ -109,7 +109,7 @@ This allows you to easily adjust the shader to a particle system using default p
|
||||
shader, this value can be used as desired.
|
||||
|
||||
+------------------------------------+-------------------------------------------------------+
|
||||
| Built-In | Description |
|
||||
| Built-in | Description |
|
||||
+====================================+=======================================================+
|
||||
| out mat4 **WORLD_MATRIX** | Model space to world space transform. |
|
||||
+------------------------------------+-------------------------------------------------------+
|
||||
@@ -150,7 +150,7 @@ shader, this value can be used as desired.
|
||||
| out float **ROUGHNESS** | Roughness for vertex lighting. |
|
||||
+------------------------------------+-------------------------------------------------------+
|
||||
|
||||
Fragment Built-Ins
|
||||
Fragment built-ins
|
||||
^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The default use of a Godot fragment processor function is to set up the material properties of your object
|
||||
@@ -158,7 +158,7 @@ and to let the built-in renderer handle the final shading. However, you are not
|
||||
these properties, and if you don't write to them, Godot will optimize away the corresponding functionality.
|
||||
|
||||
+-----------------------------------+--------------------------------------------------------------------------------------------------+
|
||||
| Built-In | Description |
|
||||
| Built-in | Description |
|
||||
+===================================+==================================================================================================+
|
||||
| in vec4 **FRAGCOORD** | Fragment coordinate, pixel adjusted. In screen space. |
|
||||
+-----------------------------------+--------------------------------------------------------------------------------------------------+
|
||||
@@ -239,7 +239,7 @@ these properties, and if you don't write to them, Godot will optimize away the c
|
||||
| out float **ALPHA_SCISSOR** | If written to, values below a certain amount of alpha are discarded. |
|
||||
+-----------------------------------+--------------------------------------------------------------------------------------------------+
|
||||
|
||||
Light Built-Ins
|
||||
Light built-ins
|
||||
^^^^^^^^^^^^^^^
|
||||
|
||||
Writing light processor functions is completely optional. You can skip the light function by setting
|
||||
|
||||
Reference in New Issue
Block a user