Optimizando las prestaciones en 3D¶
Polling¶
Godot realizará automáticamente culling de frustum de vista para evitar renderizar objetos que están fuera de la vista del viewport. Esto funciona bien para juegos que se desarrollan en áreas pequeñas, sin embargo, puede haber problemas rápidamente en niveles más grandes.
Eliminación de oclusión¶
Al caminar por una ciudad, por ejemplo, es posible que solo puedas ver unos pocos edificios en la calle en la que te encuentras, así como el cielo y algunos pájaros volando por encima. Sin embargo, desde la perspectiva de un renderizador ingenuo, aún podrías ver toda la ciudad. No solo renderizará los edificios que tienes enfrente, sino también la calle detrás de ellos, con las personas en esa calle y los edificios que están más lejos. Rápidamente te encontrarás en situaciones en las que intentas renderizar 10× o 100× más de lo que es visible.
Las cosas no son tan malas como parecen, porque el Z-buffer generalmente permite que la GPU solo sombree completamente los objetos que están al frente. Esto se conoce como depth prepass y está habilitado de forma predeterminada en Godot cuando se utiliza el renderizador GLES3. Sin embargo, los objetos innecesarios aún reducen el rendimiento.
Una forma en la que potencialmente podemos reducir la cantidad a renderizar es aprovechando la occlusión.
Por ejemplo, en nuestro escenario de la calle de la ciudad, puedes determinar de antemano que solo puedes ver otras dos calles, B y C, desde la calle A. Las calles D a Z están ocultas. Para aprovechar la occlusión, lo único que tienes que hacer es determinar cuándo tu visor está en la calle A (quizás utilizando áreas de Godot) y luego puedes ocultar las otras calles.
Este ejemplo es una versión manual de lo que se conoce como un conjunto potencialmente visible (potentially visible set). Es una técnica muy poderosa para acelerar el renderizado. También puedes usarla para restringir la física o la inteligencia artificial al área local y acelerar tanto el renderizado como estos aspectos.
Renderizado por Portales¶
Sin embargo, hay una forma mucho más fácil de aprovechar la occlusión. Godot cuenta con un avanzado sistema de renderizado por portales, que puede realizar culling de occlusión desde cámaras y luces. Consulta la documentación "Salas y portales" para obtener más información al respecto.
Este no es un sistema completamente automático y requiere cierta configuración manual. Sin embargo, potencialmente ofrece aumentos significativos de rendimiento.
Nota
In some cases, you can adapt your level design to add more occlusion opportunities. For example, you can add more walls to prevent the player from seeing too far away, which would decrease performance due to the lost opportunities for occlusion culling.
Otras técnicas de oclusión¶
Además del sistema de portales y los métodos manuales, existen varias técnicas de ocultación como el occlusion culling basado en rasterización. Algunas de estas técnicas pueden estar disponibles a través de complementos o pueden estar disponibles en el propio 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.
Puedes crear impostores mediante la pre-renderización de vistas de un objeto desde diferentes ángulos. Incluso puedes ir un paso más allá y volver a renderizar periódicamente una vista de un objeto en una textura para utilizarla como impostor. A una distancia, es necesario mover al observador una distancia considerable para que el ángulo de visión cambie significativamente. Esto puede ser complejo de implementar, pero puede valer la pena dependiendo del tipo de proyecto que estés desarrollando.
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¶
La iluminación de objetos es una de las operaciones de renderizado más costosas. La iluminación en tiempo real, las sombras (especialmente con múltiples luces) y la iluminación global (GI) son especialmente exigentes en términos de rendimiento. Pueden resultar demasiado para dispositivos móviles de menor potencia para manejar adecuadamente.
Considera utilizar iluminación precalculada (baked lighting), especialmente para dispositivos móviles. Esto puede lucir fantástico, pero tiene la desventaja de que no será dinámico. A veces, este es un compromiso que vale la pena hacer.
En general, si varias luces necesitan afectar una escena, es mejor usar Horneo de mapas de luces. Hornear también puede mejorar la calidad de la escena al agregar rebotes de luz indirectos.
Animación y skinning¶
La animación y la animación de vértices, como el esqueleto (skinning) y la deformación (morphing), pueden ser muy costosas en algunas plataformas. Es posible que debas reducir considerablemente la cantidad de polígonos de los modelos animados o limitar la cantidad de ellos en pantalla al mismo tiempo.
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.
También puede haber errores de renderizado y física debido a errores de punto flotante en mundos grandes. Es posible que puedas utilizar técnicas como orientar el mundo alrededor del jugador (en lugar de al revés) o desplazar el origen periódicamente para mantener las cosas centradas alrededor de Vector3(0, 0, 0).