> 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/scenes-sdk7/optimizacion/performance-optimization.md). # 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 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 lo rápido que 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á pensado para juegos, a través del navegador o desde el [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 debería ser fluida para todos. {% embed url="" %} Echa un vistazo a [Recursos útiles](/creator/content-creator-es/scenes-sdk7/primeros-pasos/useful-resources.md) para herramientas que pueden ayudar, como el Decentraland Scene Optimizer, que extrae, deduplica y comprime texturas de los modelos 3D de tu escena. {% hint style="info" %} **📱 Móvil**: Los dispositivos móviles suelen ser el cliente con menos recursos disponibles. Si tu escena apunta a jugadores móviles, consulta también [Building for Mobile](/creator/content-creator-es/desarrollar-para-movil/cliente-movil/overview.md) para orientación específica para móviles. {% endhint %} El Explorer de Decentraland impone 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 grande. Necesitamos tu ayuda para que todo funcione sin problemas. ## Tiempo ### Video playing Reproducir videos es una de las cosas más costosas para que el engine las gestione. Si tu escena incluye videos, asegúrate de que solo *UNO* VideoTexture se esté usando a la vez. Puedes tener docenas de planos 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 notables. También deberías evitar tener videos reproduciéndose en regiones donde no pueden verse. Por ejemplo, si tienes una pantalla en interiores, activa y 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 a diferentes planos. Cada pantalla de video usa [UV mapping](/creator/content-creator-es/scenes-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 están reproduciendo 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 para las escenas vecinas. Aun así, lo ideal es activar la reproducción de cualquier video solo cuando los jugadores [entran en tu escena](/creator/content-creator-es/scenes-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 elegir 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 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 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 visitan cada piso. Consulta [esta escena de ejemplo](https://github.com/decentraland-scenes/lazy-loading) para ver cómo podría funcionar eso. Para obtener el mejor resultado en términos de evitar tirones, oculta entities cambiando la propiedad `visibles` de su shape a false. Con este enfoque, las añades al engine al crearlas, 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 el [limitaciones de la escena](/creator/content-creator-es/scenes-sdk7/optimizacion/scene-limitations.md). 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 trabajar alrededor de esas limitaciones. {% hint style="warning" %} **📔 Nota**: Las entities que no son visibles pero se añaden al engine sí cuentan para las limitaciones de la escena. {% endhint %} También puedes activar o desactivar animaciones para 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 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á lejos y lo bastante pequeña, el engine la descarta. Este descarte ayuda a nivel de drawcall; eliminar entities del 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 siguen renderizándose. {% endhint %} ### Bloques async Bloques de [código async](/creator/content-creator-es/scenes-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 que esperaba. Ten en cuenta que las escenas se ejecutan en un solo thread, así que esto no es procesamiento en paralelo, solo evita que la escena se quede detenida 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 escena mientras espera una respuesta. Lo mismo aplica a cualquier llamada a servidores de terceros. Ten en cuenta que la escena se considerará completamente cargada cuando todo lo que no sea async haya terminado. Puede que los procesos async sigan ejecutándose cuando el jugador entre en la escena. Evita situaciones en las que un proceso async resulte en la carga de una entity que potencialmente pueda dejar al jugador atrapado dentro de su geometría. ### Apóyate en Events Intenta que la lógica de la escena se base en escuchar [Events](/creator/content-creator-es/scenes-sdk7/interactividad/event-listeners.md) todo lo posible, en lugar de ejecutar comprobaciones en cada frame. El `update()` function en un [system](/creator/content-creator-es/scenes-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 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 dentro 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 en las que tus modelos 3D pueden optimizarse para ser más ligeros. Al trabajar con el [Creator Hub](/creator/content-creator-es/scene-editor/primeros-pasos/editor-installation.md), puedes ver estadísticas sobre los recursos usados por los modelos 3D en tu escena, y si superan alguno de los [limitaciones de la escena](/creator/content-creator-es/scenes-sdk7/optimizacion/scene-limitations.md). ![](https://1216664193-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FoPnXBby9S6MrsW83Y9qZ%2Fuploads%2Fgit-blob-88f68a93b0cfcb7f8c48270f31ba7137655ee2e1%2Ftriangle-limit1.png?alt=media\&token=6ba1a8ad-a1e4-472b-b9ca-a3b9d1aab9d8) Puedes expandir este menú para ver detalles. ![](https://1216664193-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FoPnXBby9S6MrsW83Y9qZ%2Fuploads%2Fgit-blob-aebaad725f1d9397552b2fb36a318eec91589b9c%2Ftriangle-limit2.png?alt=media\&token=65973f60-8eda-4193-9a81-f5a42d4c5032) 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 map, compartida entre todos los modelos de la escena. 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 textura albedo como para el normal map o el emissive map de un material. Usa archivos separados, incluso si son idénticos. Asignar el mismo archivo de imagen a distintos tipos de propiedades de texture 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](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 omitir bastantes de las optimizaciones de renderizado. Si es posible, prioriza geometría opaca o con alpha tested. * Evita usar skinned meshes. Pueden reducir el rendimiento de forma significativa. {% hint style="info" %} **💡 Consejo**: Lee más sobre las mejores prácticas para modelos 3D en la \[sección de modelado 3D]\(/creator/3d-modeling/3d-models {% endhint %} ### Rescatar un modelo pesado en Blender Cuando las estadísticas señalan un modelo concreto, normalmente es más rápido arreglar el modelo que trabajar alrededor de él en código. Las ediciones más útiles, en Blender o una herramienta similar: * **Reducir el recuento de triángulos** con el modificador Decimate. Esta es una herramienta de rescate para modelos que ya tienes. Los modelos nuevos se modelan mejor en low-poly desde el inicio. * **Redimensionar las texturas** a una potencia de dos, 1024x1024 o menor, y reorganizarlas en el *.glb*. * **Eliminar las caras que el jugador nunca ve**, como la parte inferior y la trasera de los props. Activa [back-face culling](#backface-culling) en lugar de duplicar la geometría. * **Combinar materials** en uno, usando una sola textura atlas en lugar de una textura por parte. * **Elimina luces, cámaras y materials de `_collider` meshes.** El engine los ignora, así que son puro peso. Comprueba el recuento de triángulos y el recuento de materiales antes y después, luego exporta de nuevo sobre el mismo archivo. Si hay una preview en ejecución, se recarga con tus cambios. ### 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 entity, y apuntarlas a todas al mismo *****.glb***** thumbnail.png.** ```ts // BIEN: un archivo, muchas entities 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 entities comparten una fuente. El archivo se descarga una vez, se convierte a asset bundle una vez, y sus meshes y textures se mantienen en memoria una vez — la vigésima farola cuesta casi 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, en cambio, significa veinte descargas y veinte copias en memoria. Lo que esto **no** ahorra son draw calls. Veinte farolas son veinte objetos que dibujar, vengan de veinte entities o de un solo *.glb* que contiene veinte farolas modeladas en él. La única forma de reducir ese recuento es unir los meshes en tu herramienta de modelado, lo cual supone una auténtica compensación — mira [Instancing vs Duplicating vs Merging](/creator/content-creator-es/modelado-y-animaciones-3d/meshes.md#instancing-objects-vs-duplicating-objects) para saber cuándo vale la pena. Algunos consejos relacionados: * **Agrupa en clústeres en lugar de en un modelo gigantesco.** Si tienes muchos props dispersos, un buen punto intermedio es uno *.glb* por grupo — un bloque 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 mientras mantienes cada clúster lo bastante pequeño para que el culling siga siendo útil. * **¿Vas a crear muchas copias a la vez?** Precarga primero el modelo con el [`AssetLoad` component](/creator/content-creator-es/scenes-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 una gran ráfaga puede costarte un frame de todos modos — la precarga elimina la espera del archivo, no el coste de crear las copias. * **Un solo modelo muy grande le exige más al engine que muchos pequeños.** El engine reparte el trabajo de construir tu escena entre frames para evitar tirones, pero no puede dividir un solo modelo enorme — eso cae en un frame. Muchas piezas pequeñas se cargan de forma fluida; una pieza monolítica tiene más probabilidades de provocar un tirón visible. * **Repetir un modelo no introduce nuevas texturas ni geometría.** Veinte farolas construidas a partir de un modelo comparten los meshes y textures de ese modelo en lugar de añadir más 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 clipping de límites de tu escena, así que el recuento de materials sigue el número de objetos que renderizas, no el número de modelos que usas. Esas instancias siguen compartiendo las mismas textures y variantes de shader, así que cuestan un poco de memoria en lugar de tiempo de frame. Lo que empuja a una escena contra el [límite](/creator/content-creator-es/scenes-sdk7/optimizacion/scene-limitations.md) es tener muchos *modelos* diferentes, cada uno con su propio conjunto a medida — así que consolidar tu escena en torno a una biblioteca más pequeña de modelos reutilizados ayuda en ese sentido. ### Backface Culling Para optimizar el rendimiento, Backface Culling se establecerá en **On** en **todos** en los materials del modelo una vez renderizado en el engine, independientemente de sus ajustes. Si esperas ver la parte trasera o el interior de tus modelos, duplica las caras e invierte las normals. #### Solución de problemas Para verificar si una escena tiene problemas de Backface Culling en materials, sigue estos pasos: 1. Abre el `panel de` debug * Si la escena está publicada, escribe `/debug` comando en el chat. * Si estás en modo Preview de 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. Bajo **Escena actual**, haz clic en el **debugger de Backface** botón. ![](https://1216664193-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FoPnXBby9S6MrsW83Y9qZ%2Fuploads%2Fgit-blob-94f40725793fcbf697f6386ad6c6249ca681381c%2Fdebug-panel-backface-debugging.png?alt=media\&token=e41f8a8a-1115-4a8b-b0e9-d4016a74da21) 4. Alternar **Forzar Backface Culling**: Muestra los materials renderizados con Backface Culling activado. Este es el renderizado real una vez que la Optimización esté en producción. Alterna entre On y Off para detectar materials que necesiten corrección. 5. Activa y desactiva el **debugger de Backface** para detectar fácilmente los materials que tienen Backface Culling desactivado. Resalta: * **Rojo**: Materials que no tienen Backface Culling configurado en **On**. * **Verde**: Materials 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 servidores de contenido 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 más fluidez. La conversión comienza inmediatamente después de cada deployment. Normalmente tarda solo unos segundos, aunque puede tardar más en escenas muy grandes o cuando los servidores están ocupados, 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 fluida y te permite comprobar cualquier problema con los modelos comprimidos antes de publicar. Consulta [Previsualizar con assets optimizados](/creator/content-creator-es/scenes-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 al menos una hora antes, para que los modelos ya se hayan convertido a asset bundles para entonces y tengas tiempo de corregir cualquier imprevisto. 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 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* un 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 escena se conecta a servidores de terceros o usa el [messagebus](/creator/content-creator-es/scenes-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 WebSockets activa a la vez. * Las llamadas HTTP son canalizadas por el engine para que solo se gestione una a la vez. Cualquier solicitud adicional se pone en cola internamente y debe esperar hasta que se completen las demás solicitudes. Este proceso de cola se gestiona automáticamente; no necesitas hacer nada. * Cuando usas el [messagebus](/creator/content-creator-es/scenes-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 resulte directamente en el envío de otro mensaje, ya que la cantidad de mensajes puede crecer exponencialmente cuando hay mucha gente en la escena. ## UI de la escena Las UIs de la 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. {% 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 tener el texto de las tiles y cualquier imagen adicional integrada 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 acabar quedando en cola. Por ejemplo, si hay una barra de vida en tu UI que debería reducirse a lo largo del 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 System que actualiza esta barra puede usar un temporizador breve que cuente 100 milisegundos y solo afectar a la UI cuando este temporizador llegue a 0. Evita tener muchos elementos de UI ocultos; estos también tienen efecto en el rendimiento incluso si no se están renderizando. Cuando sea posible, intenta crear los componentes de UI bajo demanda. ## El terreno paisajístico en Worlds Las escenas publicadas en un [Decentraland World](https://github.com/decentraland/docs/tree/main/creator/worlds/about.md) está rodeado por un paisaje autogenerado de praderas, árboles y mar. Renderizar este paisaje consume parte del presupuesto de renderizado del jugador. Si tu escena no lo necesita, puedes [desactivar el terreno paisajístico](/creator/content-creator-es/scenes-sdk7/tipos-de-proyectos/scene-metadata.md#landscape-terrain) en tu `scene.json` para liberar esos recursos para el contenido propio de tu escena. ## Monitorizar el rendimiento La mejor métrica para saber qué tal rinde una escena es el FPS (Frames Per Second). En preview, puedes ver el FPS actual de la escena en el panel de debug. Deberías procurar tener siempre 30 FPS o más. En la escena desplegada, puedes activar y desactivar el panel que muestra estas métricas escribiendo `/showfps` en la ventana de chat. ### Panel de Scene Stats Cuando ejecutas 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 consola y debug. Panel de Scene Stats El panel cuenta los triángulos, entities, bodies y textures de la escena frente a sus límites, mostrando qué porcentaje de cada presupuesto se está usando. Un valor se vuelve naranja cuando alcanza el 80% de su límite. También muestra recuentos simples de materials, geometries, 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 descarga, lo que hace que el panel sea útil para comprobar cómo estrategias como [lazy loading](#lazy-loading) afectan a lo que el engine está gestionando realmente en cada momento. Consulta [limitaciones de la escena](/creator/content-creator-es/scenes-sdk7/optimizacion/scene-limitations.md) para obtener detalles sobre cada límite. Ten en cuenta que estos son límites blandos: superarlos no bloqueará tu escena, pero sí 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 ejecutas 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’ aumenta. 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 pasaron 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 aplicar más optimizaciones a 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 experimentas en preview puede diferir del de producción: * Las escenas vecinas alrededor pueden 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 visitan tu escena pueden estar ejecutándola en hardware menos potente Siempre es una buena práctica intentar desplegar primero tu escena en un [Decentraland World](/creator/content-creator-es/scenes-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 experimentas la escena es la misma para todos los demás. ## Optimizar con IA Un agente de IA puede encargarse de gran parte de la medición y la corrección descritas en esta página por ti. Decentraland proporciona [Habilidades de IA](/creator/content-creator-es/scenes-sdk7/primeros-pasos/vibe-coding.md#install-skills-for-any-ai-agent) skills que enseñan a agentes de código (como Claude Code o Cursor) a optimizar escenas, y el cliente de escritorio incluye un [MCP server](/creator/content-creator-es/scenes-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` skills 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 Scene Stats y las compara con los [limitaciones de la escena](/creator/content-creator-es/scenes-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, incluido lo que es visible desde un punto de vista específico, para que sepa exactamente qué modelos optimizar primero. * **Medir la tasa de frames real**: coloca 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, así sus recomendaciones y correcciones están respaldadas por números reales en lugar de suposiciones. Esto convierte la optimización en algo que simplemente puedes pedir: > "Comprueba si mi escena está dentro de los límites, encuentra lo que sea que está frenando la tasa de frames cerca del punto de spawn, arréglalo y muéstrame los números antes y después." ### Combinar con el servidor MCP de Blender Las herramientas de Decentraland le dicen 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 recuento de triángulos, fusionar sus materiales o reducir sus texturas, y exportar el resultado de vuelta a la escena como un `.glb` archivo, donde luego puede volver a medir la tasa de frames en el mundo. Ten en cuenta que las ediciones automáticas de meshes pueden cambiar visiblemente el aspecto de un modelo, así que revisa siempre los resultados y guarda 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.decentraland.org/creator/content-creator-es/scenes-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 what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.