Optimización del rendimiento

Optimiza tu Scene para que cargue rápido y funcione sin problemas para todos los players.

Hay varios aspectos que puedes optimizar en tus scenes para asegurar la mejor experiencia posible para los jugadores que las visitan. Este documento cubre algunas buenas prácticas que pueden marcar una gran diferencia en lo rápido que carga tu scene y en lo fluido que funciona para los jugadores que están en ella o en scenes vecinas.

Ten en cuenta que muchos jugadores pueden estar visitando Decentraland usando hardware que no está diseñado para gaming, a través del navegador o desde la aplicación móvil en un teléfono; todo ello limita la capacidad de procesamiento disponible para tu scene. La experiencia de visitar tu scene debería ser fluida para todos.

Consulta Recursos útiles para encontrar herramientas que pueden ayudar, como el Decentraland Scene Optimizer, que extrae, deduplica y comprime las textures de los modelos 3D de tu scene.

📱 Móvil: Los dispositivos móviles suelen ser el client con más limitaciones de recursos. Si tu scene está dirigida a players móviles, consulta también Crear para Mobile para obtener orientación específica para móvil.

El Explorer de Decentraland aplica muchas optimizaciones a nivel del Engine. Estas optimizaciones marcan una gran diferencia, pero el reto de renderizar simultáneamente varias experiencias generadas por users en un navegador es enorme. Necesitamos tu ayuda para que todo funcione sin problemas.

Sincronización

Reproducción de video

Reproducir videos es una de las tareas más costosas para que el Engine las gestione. Si tu scene incluye videos, asegúrate de que solo UNA SOLA VideoTexture esté en uso a la vez. Puedes tener docenas de planes compartiendo la misma VideoTexture sin un impacto significativo en el rendimiento, pero en cuanto añades una segunda VideoTexture, sus efectos en el framerate se vuelven muy notorios.

También deberías evitar que los videos se reproduzcan en regiones donde no pueden verse. Por ejemplo, si tienes una pantalla en interiores, activa o desactiva el video usando un trigger area en función de cuándo el jugador entra y sale.

💡 Consejo: Un truco que varias scenes han usado es transmitir un solo video con varias regiones que se mapean de forma diferente en distintos planes. Cada pantalla de video usa UV mapping para mostrar solo una parte distinta de la VideoTexture. Gracias a esto, puede parecer que hay videos separados reproduciéndose sin el coste de tener varias VideoTextures.

💡 Consejo: Cuando los jugadores están fuera de tu scene, las VideoTextures no se actualizan en cada frame. Esto ayuda a reducir el impacto en las scenes vecinas. No obstante, lo ideal es activar la reproducción de cualquier video solo cuando los jugadores entren en tu scene .

Carga diferida

Si tu scene es grande, o tiene áreas interiores que no siempre son visibles, puedes optar por no cargar todo el conjunto de entities desde el principio. En su lugar, carga el contenido por regiones a medida que el jugador visita distintas partes de la scene. Esto puede reducir significativamente el tiempo de carga de la scene, y también la cantidad de textures y contenido 3D que el Engine necesita gestionar en cada frame.

Por ejemplo, el edificio principal de un museo podría cargarse desde el principio, pero las pinturas de cada piso solo se cargarían para cada jugador a medida que visite cada piso.

Consulta esta scene de ejemplo para ver cómo podría funcionar.

Para obtener el mejor resultado en términos de evitar tirones, oculta las entities cambiando la visible propiedad a false. Con este enfoque, los añades al Engine al crearlos, pero simplemente no haces visibles sus modelos.

Una alternativa es no añadir las entities al Engine hasta que se necesiten. Esto puede provocar algunos tirones cuando las entities aparecen por primera vez, y también pueden tardar un par de segundos en hacerse visibles. La ventaja de este enfoque es que es una forma válida de sortear los scene limitations. Ten en cuenta que el conteo de límites de la scene corresponde al contenido que se está renderizando en la scene en cualquier momento dado, no al contenido total que podría renderizarse. Cargar y descargar partes de la scene debería permitirte sortear esas limitaciones.

📔 Nota: Las entities que no son visibles pero sí se añaden al Engine cuentan para los límites de la scene.

También puedes activar o desactivar las animations de las entities que estén lejos u ocultas. Por ejemplo, para un NPC que reproduce una animación idle muy sutil, podrías hacer que solo reproduzca esa animation cuando el jugador esté a menos de 20 metros. Usa un trigger area alrededor del NPC y activa o desactiva sus animations en consecuencia.

💡 Consejo: Cuando una entity está lo suficientemente lejos y es pequeña, el Engine la culla. Este culling ayuda a nivel de drawcall; eliminar entities del Engine siempre es mejor. Este culling tampoco tiene en cuenta la oclusión por otras entities, así que las entities que no son tan pequeñas pero están ocultas por una pared siguen renderizándose.

Bloques asíncronos

Bloques de código asíncrono no bloquean el progreso de todo lo demás mientras esperan: la scene sigue ejecutándose, y el bloque async se reanuda cuando llega la respuesta esperada. Ten en cuenta que las scenes se ejecutan en un solo thread, así que esto no es procesamiento paralelo; solo evita que la scene se bloquee mientras espera respuestas externas.

Cualquier proceso que dependa de respuestas de servicios asíncronos, como getPlayerData() o getRealm() debe ejecutarse siempre en bloques async, ya que de lo contrario bloquean el resto de la carga de la scene mientras esperan una respuesta. Lo mismo se aplica a cualquier llamada a servidores de terceros.

Ten en cuenta que la scene se considerará completamente cargada cuando termine todo lo que no sea async. Es posible que los procesos async sigan ejecutándose cuando el jugador entre en la scene. Evita situaciones en las que un proceso async provoque la carga de una entity que podría dejar al jugador atrapado dentro de su geometry.

Apóyate en los eventos

Intenta que la lógica de la scene dependa de escuchar eventos todo lo posible, en lugar de ejecutar comprobaciones en cada frame.

El update() función en un System se ejecuta en cada frame, 30 veces por segundo (idealmente). Evita hacer comprobaciones recurrentes si puedes suscribirte en su lugar a un event.

Por ejemplo, en lugar de comprobar constantemente los wearables del jugador, puedes suscribirte al onProfileChanged evento, y comprobar los wearables del jugador solo cuando hayan cambiado.

Si debes usar un System, evita hacer comprobaciones o ajustes en cada frame. Puedes incluir un temporizador como parte de la función update y ejecutar la comprobación solo una vez por cada segundo completo, o por el período que tenga sentido.

Optimiza los modelos 3D

Hay varias formas de optimizar tus modelos 3D para que sean más ligeros.

Cuando trabajes con el Creator Hubpuedes ver estadísticas sobre los recursos que usan los modelos 3D de tu scene, y si superan alguno de los scene limitations.

Puedes desplegar este menú para ver los detalles.

Aquí tienes algunos consejos para mejorar estas métricas:

• Cuando sea posible, comparte textures entre modelos 3D. Una buena práctica es usar una sola texture como atlas map, compartida por todos los modelos de la scene. Es mejor tener 1 texture compartida grande de 1024x1024 píxeles que varias pequeñas.

  Nota: evita usar el mismo archivo de imagen tanto para la textura albedo como para el normal map o el emissive map de un material. Usa archivos separados, aunque sean idénticos. Asignar el mismo archivo de imagen a distintos tipos de propiedades de textura puede introducir artefactos visuales no deseados cuando se comprime a asset bundles.

• .glb es un formato comprimido, siempre pesará menos que un .gltf. Por otro lado, con .gltf es fácil compartir imágenes de textura exportando las textures como un archivo separado. Puedes tener lo mejor de ambos mundos usando el siguiente pipeline, que permite tener .glb modelos con archivos de textura externos.

• Evita usar transparencies mezcladas. Las transparencies mezcladas tienen que saltarse bastantes optimizaciones de renderizado. Si es posible, prioriza la geometry opaca o con alpha test.

• Evita los skinned meshes. Pueden reducir significativamente el rendimiento.

💡 Consejo: Lee más sobre buenas prácticas de modelos 3D en la [Sección de 3D Modeling](/creator/3d-modeling/3d-models

Backface Culling

Para la optimización del rendimiento, Backface Culling se establecerá en Activado activado todos los materiales del modelo una vez renderizados en el Engine, independientemente de su configuración.

Si esperas ver la cara posterior o el interior de tus modelos, duplica las faces e invierte las normals.

Solución de problemas

Para verificar si una scene tiene problemas de Backface Culling en los materials, sigue estos pasos:

1. Abre el debug panel en la scene.

• Si la scene está publicada, escribe /debug comando en el chat.

• Si estás en modo Preview en la scene., haz clic en el icono de bug (

  

  icono de debug

  ) ubicado en la esquina superior derecha de la pantalla.

1. El panel de debug aparecerá en la esquina inferior derecha de la pantalla.

2. Debajo de Escena actual, haz clic en el depurador de Backface botón.

1. Alternar Forzar Backface Culling: Muestra los materials renderizados con Backface Culling activado. Este es el renderizado real una vez que la Optimization esté en producción. Alterna entre activado y desactivado para detectar los materials que necesitan corrección.

2. Alterna el depurador de Backface para detectar fácilmente los materials que tienen Backface Culling desactivado. Resalta:

• Rojo: Materials que no tienen Backface Culling configurado en Activado.

• Verde: Materials con Backface Culling Activado.

Material con Backface Culling desactivado (izquierda) frente a Backface Culling activado (derecha)

Conversión a Asset Bundle

Aproximadamente una vez al día, los content servers de Decentraland ejecutan un proceso para comprimir cada .gltf y .glb modelo de cada scene recién desplegada al formato asset bundle. Este formato es significativamente más ligero, lo que hace que las scenes carguen mucho más rápido y funcionen con mayor fluidez en el navegador.

💡 Consejo: Al planificar un evento en Decentraland, asegúrate de desplegar tu scene con un día de antelación, para que todos los modelos se hayan convertido a asset bundles para entonces. Si no quieres arruinar la sorpresa antes del evento, puedes desplegar una versión de tu scene que incluya todos los modelos 3D finales en la carpeta del proyecto, pero donde estos no sean visibles o donde su tamaño esté establecido en 0.

📔 Nota: Si haces any un cambio en un archivo de modelo 3D, aunque sea solo un cambio de nombre, se considerará un archivo nuevo y deberá convertirse de nuevo al formato asset bundle.

Conectividad

Si tu scene se conecta a servidores de terceros o usa el MessageBus para enviar mensajes entre players, también hay algunas cosas que quizá quieras tener en cuenta.

• Tu scene solo debería tener una conexión WebSockets activa a la vez.

• Las llamadas HTTP se canalizan a través del Engine para que solo una se procese a la vez. Cualquier solicitud adicional se pone en cola internamente y debe esperar hasta que terminen las demás solicitudes. Este proceso de cola se gestiona automáticamente; no necesitas hacer nada.

• Cuando uses el MessageBus para enviar mensajes entre players, ten en cuenta que todos los mensajes se envían a todos los demás players de la server island. Evita situaciones en las que un mensaje entrante provoque directamente el envío de otro mensaje, ya que el número de mensajes puede crecer exponencialmente muy rápido cuando hay una multitud en la scene.

UI de la scene

Las UIs de la scene pueden resultar costosas de renderizar cuando están compuestas por muchos elementos individuales. Ten en cuenta que cada elemento de UI requiere un drawcall separado en el Engine.

💡 Consejo: Intenta combinar varios elementos en una sola imagen. Por ejemplo, si tienes un menú con varios elementos de texto, lo ideal es que el texto de los tiles y cualquier imagen adicional se incrusten en la imagen de fondo. Eso le ahorra al Engine un drawcall adicional por frame por cada elemento de texto.

Evita hacer ajustes a la UI en cada frame; eso es especialmente costoso y puede acabar poniéndose en cola. Por ejemplo, si hay una barra de salud en tu UI que debería reducirse con el tiempo, probablemente los jugadores no notarían la diferencia entre que se actualice a 10 FPS en lugar de a 30 FPS (en cada frame). El System que actualiza esta barra puede usar un temporizador breve que cuente 100 milisegundos y solo afectar a la UI cuando ese temporizador llegue a 0.

Evita tener muchos elementos de UI ocultos; también afectan al rendimiento aunque no se estén renderizando. Cuando sea posible, intenta crear los componentes de UI bajo demanda.

Terreno del paisaje en Worlds

Las scenes publicadas en un Decentraland World están rodeadas por un paisaje generado automáticamente de praderas, árboles y mar. Renderizar este paisaje consume parte del presupuesto de renderizado del jugador. Si tu scene no lo necesita, puedes desactivar el terreno del paisaje en tu scene.json para liberar esos recursos para el contenido de tu propia scene.

Monitoriza el rendimiento

La mejor métrica para saber qué tan bien rinde una scene es el FPS (Frames Per Second). En Preview, puedes ver el FPS actual de la scene en el panel de debug. Deberías intentar tener siempre 30 FPS o más.

En la scene desplegada, puedes alternar el panel que muestra estas métricas escribiendo /showfps en la ventana de chat.

Uno de los principales cuellos de botella en el rendimiento de una scene suele ser el envío de mensajes entre el código de la scene y el Engine.

Cuando ejecutes una scene en Preview, ten en cuenta que en la esquina superior derecha aparece “Y = Toggle Panel”. Pulsa Y en el teclado para abrir un panel con información útil que se actualiza en tiempo real.

A medida que interactúas con cosas que implican mensajes entre el SDK y el Engine, notarás que el número ‘Processed Messages’ aumenta. Debes vigilar de cerca el número ‘Pending on Queue’; siempre debería ser 0 o estar cerca de 0. Esto te indica cuántos de esos mensajes no llegaron a procesarse y se enviaron a una cola. Si el conteo de ‘Pending on Queue’ empieza a crecer, entonces has entrado en la zona de peligro y deberías pensar en hacer más optimizaciones en tu scene.

📔 Nota: No mantengas el panel abierto cuando no lo estés usando, ya que tiene un impacto negativo en el rendimiento.

Ten en cuenta que el rendimiento que experimentas en Preview puede diferir del de producción:

• Las scenes vecinas circundantes podrían tener un impacto negativo

• La compresión de los modelos 3D de las scenes en asset bundles puede tener un impacto positivo

• Algunos jugadores que visiten tu scene pueden estar usando hardware menos potente

Siempre es una buena práctica intentar desplegar primero tu scene en un Decentraland World para realizar pruebas más exhaustivas.

Pide siempre feedback a los players. Nunca des por sentado que la forma en que tú experimentas la scene es la misma para todos los demás.