compositor.rst 14 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373
  1. .. _doc_compositor:
  2. The Compositor
  3. ==============
  4. The compositor is a new feature in Godot 4 that allows control over
  5. the rendering pipeline when rendering the contents of a :ref:`Viewport <class_Viewport>`.
  6. It can be configured on a :ref:`WorldEnvironment <class_WorldEnvironment>`
  7. node where it applies to all Viewports, or it can be configured on
  8. a :ref:`Camera3D <class_Camera3D>` and apply only to
  9. the Viewport using that camera.
  10. The :ref:`Compositor <class_Compositor>` resource is used to configure
  11. the compositor. To get started, create a new compositor on the appropriate node:
  12. .. image:: img/new_compositor.webp
  13. .. note::
  14. The compositor is currently a feature that is only supported by
  15. the Mobile and Forward+ renderers.
  16. Compositor effects
  17. ------------------
  18. Compositor effects allow you to insert additional logic into the rendering
  19. pipeline at various stages. This is an advanced feature that requires
  20. a high level of understanding of the rendering pipeline to use to
  21. its best advantage.
  22. As the core logic of the compositor effect is called from the rendering
  23. pipeline it is important to note that this logic will thus run within
  24. the thread on which rendering takes place.
  25. Care needs to be taken to ensure we don't run into threading issues.
  26. To illustrate how to use compositor effects we'll create a simple
  27. post processing effect that allows you to write your own shader code
  28. and apply this full screen through a compute shader.
  29. You can find the finished demo project `here <https://github.com/godotengine/godot-demo-projects/tree/master/compute/post_shader>`_.
  30. We start by creating a new script called ``post_process_shader.gd``.
  31. We'll make this a tool script so we can see the compositor effect work in the editor.
  32. We need to extend our node from :ref:`CompositorEffect <class_CompositorEffect>`.
  33. We must also give our script a class name.
  34. .. code-block:: gdscript
  35. :caption: post_process_shader.gd
  36. @tool
  37. extends CompositorEffect
  38. class_name PostProcessShader
  39. Next we're going to define a constant for our shader template code.
  40. This is the boilerplate code that makes our compute shader work.
  41. .. code-block:: gdscript
  42. const template_shader : String = "#version 450
  43. // Invocations in the (x, y, z) dimension
  44. layout(local_size_x = 8, local_size_y = 8, local_size_z = 1) in;
  45. layout(rgba16f, set = 0, binding = 0) uniform image2D color_image;
  46. // Our push constant
  47. layout(push_constant, std430) uniform Params {
  48. vec2 raster_size;
  49. vec2 reserved;
  50. } params;
  51. // The code we want to execute in each invocation
  52. void main() {
  53. ivec2 uv = ivec2(gl_GlobalInvocationID.xy);
  54. ivec2 size = ivec2(params.raster_size);
  55. if (uv.x >= size.x || uv.y >= size.y) {
  56. return;
  57. }
  58. vec4 color = imageLoad(color_image, uv);
  59. #COMPUTE_CODE
  60. imageStore(color_image, uv, color);
  61. }"
  62. For more information on how compute shaders work,
  63. please check :ref:`Using compute shaders <doc_compute_shaders>`.
  64. The important bit here is that for every pixel on our screen,
  65. our ``main`` function is executed and inside of this we load
  66. the current color value of our pixel, execute our user code,
  67. and write our modified color back to our color image.
  68. ``#COMPUTE_CODE`` gets replaced by our user code.
  69. In order to set our user code, we need an export variable.
  70. We'll also define a few script variables we'll be using:
  71. .. code-block:: gdscript
  72. @export_multiline var shader_code : String = "":
  73. set(value):
  74. mutex.lock()
  75. shader_code = value
  76. shader_is_dirty = true
  77. mutex.unlock()
  78. var rd : RenderingDevice
  79. var shader : RID
  80. var pipeline : RID
  81. var mutex : Mutex = Mutex.new()
  82. var shader_is_dirty : bool = true
  83. Note the use of a :ref:`Mutex <class_Mutex>` in our code.
  84. Most of our implementation gets called from the rendering engine
  85. and thus runs within our rendering thread.
  86. We need to ensure that we set our new shader code, and mark our
  87. shader code as dirty, without our render thread accessing this
  88. data at the same time.
  89. Next we initialize our effect.
  90. .. code-block:: gdscript
  91. # Called when this resource is constructed.
  92. func _init():
  93. effect_callback_type = EFFECT_CALLBACK_TYPE_POST_TRANSPARENT
  94. rd = RenderingServer.get_rendering_device()
  95. The main thing here is setting our ``effect_callback_type`` which tells
  96. the rendering engine at what stage of the render pipeline to call our code.
  97. .. note::
  98. Currently we only have access to the stages of the 3D rendering pipeline!
  99. We also get a reference to our rendering device, which will come in very handy.
  100. We also need to clean up after ourselves, for this we react to the
  101. ``NOTIFICATION_PREDELETE`` notification:
  102. .. code-block:: gdscript
  103. # System notifications, we want to react on the notification that
  104. # alerts us we are about to be destroyed.
  105. func _notification(what):
  106. if what == NOTIFICATION_PREDELETE:
  107. if shader.is_valid():
  108. # Freeing our shader will also free any dependents such as the pipeline!
  109. rd.free_rid(shader)
  110. Note that we do not use our mutex here even though we create our shader inside
  111. of our render thread.
  112. The methods on our rendering server are thread safe and ``free_rid`` will
  113. be postponed cleaning up the shader until after any frames currently being
  114. rendered are finished.
  115. Also note that we are not freeing our pipeline. The rendering device does
  116. dependency tracking and as the pipeline is dependent on the shader, it will
  117. be automatically freed when the shader is destructed.
  118. From this point onwards our code will run on the rendering thread.
  119. Our next step is a helper function that will recompile the shader if the user
  120. code was changed.
  121. .. code-block:: gdscript
  122. # Check if our shader has changed and needs to be recompiled.
  123. func _check_shader() -> bool:
  124. if not rd:
  125. return false
  126. var new_shader_code : String = ""
  127. # Check if our shader is dirty.
  128. mutex.lock()
  129. if shader_is_dirty:
  130. new_shader_code = shader_code
  131. shader_is_dirty = false
  132. mutex.unlock()
  133. # We don't have a (new) shader?
  134. if new_shader_code.is_empty():
  135. return pipeline.is_valid()
  136. # Apply template.
  137. new_shader_code = template_shader.replace("#COMPUTE_CODE", new_shader_code);
  138. # Out with the old.
  139. if shader.is_valid():
  140. rd.free_rid(shader)
  141. shader = RID()
  142. pipeline = RID()
  143. # In with the new.
  144. var shader_source : RDShaderSource = RDShaderSource.new()
  145. shader_source.language = RenderingDevice.SHADER_LANGUAGE_GLSL
  146. shader_source.source_compute = new_shader_code
  147. var shader_spirv : RDShaderSPIRV = rd.shader_compile_spirv_from_source(shader_source)
  148. if shader_spirv.compile_error_compute != "":
  149. push_error(shader_spirv.compile_error_compute)
  150. push_error("In: " + new_shader_code)
  151. return false
  152. shader = rd.shader_create_from_spirv(shader_spirv)
  153. if not shader.is_valid():
  154. return false
  155. pipeline = rd.compute_pipeline_create(shader)
  156. return pipeline.is_valid()
  157. At the top of this method we again use our mutex to protect accessing our
  158. user shader code and our is dirty flag.
  159. We make a local copy of the user shader code if our user shader code is dirty.
  160. If we don't have a new code fragment, we return true if we already have a
  161. valid pipeline.
  162. If we do have a new code fragment we embed it in our template code and then
  163. compile it.
  164. .. warning::
  165. The code shown here compiles our new code in runtime.
  166. This is great for prototyping as we can immediately see the effect
  167. of the changed shader.
  168. This prevents precompiling and caching this shader which may be an issues
  169. on some platforms such as consoles.
  170. Note that the demo project comes with an alternative example where
  171. a ``glsl`` file contains the entire compute shader and this is used.
  172. Godot is able to precompile and cache the shader with this approach.
  173. Finally we need to implement our effect callback, the rendering engine will call
  174. this at the right stage of rendering.
  175. .. code-block:: gdscript
  176. # Called by the rendering thread every frame.
  177. func _render_callback(p_effect_callback_type, p_render_data):
  178. if rd and p_effect_callback_type == EFFECT_CALLBACK_TYPE_POST_TRANSPARENT and _check_shader():
  179. # Get our render scene buffers object, this gives us access to our render buffers.
  180. # Note that implementation differs per renderer hence the need for the cast.
  181. var render_scene_buffers : RenderSceneBuffersRD = p_render_data.get_render_scene_buffers()
  182. if render_scene_buffers:
  183. # Get our render size, this is the 3D render resolution!
  184. var size = render_scene_buffers.get_internal_size()
  185. if size.x == 0 and size.y == 0:
  186. return
  187. # We can use a compute shader here
  188. var x_groups = (size.x - 1) / 8 + 1
  189. var y_groups = (size.y - 1) / 8 + 1
  190. var z_groups = 1
  191. # Push constant
  192. var push_constant : PackedFloat32Array = PackedFloat32Array()
  193. push_constant.push_back(size.x)
  194. push_constant.push_back(size.y)
  195. push_constant.push_back(0.0)
  196. push_constant.push_back(0.0)
  197. # Loop through views just in case we're doing stereo rendering. No extra cost if this is mono.
  198. var view_count = render_scene_buffers.get_view_count()
  199. for view in range(view_count):
  200. # Get the RID for our color image, we will be reading from and writing to it.
  201. var input_image = render_scene_buffers.get_color_layer(view)
  202. # Create a uniform set, this will be cached, the cache will be cleared if our viewports configuration is changed.
  203. var uniform : RDUniform = RDUniform.new()
  204. uniform.uniform_type = RenderingDevice.UNIFORM_TYPE_IMAGE
  205. uniform.binding = 0
  206. uniform.add_id(input_image)
  207. var uniform_set = UniformSetCacheRD.get_cache(shader, 0, [ uniform ])
  208. # Run our compute shader.
  209. var compute_list := rd.compute_list_begin()
  210. rd.compute_list_bind_compute_pipeline(compute_list, pipeline)
  211. rd.compute_list_bind_uniform_set(compute_list, uniform_set, 0)
  212. rd.compute_list_set_push_constant(compute_list, push_constant.to_byte_array(), push_constant.size() * 4)
  213. rd.compute_list_dispatch(compute_list, x_groups, y_groups, z_groups)
  214. rd.compute_list_end()
  215. At the start of this method we check if we have a rendering device,
  216. if our callback type is the correct one, and check if we have our shader.
  217. .. note::
  218. The check for the effect type is only a safety mechanism.
  219. We've set this in our ``_init`` function, however it is possible
  220. for the user to change this in the UI.
  221. Our ``p_render_data`` parameter gives us access to an object that holds
  222. data specific to the frame we're currently rendering. We're currently only
  223. interested in our render scene buffers, which provide us access to all the
  224. internal buffers used by the rendering engine.
  225. Note that we cast this to :ref:`RenderSceneBuffersRD <class_RenderSceneBuffersRD>`
  226. to expose the full API to this data.
  227. Next we obtain our ``internal size`` which is the resolution of our 3D render
  228. buffers before they are upscaled (if applicable), upscaling happens after our
  229. post processes have run.
  230. From our internal size we calculate our group size, see our local size in our
  231. template shader.
  232. .. UPDATE: Not supported yet. When structs are supported here, update this
  233. .. paragraph.
  234. We also populate our push constant so our shader knows our size.
  235. Godot does not support structs here **yet** so we use a
  236. ``PackedFloat32Array`` to store this data into. Note that we have
  237. to pad this array with a 16 byte alignment. In other words, the
  238. length of our array needs to be a multiple of 4.
  239. Now we loop through our views, this is in case we're using multiview rendering
  240. which is applicable for stereo rendering (XR). In most cases we will only have
  241. one view.
  242. .. note::
  243. There is no performance benefit to use multiview for post processing
  244. here, handling the views separately like this will still enable the GPU
  245. to use parallelism if beneficial.
  246. Next we obtain the color buffer for this view. This is the buffer into which
  247. our 3D scene has been rendered.
  248. We then prepare a uniform set so we can communicate the color buffer to our
  249. shader.
  250. Note the use of our :ref:`UniformSetCacheRD <class_UniformSetCacheRD>` cache
  251. which ensures we can check for our uniform set each frame.
  252. As our color buffer can change from frame to frame and our uniform cache
  253. will automatically clean up uniform sets when buffers are freed, this is
  254. the safe way to ensure we do not leak memory or use an outdated set.
  255. Finally we build our compute list by binding our pipeline,
  256. binding our uniform set, pushing our push constant data,
  257. and calling dispatch for our groups.
  258. With our compositor effect completed, we now need to add it to our compositor.
  259. On our compositor we expand the compositor effects property
  260. and press ``Add Element``.
  261. Now we can add our compositor effect:
  262. .. image:: img/add_compositor_effect.webp
  263. After selecting our ``PostProcessShader`` we need to set our user shader code:
  264. .. code-block:: glsl
  265. float gray = color.r * 0.2125 + color.g * 0.7154 + color.b * 0.0721;
  266. color.rgb = vec3(gray);
  267. With that all done, our output is in grayscale.
  268. .. image:: img/post_process_shader.webp
  269. .. note::
  270. For a more advanced example of post effects, check out the
  271. `Radial blur based sky rays <https://github.com/BastiaanOlij/RERadialSunRays>`_
  272. example project created by Bastiaan Olij.