optimizing_3d_performance.rst 7.2 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174
  1. .. meta::
  2. :keywords: optimization
  3. .. _doc_optimizing_3d_performance:
  4. Optimizing 3D performance
  5. =========================
  6. Culling
  7. =======
  8. Godot will automatically perform view frustum culling in order to prevent
  9. rendering objects that are outside the viewport. This works well for games that
  10. take place in a small area, however things can quickly become problematic in
  11. larger levels.
  12. Occlusion culling
  13. ~~~~~~~~~~~~~~~~~
  14. Walking around a town for example, you may only be able to see a few buildings
  15. in the street you are in, as well as the sky and a few birds flying overhead. As
  16. far as a naive renderer is concerned however, you can still see the entire town.
  17. It won't just render the buildings in front of you, it will render the street
  18. behind that, with the people on that street, the buildings behind that. You
  19. quickly end up in situations where you are attempting to render 10× or 100× more
  20. than what is visible.
  21. Things aren't quite as bad as they seem, because the Z-buffer usually allows the
  22. GPU to only fully shade the objects that are at the front. This is called *depth
  23. prepass* and is enabled by default in Godot when using the GLES3 renderer.
  24. However, unneeded objects are still reducing performance.
  25. One way we can potentially reduce the amount to be rendered is to take advantage
  26. of occlusion.
  27. For instance, in our city street scenario, you may be able to work out in advance
  28. that you can only see two other streets, ``B`` and ``C``, from street ``A``.
  29. Streets ``D`` to ``Z`` are hidden. In order to take advantage of occlusion, all
  30. you have to do is work out when your viewer is in street ``A`` (perhaps using
  31. Godot Areas), then you can hide the other streets.
  32. This example is a manual version of what is known as a *potentially visible set*.
  33. It is a very powerful technique for speeding up rendering. You can also use it to
  34. restrict physics or AI to the local area, and speed these up as well as
  35. rendering.
  36. However, there are easier ways to take advantage of occlusion. Godot includes two
  37. built-in systems to automate occlusion culling:
  38. Occluders
  39. ~~~~~~~~~
  40. Occluder nodes can manually be placed in a scene. These will automatically hide
  41. objects that are behind the occluder. See :ref:`Occluder Nodes <doc_occluders>`.
  42. Portal Rendering
  43. ~~~~~~~~~~~~~~~~
  44. Godot features an advanced portal rendering system, which can perform occlusion
  45. culling from cameras and lights. See :ref:`doc_rooms_and_portals`.
  46. This is not a fully automatic system and it requires some manual setup. However, it potentially
  47. offers significant performance increases.
  48. .. note::
  49. In some cases, you can adapt your level design to add more occlusion
  50. opportunities. For example, you can add more walls to prevent the player
  51. from seeing too far away, which would decrease performance due to the lost
  52. opportunities for occlusion culling.
  53. Other occlusion techniques
  54. ~~~~~~~~~~~~~~~~~~~~~~~~~~
  55. As well as the portal system and manual methods, there are various other occlusion
  56. techniques such as raster-based occlusion culling. Some of these may be available
  57. through add-ons or may be available in core Godot in the future.
  58. Transparent objects
  59. ~~~~~~~~~~~~~~~~~~~
  60. Godot sorts objects by :ref:`Material <class_Material>` and :ref:`Shader
  61. <class_Shader>` to improve performance. This, however, can not be done with
  62. transparent objects. Transparent objects are rendered from back to front to make
  63. blending with what is behind work. As a result,
  64. **try to use as few transparent objects as possible**. If an object has a
  65. small section with transparency, try to make that section a separate surface
  66. with its own material.
  67. For more information, see the :ref:`GPU optimizations <doc_gpu_optimization>`
  68. doc.
  69. Level of detail (LOD)
  70. =====================
  71. In some situations, particularly at a distance, it can be a good idea to
  72. **replace complex geometry with simpler versions**. The end user will probably
  73. not be able to see much difference. Consider looking at a large number of trees
  74. in the far distance. There are several strategies for replacing models at
  75. varying distance. You could use lower poly models, or use transparency to
  76. simulate more complex geometry.
  77. You can either implement LOD manually, or make use of the ``LOD`` node, which
  78. automates much of the process. See the :ref:`Level of Detail <doc_level_of_detail>`
  79. documentation.
  80. Billboards and imposters
  81. ~~~~~~~~~~~~~~~~~~~~~~~~
  82. The simplest version of using transparency to deal with LOD is billboards. For
  83. example, you can use a single transparent quad to represent a tree at distance.
  84. This can be very cheap to render, unless of course, there are many trees in
  85. front of each other. In which case transparency may start eating into fill rate
  86. (for more information on fill rate, see :ref:`doc_gpu_optimization`).
  87. An alternative is to render not just one tree, but a number of trees together as
  88. a group. This can be especially effective if you can see an area but cannot
  89. physically approach it in a game.
  90. You can make imposters by pre-rendering views of an object at different angles.
  91. Or you can even go one step further, and periodically re-render a view of an
  92. object onto a texture to be used as an imposter. At a distance, you need to move
  93. the viewer a considerable distance for the angle of view to change
  94. significantly. This can be complex to get working, but may be worth it depending
  95. on the type of project you are making.
  96. Use instancing (MultiMesh)
  97. ~~~~~~~~~~~~~~~~~~~~~~~~~~
  98. If several identical objects have to be drawn in the same place or nearby, try
  99. using :ref:`MultiMesh <class_MultiMesh>` instead. MultiMesh allows the drawing
  100. of many thousands of objects at very little performance cost, making it ideal
  101. for flocks, grass, particles, and anything else where you have thousands of
  102. identical objects.
  103. Also see the :ref:`Using MultiMesh <doc_using_multimesh>` doc.
  104. Bake lighting
  105. =============
  106. Lighting objects is one of the most costly rendering operations. Realtime
  107. lighting, shadows (especially multiple lights), and GI are especially expensive.
  108. They may simply be too much for lower power mobile devices to handle.
  109. **Consider using baked lighting**, especially for mobile. This can look fantastic,
  110. but has the downside that it will not be dynamic. Sometimes, this is a trade-off
  111. worth making.
  112. In general, if several lights need to affect a scene, it's best to use
  113. :ref:`doc_baked_lightmaps`. Baking can also improve the scene quality by adding
  114. indirect light bounces.
  115. Animation and skinning
  116. ======================
  117. Animation and vertex animation such as skinning and morphing can be very
  118. expensive on some platforms. You may need to lower the polycount considerably
  119. for animated models or limit the number of them on screen at any one time.
  120. Large worlds
  121. ============
  122. If you are making large worlds, there are different considerations than what you
  123. may be familiar with from smaller games.
  124. Large worlds may need to be built in tiles that can be loaded on demand as you
  125. move around the world. This can prevent memory use from getting out of hand, and
  126. also limit the processing needed to the local area.
  127. There may also be rendering and physics glitches due to floating point error in
  128. large worlds. You may be able to use techniques such as orienting the world
  129. around the player (rather than the other way around), or shifting the origin
  130. periodically to keep things centred around ``Vector3(0, 0, 0)``.