viewports.rst 12 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255
  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 :ref:`Viewport <class_Viewport>`.
  9. .. image:: img/viewportnode.png
  10. :ref:`Viewports <class_Viewport>` can also be added to the scene so that there
  11. are multiple surfaces to draw on. When we are drawing to a :ref:`Viewport <class_Viewport>`
  12. that is not the Root, we call it a render target. We can access the contents
  13. of a render target by accessing its corresponding :ref:`texture <class_ViewportTexture>`.
  14. By using a :ref:`Viewport <class_Viewport>` as a render target,
  15. we can either render multiple scenes simultaneously or we can render to
  16. a :ref:`texture <class_ViewportTexture>` which is applied to an object in the scene, for example a dynamic
  17. skybox.
  18. :ref:`Viewports <class_Viewport>` have a variety of use cases, including:
  19. - Rendering 3D objects within a 2D game
  20. - Rendering 2D elements in a 3D game
  21. - Rendering dynamic textures
  22. - Generating procedural textures at runtime
  23. - Rendering multiple cameras in the same scene
  24. What all these use cases have in common is that you are given the ability to
  25. draw objects to a texture as if it were another screen and can then choose
  26. what to do with the resulting texture.
  27. Input
  28. -----
  29. :ref:`Viewports <class_Viewport>` are also responsible for delivering properly adjusted and
  30. scaled input events to all their children nodes. Typically, input is received by the
  31. nearest :ref:`Viewport <class_Viewport>` in the tree, but you can set :ref:`Viewports <class_Viewport>` not to receive input by checking
  32. 'Disable Input' to 'on'; this will allow the next nearest :ref:`Viewport <class_Viewport>` in the tree to capture
  33. the input.
  34. .. image:: img/input.png
  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 custom :ref:`Viewport <class_Viewport>` to display your :ref:`World <class_World>`, don't forget
  42. to enable this!
  43. Cameras (2D & 3D)
  44. -----------------
  45. When using a :ref:`Camera <class_Camera>` /
  46. :ref:`Camera2D <class_Camera2D>`, cameras 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.png
  50. CameraA will display on the Root :ref:`Viewport <class_Viewport>` and it will draw MeshA. CameraB
  51. will be captured by the :ref:`Viewport <class_Viewport>` Node along with MeshB. Even though MeshB is in the scene
  52. hierarchy, it will still not be drawn to the Root :ref:`Viewport <class_Viewport>`. Similarly MeshA will not
  53. be visible from the :ref:`Viewport <class_Viewport>` node because :ref:`Viewport <class_Viewport>` nodes 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 "current" property set,
  57. or make it the current camera by calling:
  58. ::
  59. camera.make_current()
  60. By default, cameras will render all objects in their world. In 3D, cameras can use their
  61. :ref:`cull_mask <class_Camera_property_cull_mask>` property combined with the
  62. :ref:`VisualInstance's <class_VisualInstance>` :ref:`layer <class_VisualInstance_property_layers>`
  63. property to restrict which objects are rendered.
  64. Scale & stretching
  65. ------------------
  66. :ref:`Viewports <class_Viewport>` have a "size" property, which represents the size of the :ref:`Viewport <class_Viewport>`
  67. in pixels. For :ref:`Viewports <class_Viewport>` which are children of :ref:`ViewportContainers <class_viewportcontainer>`,
  68. these values are overridden, but for all others, this sets their resolution.
  69. It is also possible to scale the 2D content and make the :ref:`Viewport <class_Viewport>` resolution
  70. different from the one specified in size, by calling:
  71. ::
  72. viewport.set_size_override(true, Vector2(width, height)) # Custom size for 2D.
  73. viewport.set_size_override_stretch(true) # Enable stretch for custom size.
  74. The root :ref:`Viewport <class_Viewport>` uses this for the stretch options in the project
  75. settings. For more information on scaling and stretching visit the :ref:`Multiple Resolutions Tutorial <doc_multiple_resolutions>`
  76. Worlds
  77. ------
  78. For 3D, a :ref:`Viewport <class_Viewport>` will contain a :ref:`World <class_World>`. This
  79. is basically the universe that links physics and rendering together.
  80. Spatial-based nodes will register using the :ref:`World <class_World>` of the closest
  81. :ref:`Viewport <class_Viewport>`. By default, newly created :ref:`Viewports <class_Viewport>` do not contain a :ref:`World <class_World>` but
  82. use the same as their parent :ref:`Viewport <class_Viewport>` (the root :ref:`Viewport <class_Viewport>` always contains a
  83. :ref:`World <class_World>`, which is the one objects are rendered to by default). A :ref:`World <class_World>` can
  84. be set in a :ref:`Viewport <class_Viewport>` using the "world" property, and that will separate
  85. all children nodes of that :ref:`Viewport <class_Viewport>` from interacting with the parent
  86. :ref:`Viewport's <class_Viewport>` :ref:`World <class_World>`. This is especially useful in scenarios where, for
  87. example, you might want to show a separate character in 3D imposed over
  88. the game (like in StarCraft).
  89. As a helper for situations where you want to create :ref:`Viewports <class_Viewport>` that
  90. display single objects and don't want to create a :ref:`World <class_World>`, :ref:`Viewport <class_Viewport>` has
  91. the option to use its own :ref:`World <class_World>`. This is useful when you want to
  92. instance 3D characters or objects in a 2D :ref:`World <class_World2D>`.
  93. For 2D, each :ref:`Viewport <class_Viewport>` always contains its own :ref:`World2D <class_World2D>`.
  94. This suffices in most cases, but in case sharing them may be desired, it
  95. is possible to do so by setting the :ref:`Viewport's <class_Viewport>` :ref:`World2D <class_World2D>` manually.
  96. 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.
  97. Capture
  98. -------
  99. It is possible to query a capture of the :ref:`Viewport <class_Viewport>` contents. For the root
  100. :ref:`Viewport <class_Viewport>`, this is effectively a screen capture. This is done with the
  101. following code:
  102. ::
  103. # Retrieve the captured Image using get_data().
  104. var img = get_viewport().get_texture().get_data()
  105. # Flip on the Y axis.
  106. # You can also set "V Flip" to true if not on the root Viewport.
  107. img.flip_y()
  108. # Convert Image to ImageTexture.
  109. var tex = ImageTexture.new()
  110. tex.create_from_image(img)
  111. # Set Sprite Texture.
  112. $sprite.texture = tex
  113. But if you use this in ``_ready()`` or from the first frame of the :ref:`Viewport's <class_Viewport>` initialization,
  114. you will get an empty texture because there is nothing to get as texture. You can deal with
  115. it using (for example):
  116. ::
  117. # Wait until the frame has finished before getting the texture.
  118. yield(VisualServer, "frame_post_draw")
  119. # You can get the image after this.
  120. Viewport Container
  121. ------------------
  122. If the :ref:`Viewport <class_Viewport>` is a child of a :ref:`ViewportContainer <class_viewportcontainer>`, it will become active and display anything it has inside. The layout looks like this:
  123. .. image:: img/container.png
  124. The :ref:`Viewport <class_Viewport>` will cover the area of its parent :ref:`ViewportContainer <class_viewportcontainer>` completely
  125. if :ref:`Stretch<class_viewportcontainer_property_stretch>` is set to ``true`` in :ref:`ViewportContainer <class_viewportcontainer>`.
  126. Note: The size of the :ref:`ViewportContainer <class_viewportcontainer>` cannot be smaller than the size of the :ref:`Viewport <class_Viewport>`.
  127. Rendering
  128. ---------
  129. Due to the fact that the :ref:`Viewport <class_Viewport>` is an entryway into another rendering surface, it exposes a few
  130. rendering properties that can be different from the project settings. The first is MSAA; you can
  131. choose to use a different level of MSAA for each :ref:`Viewport <class_Viewport>`; the default behavior is DISABLED.
  132. You can also set the :ref:`Viewport <class_Viewport>` to use HDR, HDR is very useful for when you want to store values in the texture that are outside the range 0.0 - 1.0.
  133. If you know how the :ref:`Viewport <class_Viewport>` is going to be used, you can set its Usage to either 3D or 2D. Godot will then
  134. restrict how the :ref:`Viewport <class_Viewport>` is drawn to in accordance with your choice; default is 3D.
  135. The 2D usage mode is slightly faster and uses less memory compared to the 3D one. It's a good idea to set the :ref:`Viewport <class_Viewport>`'s Usage property to 2D if your viewport doesn't render anything in 3D.
  136. .. note::
  137. If you need to render 3D shadows in the viewport, make sure to set the viewport's *Shadow Atlas Size* property to a value higher than 0.
  138. Otherwise, shadows won't be rendered. For reference, the Project Settings define it to 4096 by default.
  139. Godot also provides a way of customizing how everything is drawn inside :ref:`Viewports <class_Viewport>` using “Debug Draw”.
  140. Debug Draw allows you to specify one of four options for how the :ref:`Viewport <class_Viewport>` will display things drawn
  141. inside it. Debug Draw is disabled by default.
  142. .. image:: img/default_scene.png
  143. *A scene drawn with Debug Draw disabled*
  144. The other three options are Unshaded, Overdraw, and Wireframe. Unshaded draws the scene
  145. without using lighting information so all the objects appear flatly colored the color of
  146. their albedo.
  147. .. image:: img/unshaded.png
  148. *The same scene with Debug Draw set to Unshaded*
  149. Overdraw draws the meshes semi-transparent with an additive blend so you can see how the meshes overlap.
  150. .. image:: img/overdraw.png
  151. *The same scene with Debug Draw set to Overdraw*
  152. Lastly, Wireframe draws the scene using only the edges of triangles in the meshes.
  153. .. note::
  154. The effects of the Wireframe mode are only visible in the editor, not while the project is running.
  155. Render target
  156. -------------
  157. When rendering to a :ref:`Viewport <class_Viewport>`, whatever is inside will not be
  158. visible in the scene editor. To display the contents, you have to draw the :ref:`Viewport's <class_Viewport>` :ref:`ViewportTexture <class_ViewportTexture>` somewhere.
  159. This can be requested via code using (for example):
  160. ::
  161. # This gives us the ViewportTexture.
  162. var rtt = viewport.get_texture()
  163. sprite.texture = rtt
  164. Or it can be assigned in the editor by selecting "New ViewportTexture"
  165. .. image:: img/texturemenu.png
  166. and then selecting the :ref:`Viewport <class_Viewport>` you want to use.
  167. .. image:: img/texturepath.png
  168. Every frame, the :ref:`Viewport <class_Viewport>`'s texture is cleared away with the default clear color (or a transparent
  169. color if :ref:`Transparent Bg<class_Viewport_property_transparent_bg>` is set to ``true``). This can be changed by setting :ref:`Clear Mode<class_Viewport_property_render_target_clear_mode>` to Never or Next Frame.
  170. As the name implies, Never means the texture will never be cleared, while next frame will
  171. clear the texture on the next frame and then set itself to Never.
  172. By default, re-rendering of the :ref:`Viewport <class_Viewport>` happens when the
  173. :ref:`Viewport <class_Viewport>`'s :ref:`ViewportTexture <class_ViewportTexture>` has been drawn in a frame. If visible, it will be
  174. rendered; otherwise, it will not. This behavior can be changed to manual
  175. rendering (once), or always render, no matter if visible or not. This flexibility
  176. allows users to render an image once and then use the texture without
  177. incurring the cost of rendering every frame.
  178. Make sure to check the Viewport demos! Viewport folder in the demos
  179. archive available to download, or
  180. https://github.com/godotengine/godot-demo-projects/tree/master/viewport