> For the complete documentation index, see [llms.txt](https://docs.decentraland.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.decentraland.org/creator/content-creator-es/escenas-sdk7/optimizacion/performance-optimization.md).
# Optimización del rendimiento
Hay varios aspectos que puedes optimizar en tus scenes para garantizar la mejor experiencia posible para los jugadores que las visitan. Este documento cubre algunas buenas prácticas que pueden marcar una gran diferencia en la rapidez con la que se carga tu scene y en lo fluido que se ejecuta 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 [app móvil](/creator/content-creator-es/escenas-sdk7/desarrollar-para-movil/building-for-mobile.md) en un teléfono — todo lo cual limita la potencia de procesamiento disponible para tu scene. La experiencia de visitar tu scene debería ser fluida para todos.
{% hint style="info" %}
**📱 Móvil**: Los dispositivos móviles suelen ser el client con más limitaciones de recursos. Si tu scene está dirigida a jugadores móviles, consulta también [Building for Mobile](/creator/content-creator-es/escenas-sdk7/desarrollar-para-movil/building-for-mobile.md) para obtener orientación específica para móvil.
{% endhint %}
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 fluidamente.
## Timing
### Reproducción de Video
Reproducir videos es una de las tareas más costosas para que la engine la maneje. Si tu scene incluye videos, asegúrate de que solo *UNO* VideoTexture esté en uso a la vez. Puedes tener docenas de planos compartiendo el mismo VideoTexture sin un impacto significativo en el rendimiento, pero en cuanto añades un segundo 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 según cuándo el jugador entra y sale.
{% hint style="info" %}
**💡 Consejo**: Un truco que varias scenes han usado es transmitir un solo video con múltiples regiones que se mapean de forma diferente a distintos planos. Cada pantalla de video usa [mapeo UV](/creator/content-creator-es/escenas-sdk7/conceptos-basicos-de-contenido-3d/materials.md#using-textures) para mostrar solo una parte distinta del VideoTexture. Gracias a esto, puede parecer que hay videos separados reproduciéndose sin el costo de múltiples VideoTextures.
{% endhint %}
{% hint style="info" %}
**💡 Consejo**: Cuando los jugadores están fuera de tu scene, los VideoTextures no se actualizan en cada frame. Esto ayuda a reducir el impacto en las scenes circundantes. No obstante, lo ideal es activar la reproducción de cualquier video solo cuando los jugadores [entran en tu scene](/creator/content-creator-es/escenas-sdk7/interactividad/event-listeners.md#player-enters-or-leaves-scene) .
{% endhint %}
### 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 región a medida que el jugador visita diferentes partes de la scene. Esto puede reducir significativamente el tiempo de carga de la scene, así como la cantidad de textures y contenido 3D que la 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 cargarían para cada jugador a medida que visita cada piso.
Consulta [esta scene de ejemplo](https://github.com/decentraland-scenes/lazy-loading) para ver cómo podría funcionar eso.
Para obtener el mejor resultado en cuanto a evitar tirones, oculta entities cambiando la propiedad `visible` de su shape a false. Con este enfoque, las añades a la engine al crearlas, pero simplemente no haces visibles sus modelos.
Una alternativa es no añadir las entities a la engine hasta que sean necesarias. Esto puede provocar algunos tirones cuando las entities aparecen por primera vez, y también podrían tardar un par de segundos en hacerse visibles. La ventaja de este enfoque es que es una forma válida de sortear las [limitaciones de la scene](/creator/content-creator-es/escenas-sdk7/optimizacion/scene-limitations.md). Ten en cuenta que el recuento de limitaciones de la scene corresponde al contenido que se está renderizando en la scene en un momento dado, no al contenido total que podría renderizarse. Cargar y descargar partes de la scene debería permitirte sortear esas limitaciones.
{% hint style="warning" %}
**📔 Nota**: Las entities que no son visibles pero se añaden a la engine sí cuentan para las limitaciones de la scene.
{% endhint %}
También puedes activar o desactivar las animaciones de entities que están lejos o ocluidas. Por ejemplo, para un NPC que reproduce una animación 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 en consecuencia.
{% hint style="info" %}
**💡 Consejo**: Cuando una entity está muy lejos y es lo suficientemente pequeña, la engine la descarta. Este descarte ayuda a nivel de drawcall; quitar entities de la engine siempre es mejor. Este descarte 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 todavía se renderizan.
{% endhint %}
### Bloques async
Bloques de [código async](/creator/content-creator-es/escenas-sdk7/patrones-de-programacion/async-functions.md) 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 que esperaba. Ten en cuenta que las scenes se ejecutan en un solo hilo, así que esto no es procesamiento paralelo; solo evita que la scene se detenga mientras espera respuestas externas.
Cualquier proceso que dependa de respuestas de servicios asíncronos, como `getPlayerData()` o `getRealm()` debería ejecutarse siempre en bloques async, ya que de lo contrario bloquea el resto de la carga de la scene mientras espera una respuesta. Lo mismo aplica a cualquier llamada a servidores de terceros.
Ten en cuenta que la scene se considerará completamente cargada cuando todo lo que no sea async haya terminado. Es posible que los procesos async sigan en ejecución cuando el jugador entre en la scene. Evita situaciones en las que un proceso async provoque la carga de una entity que potencialmente pueda dejar al jugador atrapado dentro de su geometría.
### Depender de Events
Intenta que la lógica de la scene dependa de escuchar [events](/creator/content-creator-es/escenas-sdk7/interactividad/event-listeners.md) en la medida de lo posible, en lugar de ejecutar comprobaciones en cada frame.
La `update()` función en un [system](/creator/content-creator-es/escenas-sdk7/arquitectura/systems.md) se ejecuta en cada frame, 30 veces por segundo (idealmente). Evita hacer comprobaciones recurrentes si puedes suscribirte a un event en su lugar.
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 tienes que 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 periodo que tenga sentido.
## Optimizar modelos 3D
Hay varias formas en las que tus modelos 3D pueden optimizarse para ser más ligeros.
Cuando trabajas con [Creator Hub](/creator/content-creator-es/scene-editor/empezar/editor-installation.md), puedes ver estadísticas sobre los recursos usados por los modelos 3D en tu scene, y si superan alguno de los [limitaciones de la scene](/creator/content-creator-es/escenas-sdk7/optimizacion/scene-limitations.md).
Puedes expandir 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 entre todos los modelos de la scene. Es mejor tener 1 textura compartida grande de 1024x1024 píxeles en lugar de varias pequeñas.
> Nota: Evita usar el mismo archivo de imagen tanto para la texture de 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 texture 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 textures exportando las textures como un archivo separado. Puedes tener lo mejor de ambos mundos usando el [siguiente flujo de trabajo](https://github.com/AnalyticalGraphicsInc/gltf-pipeline), que te permite tener *.glb* modelos con archivos de texture externos.
* Evita usar transparencias mezcladas. Las transparencias mezcladas tienen que saltarse bastantes de las optimizaciones de renderizado. Si es posible, prioriza la geometría opaca o con alpha testing.
* Evita usar skinned meshes. Pueden reducir el rendimiento significativamente.
{% hint style="info" %}
**💡 Consejo**: Lee más sobre buenas prácticas para modelos 3D en la \[Sección de 3D Modeling]\(/creator/3d-modeling/3d-models
{% endhint %}
### Backface Culling
Para la optimización del rendimiento, Backface Culling se establecerá en **On** en **todos** los Materials del modelo una vez renderizados en la engine, independientemente de sus ajustes.
Si esperas ver la cara posterior o el interior de tus modelos, duplica las caras e invierte las normals.
#### Solución de problemas
Para verificar si una scene tiene problemas con Backface Culling en Materials, sigue estos pasos:
1. Abre el `panel de depuración` en la scene.
* Si la scene está publicada, escribe el `/debug` comando en el chat.
* Si estás en modo Preview en la scene, haz clic en el icono de bug (
) ubicado en la esquina superior derecha de la pantalla.
2. El panel de depuración aparecerá en la esquina inferior derecha de la pantalla.
3. En **Current Scene**, haz clic en el botón **Backface debugger** .
4. Activa o desactiva **Force Backface Culling**: Muestra los Materials renderizados con Backface Culling activado. Este es el renderizado real una vez que la Optimization está en producción. Actívalo y desactívalo para detectar Materials que necesitan corrección.
5. Activa o desactiva el **Backface debugger** para detectar fácilmente los Materials que tienen Backface Culling desactivado. Resalta:
* **Rojo**: Materials que no tienen Backface Culling establecido en **On**.
* **Verde**: Materials con Backface Culling **On**.
Material con Backface Culling desactivado (izquierda) vs. 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 en cada scene recién desplegada al formato asset bundle. Este formato es *significativamente* más ligero, lo que hace que las scenes se carguen mucho más rápido y se ejecuten con más fluidez en el navegador.
{% hint style="info" %}
**💡 Consejo**: Cuando planifiques un evento en Decentraland, asegúrate de desplegar tu scene con un día de anticipación, para que para entonces todos los modelos se hayan convertido a asset bundles. 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.
{% endhint %}
{% hint style="warning" %}
**📔 Nota**: Si haces *cualquier* cambio en un archivo de modelo 3D, incluso si solo es un cambio de nombre, se considerará un archivo nuevo y deberá convertirse de nuevo al formato asset bundle.
{% endhint %}
## Conectividad
Si tu scene se conecta a servidores de terceros o usa el [messagebus](/creator/content-creator-es/escenas-sdk7/redes/serverless-multiplayer.md#send-explicit-messagebus-messages) para enviar mensajes entre jugadores, 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 son canalizadas por la engine para que solo se procese una a la vez. Cualquier solicitud adicional se pone en cola internamente y debe esperar hasta que otras solicitudes se completen. Este proceso de cola se gestiona automáticamente; no necesitas hacer nada.
* Cuando uses el [messagebus](/creator/content-creator-es/escenas-sdk7/redes/serverless-multiplayer.md#send-explicit-messagebus-messages) 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 server. Evita situaciones en las que un mensaje entrante provoque directamente el envío de otro mensaje, ya que la cantidad de mensajes puede crecer rápidamente de forma exponencial cuando hay mucha gente en la scene.
## UI de la Scene
Las UIs de la scene pueden volverse costosas de renderizar cuando están compuestas por muchos elementos individuales. Ten en cuenta que cada UI element requiere un drawcall separado en la engine.
{% hint style="info" %}
**💡 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 estén integrados en la imagen de fondo. Eso evita que la engine haga un drawcall adicional por frame para cada elemento de texto.
{% endhint %}
Evita hacer ajustes en la UI en cada frame; eso es especialmente costoso y puede acabar quedando 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 una 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; estos también afectan al rendimiento incluso si no se están renderizando. Cuando sea posible, intenta crear UI components bajo demanda.
## Terreno del paisaje en Worlds
Las scenes publicadas en un [Decentraland World](https://github.com/decentraland/docs/tree/main/creator/worlds/about.md) están rodeadas por un paisaje autogenerado 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](/creator/content-creator-es/escenas-sdk7/tipos-de-proyectos/scene-metadata.md#landscape-terrain) en tu `scene.json` para liberar esos recursos para el propio contenido de tu scene.
## Monitorizar el rendimiento
La mejor métrica para saber qué tan bien se está ejecutando una scene es el FPS (Frames Per Second). En Preview, puedes ver los FPS actuales de la scene en el panel de depuración. Deberías procurar tener siempre 30 FPS o más.
En la scene desplegada, puedes activar o desactivar el panel que muestra estas métricas escribiendo `/showfps` en la ventana del 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 la engine.
Cuando ejecutes una scene en Preview, fíjate en 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 la engine, notarás que aumenta el número de ‘Processed Messages’. Debes vigilar de cerca el número de ‘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 recuento de ‘Pending on Queue’ empieza a crecer, entonces has entrado en la zona de peligro y deberías pensar en hacer más optimizaciones a tu scene.
{% hint style="warning" %}
**📔 Nota**: No mantengas el panel abierto cuando no lo estés usando, ya que tiene un impacto negativo en el rendimiento.
{% endhint %}
Ten en cuenta que el rendimiento que experimentes 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 podrían estar ejecutándose en hardware menos potente
Siempre es una buena práctica intentar desplegar primero tu scene en el [entorno de prueba](/creator/content-creator-es/escenas-sdk7/publicacion/publishing.md#the-test-server) para realizar pruebas más exhaustivas.
Pide siempre feedback a los jugadores. Nunca des por sentado que la forma en que tú experimentas la scene es la misma para todos los demás.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.decentraland.org/creator/content-creator-es/escenas-sdk7/optimizacion/performance-optimization.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.