Godot suit une philosophie de performance équilibrée. Dans le monde de la performance, il y a toujours des compromis à faire, qui consistent à troquer la vitesse contre la facilité d'utilisation et la flexibilité. En voici quelques exemples pratiques :

  • Rendering large amounts of objects efficiently is easy, but when a large scene must be rendered, it can become inefficient. To solve this, visibility computation must be added to the rendering. This makes rendering less efficient, but at the same time, fewer objects are rendered. Therefore, the overall rendering efficiency is improved.
  • Configuring the properties of every material for every object that needs to be rendered is also slow. To solve this, objects are sorted by material to reduce the costs. At the same time, sorting has a cost.
  • In 3D physics, a similar situation happens. The best algorithms to handle large amounts of physics objects (such as SAP) are slow at insertion/removal of objects and raycasting. Algorithms that allow faster insertion and removal, as well as raycasting, will not be able to handle as many active objects.

And there are many more examples of this! Game engines strive to be general-purpose in nature. Balanced algorithms are always favored over algorithms that might be fast in some situations and slow in others, or algorithms that are fast but are more difficult to use.

Godot is not an exception to this. While it is designed to have backends swappable for different algorithms, the default backends prioritize balance and flexibility over performance.

Dans cette optique, l'objectif de ce tutoriel est d'expliquer comment tirer les performances maximums de Godot. Bien que les tutoriels puissent être lus dans n'importe quel ordre, il est bon de commencer par Conseils généraux d'optimisation.