Optimiser les performances 3D

Culling

Godot effectuera automatiquement une un frustrum culling de la vue afin d'éviter de rendre des objets qui se trouvent en dehors du viewport. Cela fonctionne bien pour les jeux qui se déroulent dans une petite zone, mais les choses peuvent rapidement devenir problématiques dans les niveaux plus large.

Occlusion culling

Walking around a town for example, you may only be able to see a few buildings in the street you are in, as well as the sky and a few birds flying overhead. As far as a naive renderer is concerned however, you can still see the entire town. It won't just render the buildings in front of you, it will render the street behind that, with the people on that street, the buildings behind that. You quickly end up in situations where you are attempting to render 10× or 100× more than what is visible.

Things aren't quite as bad as they seem, because the Z-buffer usually allows the GPU to only fully shade the objects that are at the front. This is called depth prepass and is enabled by default in Godot when using the GLES3 renderer. However, unneeded objects are still reducing performance.

One way we can potentially reduce the amount to be rendered is to take advantage of occlusion. As of Godot 3.2.2, there is no built in support for occlusion in Godot. However, with careful design you can still get many of the advantages.

For instance, in our city street scenario, you may be able to work out in advance that you can only see two other streets, B and C, from street A. Streets D to Z are hidden. In order to take advantage of occlusion, all you have to do is work out when your viewer is in street A (perhaps using Godot Areas), then you can hide the other streets.

This is a manual version of what is known as a "potentially visible set". It is a very powerful technique for speeding up rendering. You can also use it to restrict physics or AI to the local area, and speed these up as well as rendering.

Note

In some cases, you may have to adapt your level design to add more occlusion opportunities. For example, you may have to add more walls to prevent the player from seeing too far away, which would decrease performance due to the lost opportunies for occlusion culling.

Autres techniques d'occlusion

There are other occlusion techniques such as portals, automatic PVS, and raster-based occlusion culling. Some of these may be available through add-ons and may be available in core Godot in the future.

Objets transparents

Godot sorts objects by Material and Shader to improve performance. This, however, can not be done with transparent objects. Transparent objects are rendered from back to front to make blending with what is behind work. As a result, try to use as few transparent objects as possible. If an object has a small section with transparency, try to make that section a separate surface with its own material.

Pour plus d'informations, voir la documentation GPU optimizations.

Niveau de détail (LOD)

In some situations, particularly at a distance, it can be a good idea to replace complex geometry with simpler versions. The end user will probably not be able to see much difference. Consider looking at a large number of trees in the far distance. There are several strategies for replacing models at varying distance. You could use lower poly models, or use transparency to simulate more complex geometry.

Billboards(panneaux d'affichage) et imposteurs

La version la plus simple de l'utilisation de la transparence mettre en place de la LOD est celle des panneaux d'affichage (billboards). Par exemple, vous pouvez utiliser un seul quad transparent pour représenter un arbre à distance. Ceci peut donner un rendu bon marché, à moins, bien sûr, qu'il y ait beaucoup d'arbres en face les uns des autres. Dans ce cas, la transparence peut commencer à taper dans le taux de remplissage (pour plus d'informations sur le taux de remplissage, voir doc_gpu_optimisation).

Une alternative consiste à rendre non pas un seul arbre, mais plusieurs arbres ensemble en tant que groupe. Cela peut être particulièrement efficace si vous pouvez voir une zone mais ne pouvez pas l'approcher physiquement dans un jeu.

Vous pouvez créer des imposteurs en pré-rendant des vues d'un objet sous différents angles. Vous pouvez même aller plus loin et re-rendre périodiquement une vue d'un objet sur une texture pour l'utiliser comme un imposteur. À distance, vous devez déplacer le spectateur sur une distance considérable pour que l'angle de vue change de manière significative. Cela peut être complexe à mettre en œuvre, mais peut en valoir la peine selon le type de projet que vous réalisez.

Utiliser l'instanciation (MultiMesh)

Si plusieurs objets identiques doivent être dessinés au même endroit ou à proximité, essayez d'utiliser MultiMesh. MultiMesh permet de dessiner des dizaines de milliers d'objets à très faible coût de performance, ce qui le rend idéal pour les troupeaux, l'herbe, les particules et tout ce qui comporte des milliers d'objets identiques.

Voir aussi la documentation Using MultiMesh.

Préparation de l’éclairage

L'éclairage des objets est l'une des opérations de rendu les plus coûteuses. L'éclairage en temps réel, les ombres (surtout les lumières multiples) et GI sont particulièrement coûteux. Ils peuvent être tout simplement trop élevés pour les appareils mobiles de faible puissance.

Consider using baked lighting, especially for mobile. This can look fantastic, but has the downside that it will not be dynamic. Sometimes, this is a trade-off worth making.

En général, si plusieurs lumières doivent affecter une scène, il est préférable d'utiliser Baked lightmaps. Le pré-calcul peut également améliorer la qualité de la scène en ajoutant des rebonds de lumière indirecte.

Animation and skinning

Animation and vertex animation such as skinning and morphing can be very expensive on some platforms. You may need to lower the polycount considerably for animated models or limit the number of them on screen at any one time.

Grands mondes

Si vous créez de grands mondes, il y a des considérations différentes de celles que vous connaissez peut-être avec les jeux plus petits.

Les grands mondes peuvent devoir être construits dans des tuiles qui peuvent être chargées à la demande lorsque vous vous déplacez dans le monde. Cela peut éviter que l'utilisation de la mémoire ne devienne incontrôlable et limiter le traitement nécessaire à la zone locale.

There may also be rendering and physics glitches due to floating point error in large worlds. You may be able to use techniques such as orienting the world around the player (rather than the other way around), or shifting the origin periodically to keep things centred around Vector3(0, 0, 0).