Optimización del rendimiento
Optimiza tu escena para que cargue rápido y funcione sin problemas para todos los jugadores.
Hay varios aspectos que puedes optimizar en tus escenas para asegurar la mejor experiencia posible para los jugadores que las visitan. Este documento cubre algunas prácticas recomendadas que pueden hacer una gran diferencia en la rapidez con que se carga tu escena y en la fluidez con la que se ejecuta para los jugadores que están en ella o en escenas vecinas.
Ten en cuenta que muchos jugadores pueden estar visitando Decentraland usando hardware que no está diseñado para juegos, y a través del navegador, lo que limita cuánto del poder de procesamiento del hardware está disponible para usar. La experiencia de visitar tu escena debe ser fluida para todos.
El Explorer de Decentraland aplica muchas optimizaciones a nivel de engine. Estas optimizaciones marcan una gran diferencia, pero el desafío de renderizar múltiples experiencias generadas por usuarios simultáneamente en un navegador es grande. Necesitamos tu ayuda para que todo funcione sin problemas.
Temporización
Reproducción de video
Reproducir videos es una de las tareas más costosas para que el engine las maneje. Si tu escena incluye videos, asegúrate de que solo UNO VideoTexture esté en uso a la vez. Puedes tener docenas de planos compartiendo la misma VideoTexture sin un impacto significativo en el rendimiento, pero tan pronto como añades una segunda VideoTexture, sus efectos en la tasa de frames se vuelven muy notorios.
También debes evitar tener videos reproduciéndose en regiones donde no pueden verse. Por ejemplo, si tienes una pantalla en interiores, activa o desactiva el video usando un trigger area basado en cuándo el jugador entra y sale.
💡 Consejo: Un truco que varias escenas han usado es transmitir un único video con múltiples regiones que se mapean de manera diferente a distintos planos. 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 costo de múltiples VideoTextures.
💡 Consejo: Cuando los jugadores están fuera de tu escena, las VideoTextures no se actualizan en cada frame. Esto ayuda a reducir el impacto para las escenas circundantes. No obstante, lo ideal es activar la reproducción de cualquier video solo cuando los jugadores entren en tu escena .
Carga diferida
Si tu escena es grande, o tiene áreas interiores que no siempre son visibles, puedes optar por no cargar el conjunto completo de entidades desde el inicio. En su lugar, carga el contenido por región a medida que el jugador visita diferentes partes de la escena. Esto puede reducir significativamente el tiempo de carga de la escena, y también la cantidad de texturas y contenido 3D que el engine necesita manejar en cada frame.
Por ejemplo, el edificio principal de un museo podría cargarse desde el inicio, pero las pinturas de cada piso solo se cargan para cada jugador cuando visitan ese piso.
Ver esta escena de ejemplo para ver cómo podría funcionar eso.
Para obtener el mejor resultado en términos de evitar tartamudeos, oculta entidades cambiando la propiedad visible de su shape a false. Con este enfoque, las agregas al engine al crearlas, pero simplemente no haces visibles sus modelos.
Una alternativa es no añadir las entidades al engine hasta que sean necesarias. Esto puede resultar en algunos tartamudeos cuando las entidades aparecen por primera vez, y también podrían tardar un par de segundos en volverse visibles. La ventaja de este enfoque es que es una forma válida de eludir las limitaciones de la escena. Ten en cuenta que el conteo de limitaciones de la escena es para el contenido que se está renderizando en la escena en un momento dado, no para el contenido total que podría renderizarse. Cargar y descargar partes de la escena debería permitirte sortear esas limitaciones.
📔 Nota: Las entidades que no son visibles pero que están agregadas al engine sí cuentan para las limitaciones de la escena.
También puedes activar o desactivar animaciones para entidades que estén lejanas u ocultas. Por ejemplo, para un NPC que reproduce una animación de idle muy sutil, podrías hacer que solo reproduzca esa animación cuando el jugador esté a menos de 20 metros. Usa un trigger area alrededor del NPC y activa o desactiva sus animaciones según corresponda.
💡 Consejo: Cuando una entidad está lejos y lo suficientemente pequeña, es descartada (culled) por el engine. Este culling ayuda a nivel de drawcall; eliminar entidades del engine siempre es mejor. Este culling tampoco tiene en cuenta la oclusión por otras entidades, por lo que entidades que no son tan pequeñas pero están ocultas por una pared aún se renderizan.
Bloques async
Bloques de código async se procesan en un hilo separado del resto de la escena, para evitar bloquear el progreso de todo lo demás.
Cualquier proceso que dependa de respuestas de servicios asincrónicos, como getPlayerData() o getRealm() debe ejecutarse siempre en bloques async, ya que de lo contrario bloquean el resto de la carga de la escena mientras esperan una respuesta. Lo mismo aplica para cualquier llamada a servidores de terceros.
Ten en cuenta que la escena se considerará completamente cargada cuando todo lo que no es async haya terminado. Los procesos async podrían seguir ejecutándose cuando el jugador entra en la escena. Evita situaciones donde un proceso async resulte en la carga de una entidad que potencialmente podría dejar al jugador atascado dentro de su geometría.
Apóyate en Events
Procura que la lógica de la escena se base en escuchar events tanto como sea posible, en lugar de ejecutar comprobaciones en cada frame.
La update() función en un system se ejecuta en cada frame, 30 veces por segundo (idealmente). Evita hacer comprobaciones recurrentes si en su lugar puedes suscribirte a un event.
Por ejemplo, en lugar de comprobar constantemente los wearables del jugador, puedes suscribirte al onProfileChanged event, 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 el período que tenga sentido.
Optimiza modelos 3D
Hay varias maneras en que tus modelos 3D pueden optimizarse para ser más ligeros.
Al trabajar con el Creator Hub, puedes ver estadísticas sobre los recursos usados por los modelos 3D en tu escena, y si pasan alguno de los limitaciones de la escena.

Puedes expandir este menú para ver detalles.

Aquí hay algunos consejos para mejorar estas métricas:
Cuando sea posible, comparte texturas entre modelos 3D. Una buena práctica es usar una única textura como atlas, compartida entre todos los modelos de la escena. Es mejor tener 1 textura grande compartida de 1024x1024 píxeles en lugar de varias pequeñas.
Nota: Evita usar el mismo archivo de imagen tanto para la textura albedo como para el mapa normal o el mapa emissive de un material. Usa archivos separados, incluso si son idénticos. Asignar el mismo archivo de imagen a diferentes tipos de propiedades de textura puede introducir artefactos visuales no deseados cuando se comprimen en 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 texturas como un archivo separado. Puedes tener lo mejor de ambos mundos usando la siguiente canalización, que te permite tener .glb modelos con archivos de textura externos.
Evita usar transparencias mezcladas (blended). Las transparencias blended tienen que eludir varias optimizaciones de renderizado. Si es posible, prefiere geometría opaca o con alpha test.
Evita meshes skinned. Pueden afectar significativamente al rendimiento.
💡 Consejo: Lee más sobre las buenas prácticas de modelos 3D en la [Sección de Modelado 3D](/creator/3d-modeling/3d-models
Backface Culling
Para la optimización del rendimiento, Backface Culling se establecerá en On on todas los materiales del modelo una vez renderizados en el engine, independientemente de sus configuraciones.
Si esperas ver la cara trasera o el interior de tus modelos, duplica las caras e invierte las normales.
Resolución de problemas
Para verificar si una escena tiene problemas de Backface Culling en materiales, sigue estos pasos:
Abre el
debugpanel en la escena.
Si la escena está publicada, escribe el comando
/debugen el chat.Si estás en modo Preview en la escena, haz clic en el ícono de Bug (
) ubicado en la esquina superior derecha de la pantalla.
El panel de debug aparecerá en la esquina inferior derecha de la pantalla.
Bajo Current Scene, haz clic en el botón Backface debugger .

Activa Force Backface Culling: Muestra los materiales renderizados con Backface Culling On. Este es el render real una vez que la Optimization está en producción. Activa y desactiva para detectar materiales que necesitan ser corregidos.
Activa el Backface debugger para detectar fácilmente materiales que tienen Backface Culling Off. Resalta:
Rojo: Materiales que no tienen Backface Culling establecido en On.
Verde: Materiales con Backface Culling On.
Material con Backface Culling Off (izquierda) vs. Backface Culling On (derecha)
Conversión a Asset Bundle
Aproximadamente una vez al día, los servidores de contenido de Decentraland ejecutan un proceso para comprimir cada .gltf y .glb modelo en cada escena recién desplegada al formato asset bundle. Este formato es significativamente más ligero, haciendo que las escenas se carguen mucho más rápido y se ejecuten con más suavidad en el navegador.
💡 Consejo: Al planificar un evento en Decentraland, asegúrate de desplegar tu escena con un día de antelación, para que los modelos ya estén convertidos a asset bundles para entonces. Si no quieres arruinar la sorpresa antes del evento, puedes desplegar una versión de tu escena 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 cualquier cambio a un archivo de modelo 3D, incluso si es solo un cambio de nombre, será considerado un archivo nuevo y deberá convertirse de nuevo al formato asset bundle.
Conectividad
Si tu escena se conecta a servidores de terceros o usa el messagebus para enviar mensajes entre jugadores, también hay algunas cosas que podrías tener en cuenta.
Tu escena solo debe tener una conexión WebSockets activa a la vez.
Las llamadas HTTP son canalizadas por el engine para que solo una se maneje a la vez. Cualquier solicitud adicional se encola internamente y debe esperar hasta que otras solicitudes se completen. Este proceso de encolado se maneja automáticamente, no necesitas hacer nada.
Al usar el messagebus para enviar mensajes entre jugadores, ten en cuenta que todos los mensajes se envían a todos los demás jugadores en la isla del servidor. Evita situaciones donde un mensaje entrante resulte directamente en el envío de otro mensaje, ya que el número de mensajes puede crecer rápidamente de forma exponencial cuando hay multitud en la escena.
UI de la escena
Las UIs de escena pueden volverse 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 múltiples elementos en una sola imagen. Por ejemplo, si tienes un menú con varios elementos de texto, lo ideal es tener el texto de las casillas y cualquier imagen adicional baked en la imagen de fondo. Eso evita que el engine haga un drawcall adicional por frame para cada elemento de texto.
Evita hacer ajustes a la UI en cada frame; estos son especialmente costosos y pueden terminar encolados. Por ejemplo, si hay una barra de salud en tu UI que debe reducirse con el tiempo, los jugadores probablemente no notarían diferencia si se actualiza a 10 FPS en lugar de 30 FPS (en cada frame). El sistema que actualiza esta barra puede usar un breve temporizador que cuente 100 milisegundos y solo afectar la UI cuando este temporizador llegue a 0.
Evita tener muchos elementos de UI ocultos; estos también afectan el rendimiento incluso si no se están renderizando. Cuando sea posible, intenta crear componentes de UI bajo demanda.
Monitorea el rendimiento
La mejor métrica para saber qué tan bien está rindiendo una escena es el FPS (Frames Per Second). En preview, puedes ver el FPS actual de la escena en el panel de debug. Debes apuntar a tener siempre 30 FPS o más.
En la escena 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 escena suele ser el envío de mensajes entre el código de la escena y el engine.
Cuando ejecutas una escena en preview, nota que en la esquina superior derecha dice “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 de ‘Processed Messages’ crece. Debes vigilar de cerca el número ‘Pending on Queue’, debería ser siempre 0 o cercano a 0. Esto te indica cuántos de estos mensajes no se llegaron a procesar y fueron empujados a una cola. Si el conteo de ‘Pending on Queue’ comienza a crecer, entonces has entrado en la zona de peligro y deberías considerar hacer más optimizaciones a tu escena.
📔 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 experimentes en preview puede diferir del de producción:
Las escenas vecinas circundantes podrían tener un impacto negativo
La compresión de los modelos 3D de las escenas en asset bundles puede tener un impacto positivo
Algunos jugadores que visitan tu escena pueden estar usando hardware menos potente
Siempre es una buena práctica intentar desplegar tu escena primero en el entorno de prueba para hacer pruebas más exhaustivas.
Siempre pide a los jugadores retroalimentación. Nunca des por sentado que la forma en que tú experimentas la escena es la misma para todos los demás.
Última actualización