Optimizando las prestaciones en 3D

Polling

Godot will automatically perform view frustum culling in order to prevent rendering objects that are outside the viewport. This works well for games that take place in a small area, however things can quickly become problematic in larger levels.

Eliminación de oclusión

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.3, 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.

Nota

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.

Otras técnicas de oclusión

Existen otras técnicas de oclusión como portales, PVS automáticos y eliminación selectiva de oclusión basada en ráster. Algunos de estos pueden estar disponibles a través de complementos y pueden estar disponibles en el core de Godot en el futuro.

Objetos transparentes

Como se mencionó antes, Godot clasifica los objetos por material y shader para mejorar el rendimiento. Esto, sin embargo, no se puede hacer en objetos transparentes. Los objetos transparentes se renderizan de atrás hacia adelante para hacer que se mezclen con lo que hay detrás del trabajo. Por lo tanto ¡intenta reducir al mínimo la transparencia de los objetos! Si un objeto tiene una sección pequeña con transparencia, intenta hacer de esa sección un material independiente.Godot ordena los objetos por Material y Shader para mejorar el rendimiento. Sin embargo, esto no se puede hacer con objetos transparentes. Los objetos transparentes se renderizan de atrás hacia adelante para combinarlos con lo que hay detrás. Como resultado, intente utilizar la menor cantidad posible de objetos transparentes. Si un objeto tiene una sección pequeña con transparencia, intente hacer de esa sección una superficie separada con su propio material.

Para obtener más información, consulte GPU optimizations doc.

Nivel de detalle (LOD)

En algunas situaciones, particularmente a distancia, puede ser una buena idea ** reemplazar geometrías complejas con versiones más simples **. El usuario final probablemente no podrá ver mucha diferencia. Considere mirar una gran cantidad de árboles a lo lejos. Existen varias estrategias para reemplazar modelos a diferentes distancias. Puede usar modelos con polígonos mas bajos o usar transparencia para simular geometrías más complejas.

Vallas publicitarias e impostores

La versión más simple de usar la transparencia para lidiar con LOD son los billboards. Por ejemplo, puede utilizar un solo quad transparente para representar un árbol a distancia. Esto puede ser muy económico de renderizar, a menos que, por supuesto, haya muchos árboles uno frente al otro. En cuyo caso la transparencia puede comenzar a consumir la tasa de llenado (para obtener más información sobre la tasa de llenado, consulte: ref: doc_gpu_optimization).

Una alternativa es renderizar no solo un árbol, sino un numero de arboles juntos como grupo. Esto puede ser efectivo especialmente si puedes ver el área pero no puedes aproximarte físicamente en el juego.

You can make imposters by pre-rendering views of an object at different angles. Or you can even go one step further, and periodically re-render a view of an object onto a texture to be used as an imposter. At a distance, you need to move the viewer a considerable distance for the angle of view to change significantly. This can be complex to get working, but may be worth it depending on the type of project you are making.

Usar la instanciación (MultiMesh)

Si hay que dibujar varios objetos iguales en el mismo lugar o cercanos entre sí, intenta usar MultiMesh en su lugar. MultiMesh permite dibujar decenas de miles de objetos con un coste de rendimiento muy bajo, lo que lo hace ideal para multitudes, hierba, partículas, etc.

Véase también el documento Using MultiMesh.

Bake de iluminación

Lighting objects is one of the most costly rendering operations. Realtime lighting, shadows (especially multiple lights), and GI are especially expensive. They may simply be too much for lower power mobile devices to handle.

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 general, si varias luces necesitan afectar una escena, es mejor usar Baked lightmaps. Hornear también puede mejorar la calidad de la escena al agregar rebotes de luz indirectos.

Animación y 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.

Mundos extensos

Si está creando mundos grandes, hay consideraciones diferentes que le puede ser familiar en los juegos más pequeños.

Mundos grandes pueden necesitar ser construidos en tiles que se pueden cargar bajo demanda mientras se mueve por el mundo. Esto puede evitar que el uso de la memoria se vaya de las manos y también limitar el procesamiento necesario al área local.

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).