> 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 escenas para garantizar la mejor experiencia posible para los jugadores que las visitan. Este documento cubre algunas prácticas recomendadas que pueden marcar una gran diferencia en la velocidad con la que se carga tu escena y en lo fluida 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 jugar, a través del navegador o desde la [aplicación móvil](/creator/content-creator-es/desarrollar-para-movil/cliente-movil/overview.md) en un teléfono — todo lo cual limita cuánta capacidad de procesamiento está disponible para tu escena. La experiencia de visitar tu escena debe ser fluida para todos. {% embed url="" %} Consulta [Recursos útiles](/creator/content-creator-es/escenas-sdk7/primeros-pasos/useful-resources.md) para encontrar herramientas que pueden ayudar, como Decentraland Scene Optimizer, que extrae, deduplica y comprime las texturas de los modelos 3D de tu escena. {% hint style="info" %} **📱 Móvil**: Los dispositivos móviles suelen ser el cliente con más restricciones de recursos. Si tu escena está dirigida a jugadores móviles, consulta también [Desarrollo para Mobile](/creator/content-creator-es/desarrollar-para-movil/cliente-movil/overview.md) para obtener orientación específica para móvil. {% endhint %} Explorer aplica muchas optimizaciones a nivel de engine. Estas optimizaciones marcan una gran diferencia, pero el reto de renderizar múltiples experiencias generadas por usuarios simultáneamente en un navegador es enorme. Necesitamos tu ayuda para que todo funcione con fluidez. ## Tiempo ### Reproducción de video Reproducir videos es una de las tareas más costosas que el engine debe manejar. Si tu escena incluye videos, asegúrate de que solo *UN* VideoTexture esté en uso a la vez. Puedes tener docenas de planos compartiendo la misma VideoTexture sin un impacto significativo en el rendimiento, pero en cuanto agregas una segunda VideoTexture, sus efectos en la tasa de fotogramas se vuelven muy notorios. También deberías evitar que los videos se reproduzcan en regiones donde no puedan 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. {% hint style="info" %} **💡 Consejo**: Un truco que han usado varias escenas es transmitir un solo video con múltiples regiones que se mapean de forma distinta en diferentes planos. Cada pantalla de video usa [mapeo UV](/creator/content-creator-es/escenas-sdk7/fundamentos-del-contenido-3d/materials.md#using-textures) para mostrar solo una parte distinta de la VideoTexture. Gracias a esto, puede parecer que se reproducen videos separados sin el coste de múltiples VideoTextures. {% endhint %} {% hint style="info" %} **💡 Consejo**: Cuando los jugadores están fuera de tu escena, las VideoTextures no se actualizan en cada frame. Esto ayuda a reducir el impacto en las escenas circundantes. Aun así, lo ideal es activar la reproducción de cualquier video solo cuando los jugadores [entran en tu escena](/creator/content-creator-es/escenas-sdk7/interactividad/event-listeners.md#player-enters-or-leaves-scene) . {% endhint %} ### Carga diferida Si tu escena es grande, o tiene áreas interiores que no siempre son visibles, puedes optar por no cargar desde el principio todo el conjunto de entidades. En su lugar, carga el contenido por región a medida que el jugador visita distintas 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 los cuadros de cada piso solo se cargarían para cada jugador a medida que visitan cada piso. Consulta [esta escena de ejemplo](https://github.com/decentraland-scenes/lazy-loading) para ver cómo podría funcionar. Para obtener el mejor resultado y evitar tirones, oculta las 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. `visible` propiedad a false. Con este enfoque, las agregas al engine al crearlas, pero simplemente no haces visibles sus modelos. Una alternativa es no agregar las entidades al engine hasta que sean necesarias. Esto puede provocar algunos tirones cuando las entidades 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 los [límites de la escena](/creator/content-creator-es/escenas-sdk7/optimizacion/scene-limitations.md). Ten en cuenta que el conteo de límites de la escena se refiere al contenido que se está renderizando en la escena en un momento dado, no al contenido total que podría renderizarse. Cargar y descargar partes de la escena debería permitirte trabajar alrededor de esas limitaciones. {% hint style="warning" %} **📔 Nota**: Las entidades que no son visibles pero se agregan al engine sí cuentan para los límites de la escena. {% endhint %} También puedes activar o desactivar las animaciones de entidades que estén lejos o ocultas. Por ejemplo, para un NPC que reproduce una animación de inactividad 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 entidad está lejos y es lo suficientemente pequeña, el engine la descarta. Este descarte ayuda a nivel de drawcall; eliminar entidades del engine siempre es mejor. Este descarte tampoco tiene en cuenta la oclusión por otras entidades, por lo que las entidades que no son tan pequeñas pero están ocultas por una pared siguen renderizándose. {% 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 escena sigue ejecutándose y el bloque async se reanuda cuando llega la respuesta esperada. Ten en cuenta que las escenas se ejecutan en un solo hilo, así que esto no es procesamiento paralelo, solo evita que la escena 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 bloquearían el resto de la carga de la escena mientras esperan una respuesta. Lo mismo se aplica a cualquier llamada a servidores de terceros. Ten en cuenta que la escena se considerará completamente cargada cuando termine todo lo que no sea async. Los procesos async aún podrían seguir ejecutándose cuando el jugador entre en la escena. Evita situaciones en las que un proceso async dé lugar a la carga de una entidad que podría dejar al jugador atrapado dentro de su geometría. ### Apóyate en Events Intenta que la lógica de la escena dependa de escuchar [eventos](/creator/content-creator-es/escenas-sdk7/interactividad/event-listeners.md) todo lo posible, en lugar de ejecutar comprobaciones en cada frame. La `update()` función en un [sistema](/creator/content-creator-es/escenas-sdk7/arquitectura/systems.md) se ejecuta en cada frame, 30 veces por segundo (idealmente). Evita hacer comprobaciones recurrentes si en su lugar puedes suscribirte a un evento. 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 sistema, 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 modelos 3D Hay varias formas de optimizar tus modelos 3D para que sean más ligeros. Al trabajar con el [Creator Hub](/creator/content-creator-es/scene-editor/comenzar/editor-installation.md), puedes ver estadísticas sobre los recursos que usan los modelos 3D en tu escena y si superan alguno de los [límites de la escena](/creator/content-creator-es/escenas-sdk7/optimizacion/scene-limitations.md). ![](/files/3db673799260cb8b4b83e8bb2d80a100b66d2a75) Puedes desplegar este menú para ver los detalles. ![](/files/034662b6a589ac95d6c913def6c58c855c604f0f) Aquí tienes algunos consejos para mejorar estas métricas: * Cuando sea posible, comparte texturas entre modelos 3D. Una buena práctica es usar una sola textura como atlas, compartida por todos los modelos de la escena. Es mejor tener 1 textura 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 exportándolas como un archivo separado. Puedes obtener 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 textura externos. * Evita usar transparencias mezcladas. Las transparencias mezcladas tienen que saltarse bastantes optimizaciones de renderizado. Si es posible, prioriza geometría opaca o con alpha test. * Evita los skinned meshes. Pueden reducir significativamente el rendimiento. {% hint style="info" %} **💡 Consejo**: Lee más sobre las prácticas recomendadas para modelos 3D en la \[Sección de 3D Modeling]\(/creator/3d-modeling/3d-models {% endhint %} ### Reutilizar el mismo modelo muchas veces Las escenas suelen estar llenas de contenido repetido: farolas a lo largo de una calle, sillas en una habitación, árboles en un parque. La mejor manera de construir esto es la más simple — **darle a cada copia su propia entidad y apuntarlas todas al mismo *****.glb***** archivo.** ```ts // BIEN: un archivo, muchas entidades for (const position of lampPostPositions) { const lampPost = engine.addEntity() Transform.create(lampPost, { position }) GltfContainer.create(lampPost, { src: 'assets/scene/lampPost.glb' }) } ``` El engine reconoce que estas entidades comparten una fuente. El archivo se descarga una sola vez, se convierte una sola vez a asset bundle, y sus Meshes y Textures se mantienen en memoria una sola vez — la vigésima farola apenas cuesta nada más allá de su propia posición en el mundo. Esto también funciona entre escenas: si una escena vecina usa el mismo archivo, ya está en memoria. Exportar veinte *.glb* archivos casi idénticos significa veinte descargas y veinte copias en memoria. Lo que esto **no** ahorra son draw calls. Veinte farolas son veinte objetos que dibujar, ya vengan de veinte entidades o de un solo *.glb* que contiene veinte farolas modeladas en él. La única forma de reducir ese conteo es unir los Meshes en tu herramienta de modelado, lo cual supone un verdadero compromiso — consulta [Instancing vs Duplicating vs Merging](/creator/content-creator-es/modelado-3d-y-animaciones/meshes.md#instancing-objects-vs-duplicating-objects) para saber cuándo vale la pena. Algunos consejos relacionados: * **Agrupa en clústeres en lugar de usar un solo modelo gigante.** Si tienes muchos props dispersos, un buen punto intermedio es uno *.glb* por grupo — un tramo de una calle, el mobiliario de una habitación — en lugar de un modelo por prop o un modelo para toda la escena. Reduces el número de objetos al mismo tiempo que mantienes cada clúster lo bastante pequeño como para que el culling siga siendo útil. * **¿Generar muchas copias a la vez?** Precarga primero el modelo con el [`AssetLoad` componente](/creator/content-creator-es/escenas-sdk7/optimizacion/pre-load-resources.md). Las copias se crean entonces a partir de un modelo que ya está en memoria, en lugar de que cada una espere la misma descarga. Construir cada copia sigue requiriendo trabajo, así que un gran pico puede costarte un frame de todas formas — la precarga elimina la espera del archivo, no el coste de crear las copias. * **Un modelo muy grande exige más al engine que muchos pequeños.** El engine reparte el trabajo de construir tu escena entre varios frames para evitar tirones, pero no puede dividir un único modelo enorme — eso cae en un solo frame. Muchas piezas pequeñas se cargan de forma fluida; una pieza monolítica tiene más probabilidades de causar un tirón visible. * **Repetir un modelo no introduce nuevas texturas ni geometría.** Veinte farolas construidas a partir de un solo modelo comparten los Meshes y Textures de ese modelo en lugar de añadir al conjunto — la vigésima no cuesta nada en memoria de texturas. Los Materials son la excepción: el engine crea una instancia de material por objeto renderizado para aplicar el recorte de límites de tu escena, así que el conteo de materiales sigue el número de objetos que renderizas, no el número de modelos que usas. Esas instancias siguen compartiendo las mismas texturas y variantes de shader, por lo que consumen un poco de memoria en lugar de tiempo de frame. Lo que acerca una escena al [límite](/creator/content-creator-es/escenas-sdk7/optimizacion/scene-limitations.md) es tener muchos *diferentes* modelos, cada uno con su propio conjunto personalizado — así que consolidar tu escena en torno a una biblioteca más pequeña de modelos reutilizados ayuda en ese aspecto. ### Backface Culling Para optimizar el rendimiento, Backface Culling se establecerá en **On** en **todas las** Materiales del modelo una vez renderizados en el engine, independientemente de sus ajustes. Si esperas ver la cara posterior o el interior de tus modelos, duplica las caras e invierte las normales. #### Solución de problemas Para verificar si una escena tiene problemas de Backface Culling en los Materials, sigue estos pasos: 1. Abre el `debug` panel en la escena. * Si la escena está publicada, escribe el `/debug` comando en el chat. * Si estás en modo Preview en la escena., haz clic en el icono de Bug ( icono de debug ) ubicado en la esquina superior derecha de la pantalla. 2. El panel de debug aparecerá en la esquina inferior derecha de la pantalla. 3. Debajo de **Current Scene**, haz clic en el **Backface debugger** botón. ![](/files/06ede3a4ba590b0c7cd220c5026a082f0b471b98) 4. Activa **Force Backface Culling**: Muestra los materiales renderizados con Backface Culling activado. Este es el renderizado real una vez que la optimización esté en producción. Alterna On y Off para detectar los materiales que necesitan corrección. 5. Activa **Backface debugger** para detectar fácilmente los materiales que tienen Backface Culling desactivado. Resalta: * **Rojo**: Materiales que no tienen Backface Culling configurado en **On**. * **Verde**: Materiales con Backface Culling **On**.


Material con Backface Culling desactivado (izquierda) vs. Backface Culling activado (derecha)

### Conversión a asset bundle Cada vez que publicas una escena, los content servers de Decentraland comprimen cada *.gltf* y *.glb* modelo en ella al formato asset bundle. Este formato es *significativamente* más ligero, lo que hace que las escenas carguen mucho más rápido y se ejecuten con mayor fluidez. La conversión comienza inmediatamente después de cada deployment. Suele tardar unos 15 minutos, pero calcula entre 30 y 60 minutos hasta que la escena convertida sea jugable de forma fiable para todos, ya que la conversión se ejecuta por separado para cada plataforma y puede quedar en cola detrás de otras escenas. Puedes [comprobar el estado de la conversión](/creator/content-creator-es/scene-editor/publicar/publish-scene.md#check-the-conversion-status) de tu escena directamente. También puedes ejecutar esta misma conversión localmente mientras desarrollas tu escena. Esto hace que tu Preview sea más fluido y te permite comprobar cualquier problema con los modelos comprimidos antes de publicar. Consulta [Preview con assets optimizados](/creator/content-creator-es/escenas-sdk7/primeros-pasos/preview-scene.md#preview-with-optimized-assets). {% hint style="info" %} **💡 Consejo**: Cuando planifiques un evento en Decentraland, publica tu versión final con al menos 2 horas de antelación, para que así todos los modelos ya estén convertidos a asset bundles para entonces. Si no quieres arruinar la sorpresa antes del evento, puedes hacer deploy de una versión de tu escena que incluya todos los modelos 3D finales en la carpeta del proyecto, pero en la que no sean visibles o en la que su tamaño esté establecido en 0. {% endhint %} {% hint style="warning" %} **📔 Nota**: Si haces *cualquier* cambio en un archivo de modelo 3D, aunque solo sea un cambio de nombre, se considerará un archivo nuevo y deberá convertirse de nuevo al formato asset bundle. {% endhint %} ## Conectividad Si tu escena se conecta a servidores de terceros o usa el [messagebus](/creator/content-creator-es/escenas-sdk7/networking/serverless-multiplayer.md#send-explicit-messagebus-messages) para enviar mensajes entre jugadores, también hay algunas cosas que quizá quieras tener en cuenta. * Tu escena solo debería tener una conexión activa de WebSockets a la vez. * Las llamadas HTTP se canalizan a través del engine para que solo se gestione una 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. * Al usar el [messagebus](/creator/content-creator-es/escenas-sdk7/networking/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 de la isla del servidor. 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 con rapidez cuando hay mucha gente en la escena. ## UI de la escena Las UI de la escena pueden ser 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. {% hint style="info" %} **💡 Consejo**: Intenta fusionar 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 mosaicos y cualquier imagen adicional queden integrados en la imagen de fondo. Eso evita que el engine haga un drawcall adicional por frame por cada elemento de texto. {% endhint %} Evita hacer ajustes a la UI en cada frame; eso es especialmente costoso y puede terminar en cola. Por ejemplo, si hay una barra de salud en tu UI que debe reducirse con el tiempo, probablemente los jugadores no notarían diferencia entre que se actualice a 10 FPS en lugar de a 30 FPS (en cada frame). El sistema que actualiza esta barra puede usar un temporizador breve que cuente 100 milisegundos y afectar la UI solo 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 de paisaje en Worlds Las escenas publicadas en un [Decentraland World](https://github.com/decentraland/docs/tree/main/creator/worlds/about.md) están rodeadas por un paisaje autogenerado de pradera, árboles y mar. Renderizar este paisaje consume parte del presupuesto de renderizado del jugador. Si tu escena 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 contenido de tu propia escena. ## 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 los FPS actuales de la escena en el panel de depuración. Deberías intentar tener siempre 30 FPS o más. En la escena desplegada, puedes activar o desactivar el panel que muestra estas métricas escribiendo `/showfps` en la ventana de chat. ### panel de Scene Stats Al ejecutar una escena en Preview en el cliente de escritorio, puedes abrir un panel que muestra estadísticas en vivo sobre el contenido de tu escena. Haz clic en el icono de estadísticas en la esquina superior derecha de la pantalla, junto a los iconos de la consola y de debug. panel de Scene Stats El panel contabiliza los triángulos, entidades, cuerpos y texturas de la escena frente a sus límites, mostrando qué porcentaje de cada presupuesto está en uso. Un valor se vuelve naranja cuando alcanza el 80% de su límite. También muestra conteos simples de materiales, geometrías, colliders y videos o audios externos. Pasa el cursor sobre el icono de información junto a cada métrica para ver una explicación de qué cuenta y por qué importa. Los números se actualizan en tiempo real a medida que el contenido se carga y se descarga, lo que hace que el panel sea útil para comprobar cómo estrategias como [carga diferida](#lazy-loading) afectan a lo que el engine está manejando realmente en cada momento. Consulta [límites de la escena](/creator/content-creator-es/escenas-sdk7/optimizacion/scene-limitations.md) para conocer los detalles de cada límite. Ten en cuenta que estos son límites blandos: superar uno no bloqueará tu escena, pero puede degradar el rendimiento para los jugadores. ### Mensajes entre la escena y el engine 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 ejecutes una escena 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 de ‘Processed Messages’ crece. 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 fueron enviados a una cola. Si el ‘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 escena. {% 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 escenas vecinas circundantes podrían tener un impacto negativo * La compresión de los modelos 3D de las escenas a asset bundles puede tener un impacto positivo * Algunos jugadores que visiten tu escena pueden estar usando hardware menos potente Siempre es una buena práctica intentar hacer deploy de tu escena primero a un [Decentraland World](/creator/content-creator-es/escenas-sdk7/publicacion/publishing-options.md#decentraland-worlds) para hacer pruebas más exhaustivas. Pide siempre feedback a los jugadores. Nunca des por sentado que la forma en que tú experimentas la escena es la misma para todos los demás. ## Optimiza con IA Un agente de IA puede encargarse por ti de gran parte de las mediciones y correcciones descritas en esta página. Decentraland proporciona [habilidades de IA](/creator/content-creator-es/escenas-sdk7/primeros-pasos/vibe-coding.md#install-skills-for-any-ai-agent) que enseñan a los agentes de programación (como Claude Code o Cursor) cómo optimizar escenas, y el cliente de escritorio incluye un [servidor MCP](/creator/content-creator-es/escenas-sdk7/primeros-pasos/vibe-coding.md#let-the-ai-see-your-scene-in-world) que permite al agente inspeccionar y medir directamente tu escena en ejecución. Con las `optimize-scene` y `unity-explorer-mcp` habilidades instaladas y el servidor MCP conectado, un agente puede: * **Comprobar la escena frente a sus presupuestos de contenido**: lee las mismas estadísticas en vivo que el panel de Scene Stats y las compara con los [límites de la escena](/creator/content-creator-es/escenas-sdk7/optimizacion/scene-limitations.md), así que puede decirte qué presupuesto se está quedando corto. * **Encontrar los assets responsables**: clasifica los modelos 3D de tu escena según cuántos triángulos, materiales y draw calls aporta cada uno, incluyendo lo que es visible desde un punto de vista específico, de modo que sabe exactamente qué modelos optimizar primero. * **Medir la tasa de fotogramas real**: sitúa al jugador en cualquier punto de la escena y toma muestras del FPS que realmente experimenta allí, incluidos los tirones momentáneos. * **Verificar su propio trabajo**: después de cada cambio puede volver a medir, de modo que sus recomendaciones y correcciones están respaldadas por números reales en lugar de suposiciones. Esto convierte la optimización en algo que puedes pedir simplemente: > "Comprueba si mi escena está dentro de los límites, encuentra lo que esté bajando la tasa de fotogramas cerca del spawn point, arréglalo y muéstrame los números antes y después." ### Combínalo con el servidor MCP de Blender Las herramientas de Decentraland le indican al agente cuáles son los modelos más pesados, pero no editan los modelos en sí. Para ir más allá, puedes intentar combinarlas con el [servidor MCP de Blender](https://www.blender.org/lab/mcp-server/), que le da al agente acceso a las herramientas de edición de Blender. Esto permite al agente abrir un modelo pesado en Blender, reducir su conteo de triángulos, fusionar sus materiales o reducir el tamaño de sus texturas, y exportar el resultado de vuelta a la escena como un `.glb` archivo, donde luego puede volver a medir la tasa de fotogramas en el mundo. Ten en cuenta que las ediciones automatizadas de Mesh pueden cambiar visiblemente el aspecto de un modelo, así que revisa siempre los resultados y conserva copias de seguridad de tus archivos originales. --- # 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.