viewports.rst 13 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286
  1. .. _doc_viewports:
  2. Using Viewports
  3. ===============
  4. Introduction
  5. ------------
  6. Think of a :ref:`Viewport <class_Viewport>` as a screen onto which the game is projected. In order
  7. to see the game, we need to have a surface on which to draw it. That surface is
  8. the Root Viewport.
  9. .. image:: img/subviewportnode.webp
  10. :ref:`SubViewports <class_SubViewport>` are a kind of Viewport that can be added to the scene so that there
  11. are multiple surfaces to draw on. When we are drawing to a SubViewport, we call it a render target. We can access the contents
  12. of a render target by accessing its corresponding :ref:`texture <class_Viewport_method_get_texture>`.
  13. By using a SubViewport as render target, we can either render multiple scenes simultaneously or we can render to
  14. a :ref:`ViewportTexture <class_ViewportTexture>` which is applied to an object in the scene, for example a dynamic
  15. skybox.
  16. :ref:`SubViewports <class_SubViewport>` have a variety of use cases, including:
  17. - Rendering 3D objects within a 2D game
  18. - Rendering 2D elements in a 3D game
  19. - Rendering dynamic textures
  20. - Generating procedural textures at runtime
  21. - Rendering multiple cameras in the same scene
  22. What all these use cases have in common is that you are given the ability to
  23. draw objects to a texture as if it were another screen and can then choose
  24. what to do with the resulting texture.
  25. Another kind of Viewports in Godot are :ref:`Windows <class_Window>`. They allow their content to be projected onto a window. While the Root Viewport is a Window, they are less
  26. flexible. If you want to use the texture of a Viewport, you'll be working with :ref:`SubViewports <class_SubViewport>` most of the time.
  27. Input
  28. -----
  29. :ref:`Viewports <class_Viewport>` are also responsible for delivering properly adjusted and
  30. scaled input events to their children nodes. By default :ref:`SubViewports <class_SubViewport>` don't
  31. automatically receive input, unless they receive it from their direct
  32. :ref:`SubViewportContainer <class_SubViewportContainer>` parent node. In this case, input can be
  33. disabled with the :ref:`Disable Input <class_Viewport_property_gui_disable_input>` property.
  34. .. image:: img/input.webp
  35. For more information on how Godot handles input, please read the :ref:`Input Event Tutorial <doc_inputevent>`.
  36. Listener
  37. --------
  38. Godot supports 3D sound (in both 2D and 3D nodes). More on this can be
  39. found in the :ref:`Audio Streams Tutorial <doc_audio_streams>`. For this type of sound to be
  40. audible, the :ref:`Viewport <class_Viewport>` needs to be enabled as a listener (for 2D or 3D).
  41. If you are using a :ref:`SubViewport <class_SubViewport>` to display your :ref:`World3D <class_World3D>` or
  42. :ref:`World2D <class_World2D>`, don't forget to enable this!
  43. Cameras (2D & 3D)
  44. -----------------
  45. When using a :ref:`Camera3D <class_Camera3D>` or
  46. :ref:`Camera2D <class_Camera2D>`, it will always display on the
  47. closest parent :ref:`Viewport <class_Viewport>` (going towards the root). For example, in the
  48. following hierarchy:
  49. .. image:: img/cameras.webp
  50. ``CameraA`` will display on the Root :ref:`Viewport <class_Viewport>` and it will draw ``MeshA``. ``CameraB``
  51. will be captured by the :ref:`SubViewport <class_SubViewport>` along with ``MeshB``. Even though ``MeshB`` is in the scene
  52. hierarchy, it will still not be drawn to the Root Viewport. Similarly, ``MeshA`` will not
  53. be visible from the SubViewport because SubViewports only
  54. capture nodes below them in the hierarchy.
  55. There can only be one active camera per :ref:`Viewport <class_Viewport>`, so if there is more
  56. than one, make sure that the desired one has the :ref:`current <class_Camera3D_property_current>` property set,
  57. or make it the current camera by calling:
  58. .. tabs::
  59. .. code-tab:: gdscript GDScript
  60. camera.make_current()
  61. .. code-tab:: csharp
  62. camera.MakeCurrent();
  63. By default, cameras will render all objects in their world. In 3D, cameras can use their
  64. :ref:`cull_mask <class_Camera3D_property_cull_mask>` property combined with the
  65. :ref:`VisualInstance3D's <class_VisualInstance3D>` :ref:`layer <class_VisualInstance3D_property_layers>`
  66. property to restrict which objects are rendered.
  67. Scale & stretching
  68. ------------------
  69. :ref:`SubViewports <class_SubViewport>` have a :ref:`size<class_SubViewport_property_size>` property, which represents the size of the SubViewport
  70. in pixels. For SubViewports which are children of :ref:`SubViewportContainers <class_SubViewportContainer>`,
  71. these values are overridden, but for all others, this sets their resolution.
  72. It is also possible to scale the 2D content and make the :ref:`SubViewport <class_SubViewport>` resolution
  73. different from the one specified in size, by calling:
  74. .. tabs::
  75. .. code-tab:: gdscript GDScript
  76. sub_viewport.set_size_2d_override(Vector2i(width, height)) # Custom size for 2D.
  77. sub_viewport.set_size_2d_override_stretch(true) # Enable stretch for custom size.
  78. .. code-tab:: csharp
  79. subViewport.Size2DOverride = new Vector2I(width, height); // Custom size for 2D.
  80. subViewport.Size2DOverrideStretch = true; // Enable stretch for custom size.
  81. For information on scaling and stretching with the Root Viewport visit the :ref:`Multiple Resolutions Tutorial <doc_multiple_resolutions>`
  82. Worlds
  83. ------
  84. For 3D, a :ref:`Viewport <class_Viewport>` will contain a :ref:`World3D <class_World3D>`. This
  85. is basically the universe that links physics and rendering together.
  86. Node3D-based nodes will register using the World3D of the closest Viewport.
  87. By default, newly created Viewports do not contain a World3D but
  88. use the same as their parent Viewport. The Root Viewport always contains a
  89. World3D, which is the one objects are rendered to by default.
  90. A :ref:`World3D <class_World3D>` can
  91. be set in a :ref:`Viewport <class_Viewport>` using the :ref:`World 3D<class_Viewport_property_world_3d>` property, that will separate
  92. all children nodes of this :ref:`Viewport <class_Viewport>` and will prevent them from interacting with the parent
  93. Viewport's World3D. This is especially useful in scenarios where, for
  94. example, you might want to show a separate character in 3D imposed over
  95. the game (like in StarCraft).
  96. As a helper for situations where you want to create :ref:`Viewports <class_Viewport>` that
  97. display single objects and don't want to create a :ref:`World3D <class_World3D>`, Viewport has
  98. the option to use its :ref:`Own World3D <class_Viewport_property_own_world_3d>`. This is useful when you want to
  99. instance 3D characters or objects in :ref:`World2D <class_World2D>`.
  100. For 2D, each :ref:`Viewport <class_Viewport>` always contains its own :ref:`World2D <class_World2D>`.
  101. This suffices in most cases, but in case sharing them may be desired, it
  102. is possible to do so by setting :ref:`world_2d<class_Viewport_property_world_2d>` on the Viewport through code.
  103. For an example of how this works, see the demo projects `3D in 2D <https://github.com/godotengine/godot-demo-projects/tree/master/viewport/3d_in_2d>`_ and `2D in 3D <https://github.com/godotengine/godot-demo-projects/tree/master/viewport/2d_in_3d>`_ respectively.
  104. Capture
  105. -------
  106. It is possible to query a capture of the :ref:`Viewport <class_Viewport>` contents. For the Root
  107. Viewport, this is effectively a screen capture. This is done with the
  108. following code:
  109. .. tabs::
  110. .. code-tab:: gdscript GDScript
  111. # Retrieve the captured Image using get_image().
  112. var img = get_viewport().get_texture().get_image()
  113. # Convert Image to ImageTexture.
  114. var tex = ImageTexture.create_from_image(img)
  115. # Set sprite texture.
  116. sprite.texture = tex
  117. .. code-tab:: csharp
  118. // Retrieve the captured Image using get_image().
  119. var img = GetViewport().GetTexture().GetImage();
  120. // Convert Image to ImageTexture.
  121. var tex = ImageTexture.CreateFromImage(img);
  122. // Set sprite texture.
  123. sprite.Texture = tex;
  124. But if you use this in ``_ready()`` or from the first frame of the :ref:`Viewport's <class_Viewport>` initialization,
  125. you will get an empty texture because there is nothing to get as texture. You can deal with
  126. it using (for example):
  127. .. tabs::
  128. .. code-tab:: gdscript GDScript
  129. # Wait until the frame has finished before getting the texture.
  130. await RenderingServer.frame_post_draw
  131. # You can get the image after this.
  132. .. code-tab:: csharp
  133. // Wait until the frame has finished before getting the texture.
  134. await RenderingServer.Singleton.ToSignal(RenderingServer.SignalName.FramePostDraw);
  135. // You can get the image after this.
  136. Viewport Container
  137. ------------------
  138. If the :ref:`SubViewport <class_SubViewport>` is a child of a :ref:`SubViewportContainer <class_SubViewportContainer>`, it will become active and display anything it has inside. The layout looks like this:
  139. .. image:: img/container.webp
  140. The :ref:`SubViewport <class_SubViewport>` will cover the area of its parent :ref:`SubViewportContainer <class_SubViewportContainer>` completely
  141. if :ref:`Stretch<class_SubViewportContainer_property_stretch>` is set to ``true`` in the SubViewportContainer.
  142. .. note::
  143. The size of the :ref:`SubViewportContainer <class_SubViewportContainer>` cannot be smaller than the size of the :ref:`SubViewport <class_SubViewport>`.
  144. Rendering
  145. ---------
  146. Due to the fact that the :ref:`Viewport <class_Viewport>` is an entryway into another rendering surface, it exposes a few
  147. rendering properties that can be different from the project settings. You can
  148. choose to use a different level of :ref:`MSAA <class_Viewport_property_msaa_2d>` for each Viewport. The default behavior is ``Disabled``.
  149. If you know that the :ref:`Viewport <class_Viewport>` is only going to be used for 2D, you can :ref:`Disable 3D<class_Viewport_property_disable_3d>`. Godot will then
  150. restrict how the Viewport is drawn.
  151. Disabling 3D is slightly faster and uses less memory compared to enabled 3D. It's a good idea to disable 3D if your viewport doesn't render anything in 3D.
  152. .. note::
  153. If you need to render 3D shadows in the viewport, make sure to set the viewport's :ref:`positional_shadow_atlas_size<class_Viewport_property_positional_shadow_atlas_size>` property to a value higher than ``0``.
  154. Otherwise, shadows won't be rendered. By default, the equivalent project setting is set to ``4096`` on desktop platforms and ``2048`` on mobile platforms.
  155. Godot also provides a way of customizing how everything is drawn inside :ref:`Viewports <class_Viewport>` using :ref:`Debug Draw<class_Viewport_property_debug_draw>`.
  156. Debug Draw allows you to specify a mode which determines how the Viewport will display things drawn
  157. inside it. Debug Draw is ``Disabled`` by default. Some other options are ``Unshaded``, ``Overdraw``, and ``Wireframe``. For a full list, refer to the :ref:`Viewport Documentation<class_Viewport_property_debug_draw>`.
  158. - **Debug Draw = Disabled** (default): The scene is drawn normally.
  159. .. image:: img/default_scene.webp
  160. - **Debug Draw = Unshaded**: Unshaded draws the scene without using lighting information so all the objects appear flatly colored in their albedo color.
  161. .. image:: img/unshaded.webp
  162. - **Debug Draw = Overdraw**: Overdraw draws the meshes semi-transparent with an additive blend so you can see how the meshes overlap.
  163. .. image:: img/overdraw.webp
  164. - **Debug Draw = Wireframe**: Wireframe draws the scene using only the edges of triangles in the meshes.
  165. .. image:: img/wireframe.webp
  166. .. note::
  167. Debug Draw modes are currently **not** supported when using the
  168. Compatibility rendering method. They will appear as regular draw modes.
  169. Render target
  170. -------------
  171. When rendering to a :ref:`SubViewport <class_SubViewport>`, whatever is inside will not be
  172. visible in the scene editor. To display the contents, you have to draw the SubViewport's :ref:`ViewportTexture <class_ViewportTexture>` somewhere.
  173. This can be requested via code using (for example):
  174. .. tabs::
  175. .. code-tab:: gdscript GDScript
  176. # This gives us the ViewportTexture.
  177. var tex = viewport.get_texture()
  178. sprite.texture = tex
  179. .. code-tab:: csharp
  180. // This gives us the ViewportTexture.
  181. var tex = viewport.GetTexture();
  182. sprite.Texture = tex;
  183. Or it can be assigned in the editor by selecting "New ViewportTexture"
  184. .. image:: img/texturemenu.webp
  185. and then selecting the :ref:`Viewport <class_Viewport>` you want to use.
  186. .. image:: img/texturepath.webp
  187. Every frame, the :ref:`Viewport's <class_Viewport>` texture is cleared away with the default clear color (or a transparent
  188. color if :ref:`Transparent BG<class_Viewport_property_transparent_bg>` is set to ``true``). This can be changed by setting :ref:`Clear Mode<class_SubViewport_property_render_target_clear_mode>` to ``Never`` or ``Next Frame``.
  189. As the name implies, Never means the texture will never be cleared, while next frame will
  190. clear the texture on the next frame and then set itself to Never.
  191. By default, re-rendering of the :ref:`SubViewport <class_SubViewport>` happens when
  192. its :ref:`ViewportTexture <class_ViewportTexture>` has been drawn in a frame. If visible, it will be
  193. rendered, otherwise, it will not. This behavior can be changed by setting :ref:`Update Mode<class_SubViewport_property_render_target_update_mode>` to ``Never``, ``Once``, ``Always``, or ``When Parent Visible``.
  194. Never and Always will never or always re-render respectively. Once will re-render the next frame and change to Never afterwards. This can be used to manually update the Viewport.
  195. This flexibility allows users to render an image once and then use the texture without incurring the cost of rendering every frame.
  196. .. note::
  197. Make sure to check the Viewport demos. They are available in the
  198. viewport folder of the demos archive, or at
  199. https://github.com/godotengine/godot-demo-projects/tree/master/viewport.