introduction_to_shaders.rst 7.4 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185
  1. .. _doc_introduction_to_shaders:
  2. Introduction to shaders
  3. =======================
  4. This page explains what shaders are and will give you an overview of how they
  5. work in Godot. For a detailed reference of the engine's shading language, see
  6. :ref:`doc_shading_language`.
  7. Shaders are a special kind of program that runs on Graphics Processing Units
  8. (GPUs). They were initially used to shade 3D scenes but can nowadays do much
  9. more. You can use them to control how the engine draws geometry and pixels on
  10. the screen, allowing you to achieve all sorts of effects.
  11. Modern rendering engines like Godot draw everything with shaders: graphics cards
  12. can run thousands of instructions in parallel, leading to incredible rendering
  13. speed.
  14. Because of their parallel nature, though, shaders don't process information the
  15. way a typical program does. Shader code runs on each vertex or pixel in
  16. isolation. You cannot store data between frames either. As a result, when
  17. working with shaders, you need to code and think differently from other
  18. programming languages.
  19. Suppose you want to update all the pixels in a texture to a given color. In
  20. GDScript, your code would use ``for`` loops::
  21. for x in range(width):
  22. for y in range(height):
  23. set_color(x, y, some_color)
  24. Your code is already part of a loop in a shader, so the corresponding code would
  25. look like this.
  26. .. code-block:: glsl
  27. void fragment() {
  28. COLOR = some_color;
  29. }
  30. .. note::
  31. The graphics card calls the ``fragment()`` function once or more for each
  32. pixel it has to draw. More on that below.
  33. Shaders in Godot
  34. ----------------
  35. Godot provides a shading language based on the popular OpenGL Shading Language
  36. (GLSL) but simplified. The engine handles some of the lower-level initialization
  37. work for you, making it easier to write complex shaders.
  38. In Godot, shaders are made up of main functions called "processor functions".
  39. Processor functions are the entry point for your shader into the program. There
  40. are seven different processor functions.
  41. 1. The ``vertex()`` function runs over all the vertices in the mesh and sets
  42. their positions and some other per-vertex variables. Used in
  43. :ref:`canvas_item shaders <doc_canvas_item_shader>` and
  44. :ref:`spatial shaders <doc_spatial_shader>`.
  45. 2. The ``fragment()`` function runs for every pixel covered by the mesh. It uses
  46. values output by the ``vertex()`` function, interpolated between the
  47. vertices. Used in :ref:`canvas_item shaders <doc_canvas_item_shader>` and
  48. :ref:`spatial shaders <doc_spatial_shader>`.
  49. 3. The ``light()`` function runs for every pixel and for every light. It takes
  50. variables from the ``fragment()`` function and from its previous runs. Used
  51. in :ref:`canvas_item shaders <doc_canvas_item_shader>` and
  52. :ref:`spatial shaders <doc_spatial_shader>`.
  53. 4. The ``start()`` function runs for every particle in a particle system once
  54. when the particle is first spawned. Used in
  55. :ref:`particles shaders <doc_particle_shader>`.
  56. 5. The ``process()`` function runs for every particle in a particle system for
  57. each frame. Used in :ref:`particles shaders <doc_particle_shader>`.
  58. 6. The ``sky()`` function runs for every pixel in the radiance cubemap when the
  59. radiance cubemap needs to be updated, and for every pixel on the current
  60. screen. Used in :ref:`sky shaders <doc_sky_shader>`.
  61. 7. The ``fog()`` function runs for every froxel in the volumetric fog froxel
  62. buffer that intersects with the :ref:`FogVolume <class_FogVolume>`. Used by
  63. :ref:`fog shaders <doc_fog_shader>`.
  64. .. warning::
  65. The ``light()`` function won't run if the ``vertex_lighting`` render mode is
  66. enabled, or if **Rendering > Quality > Shading > Force Vertex Shading** is
  67. enabled in the Project Settings. It's enabled by default on mobile
  68. platforms.
  69. .. note::
  70. Godot also exposes an API for users to write totally custom GLSL shaders. For
  71. more information see :ref:`doc_compute_shaders`.
  72. Shader types
  73. ------------
  74. Instead of supplying a general-purpose configuration for all uses (2D, 3D,
  75. particles, sky, fog), you must specify the type of shader you're writing.
  76. Different types support different render modes, built-in variables, and
  77. processing functions.
  78. In Godot, all shaders need to specify their type in the first line, like so:
  79. .. code-block:: glsl
  80. shader_type spatial;
  81. Here are the available types:
  82. * :ref:`spatial <doc_spatial_shader>` for 3D rendering.
  83. * :ref:`canvas_item <doc_canvas_item_shader>` for 2D rendering.
  84. * :ref:`particles <doc_particle_shader>` for particle systems.
  85. * :ref:`sky <doc_sky_shader>` to render :ref:`Skies <class_Sky>`.
  86. * :ref:`fog <doc_fog_shader>` to render :ref:`FogVolumes <class_FogVolume>`
  87. Render modes
  88. ------------
  89. Shaders have optional render modes you can specify on the second line, after the
  90. shader type, like so:
  91. .. code-block:: glsl
  92. shader_type spatial;
  93. render_mode unshaded, cull_disabled;
  94. Render modes alter the way Godot applies the shader. For example, the
  95. ``unshaded`` mode makes the engine skip the built-in light processor function.
  96. Each shader type has different render modes. See the reference for each shader
  97. type for a complete list of render modes.
  98. Vertex processor
  99. ^^^^^^^^^^^^^^^^
  100. The ``vertex()`` processing function is called once for every vertex in
  101. ``spatial`` and ``canvas_item`` shaders. For ``particles`` shaders, it is called
  102. once for every particle.
  103. Each vertex in your world's geometry has properties like a position and color.
  104. The function modifies those values and passes them to the fragment function. You
  105. can also use it to send extra data to the fragment function using varyings.
  106. By default, Godot transforms your vertex information for you, which is necessary
  107. to project geometry onto the screen. You can use render modes to transform the
  108. data yourself; see the :ref:`Spatial shader doc <doc_spatial_shader>` for an
  109. example.
  110. Fragment processor
  111. ^^^^^^^^^^^^^^^^^^
  112. The ``fragment()`` processing function is used to set up the Godot material
  113. parameters per pixel. This code runs on every visible pixel the object or
  114. primitive draws. It is only available in ``spatial``, ``canvas_item``, and ``sky`` shaders.
  115. The standard use of the fragment function is to set up material properties used
  116. to calculate lighting. For example, you would set values for ``ROUGHNESS``,
  117. ``RIM``, or ``TRANSMISSION``, which would tell the light function how the lights
  118. respond to that fragment. This makes it possible to control a complex shading
  119. pipeline without the user having to write much code. If you don't need this
  120. built-in functionality, you can ignore it and write your own light processing
  121. function, and Godot will optimize it away. For example, if you do not write a
  122. value to ``RIM``, Godot will not calculate rim lighting. During compilation,
  123. Godot checks to see if ``RIM`` is used; if not, it cuts all the corresponding
  124. code out. Therefore, you will not waste calculations on the effects that you do
  125. not use.
  126. Light processor
  127. ^^^^^^^^^^^^^^^
  128. The ``light()`` processor runs per pixel too, and it runs once for every light
  129. that affects the object. It does not run if no lights affect the object. It
  130. exists as a function called inside the ``fragment()`` processor and typically
  131. operates on the material properties setup inside the ``fragment()`` function.
  132. The ``light()`` processor works differently in 2D than it does in 3D; for a
  133. description of how it works in each, see their documentation, :ref:`CanvasItem
  134. shaders <doc_canvas_item_shader>` and :ref:`Spatial shaders
  135. <doc_spatial_shader>`, respectively.