> 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-pt/scenes-sdk7/otimizacao/performance-optimization.md). # Otimização de Desempenho Otimize sua scene para carregar rapidamente e funcionar sem problemas para todos os jogadores. Existem vários aspectos que você pode otimizar nas suas scenes para garantir a melhor experiência possível para os jogadores que as visitam. Este documento aborda algumas práticas recomendadas que podem fazer uma grande diferença na rapidez com que sua scene carrega e na fluidez com que ela roda para os jogadores que estão nela ou em scenes vizinhas. Lembre-se de que muitos jogadores podem estar visitando a Decentraland usando hardware que não foi feito para gaming, pelo navegador ou a partir do [aplicativo móvel](/creator/content-creator-pt/criar-para-mobile/cliente-movel/overview.md) num telemóvel — tudo isso limita quanta capacidade de processamento está disponível para a sua scene. A experiência de visitar a sua scene deve ser fluida para todos. {% embed url="" %} Confira [Recursos Úteis](/creator/content-creator-pt/scenes-sdk7/primeiros-passos/useful-resources.md) para ferramentas que podem ajudar, como o Decentraland Scene Optimizer, que extrai, deduplica e comprime textures dos modelos 3D da sua scene. {% hint style="info" %} **📱 Mobile**: Dispositivos móveis geralmente são o client com mais restrições de recursos. Se sua scene for voltada para jogadores móveis, veja também [Building for Mobile](/creator/content-creator-pt/criar-para-mobile/cliente-movel/overview.md) para orientações específicas para mobile. {% endhint %} O Explorer da Decentraland impõe muitas otimizações no nível do engine. Essas otimizações fazem uma grande diferença, mas o desafio de renderizar várias experiências geradas pelos usuários simultaneamente em um navegador é grande. Precisamos da sua ajuda para que tudo funcione de forma fluida. ## Tempo ### reprodução de vídeo Reproduzir vídeos é uma das coisas mais custosas para o engine lidar. Se sua scene inclui vídeos, certifique-se de que apenas *UM* VideoTexture esteja em uso por vez. Você pode ter dezenas de planos compartilhando o mesmo VideoTexture sem impacto significativo no desempenho, mas assim que você adicionar um segundo VideoTexture, seus efeitos na taxa de quadros se tornam muito perceptíveis. Você também deve evitar vídeos reproduzindo em regiões onde eles não podem ser vistos. Por exemplo, se você tiver uma tela em ambiente interno, alterne o vídeo usando uma trigger area com base em quando o jogador entra e sai. {% hint style="info" %} **💡 Dica**: Um truque que várias scenes usaram é transmitir um único vídeo com várias regiões mapeadas de forma diferente para diferentes planos. Cada tela de vídeo usa [mapeamento UV](/creator/content-creator-pt/scenes-sdk7/fundamentos-de-conteudo-3d/materials.md#using-textures) para mostrar apenas uma parte distinta do VideoTexture. Graças a isso, pode parecer que há vídeos separados sendo reproduzidos sem o custo de múltiplos VideoTextures. {% endhint %} {% hint style="info" %} **💡 Dica**: Quando os jogadores estão fora da sua scene, os VideoTextures não são atualizados a cada frame. Isso ajuda a reduzir o impacto para scenes vizinhas. Ainda assim, o ideal é só ligar a reprodução de quaisquer vídeos quando os jogadores [entrarem na sua scene](/creator/content-creator-pt/scenes-sdk7/interatividade/event-listeners.md#player-enters-or-leaves-scene) . {% endhint %} ### Carregamento tardio Se sua scene for grande, ou tiver áreas internas que nem sempre estão visíveis, você pode optar por não carregar o conjunto inteiro de entities desde o início. Em vez disso, carregue o conteúdo por região conforme o jogador visita diferentes partes da scene. Isso pode reduzir significativamente o tempo de carregamento da scene e também a quantidade de textures e conteúdo 3D que o engine precisa lidar a cada frame. Por exemplo, o prédio principal de um museu poderia carregar desde o início, mas as pinturas de cada andar só carregariam para cada jogador conforme eles visitassem cada andar. Veja [esta scene de exemplo](https://github.com/decentraland-scenes/lazy-loading) para ver como isso pode funcionar. Para obter o melhor resultado em termos de evitar travamentos, oculte entities alternando a propriedade `visible` da shape para false. Com essa abordagem, você as adiciona ao engine ao criá-las, mas simplesmente não torna seus modelos visíveis. Uma alternativa é não adicionar as entities ao engine até que sejam necessárias. Isso pode resultar em alguns travamentos quando as entities aparecem pela primeira vez, e elas também podem levar alguns segundos para se tornarem visíveis. A vantagem dessa abordagem é que ela é uma forma válida de contornar o [limitações da scene](/creator/content-creator-pt/scenes-sdk7/otimizacao/scene-limitations.md). Tenha em mente que a contagem de limitações da scene é para o conteúdo que está sendo renderizado na scene em um dado momento, não para o conteúdo total que poderia ser renderizado. Carregar e descarregar partes da scene deve permitir que você contorne essas limitações. {% hint style="warning" %} **📔 Observação**: Entities que não estão visíveis, mas são adicionadas ao engine, ainda contam para as limitações da scene. {% endhint %} Você também pode alternar animações ligadas ou desligadas para entities que estejam distantes ou ocultas. Por exemplo, para um NPC que reproduz uma animação idle muito sutil, você poderia fazer com que essa animação só seja reproduzida quando o jogador estiver a menos de 20 metros de distância. Use uma trigger area ao redor do NPC e alterne suas animações conforme necessário. {% hint style="info" %} **💡 Dica**: Quando uma entity está distante e pequena o suficiente, ela é eliminada pelo engine. Esse culling ajuda no nível de drawcall, mas remover entities do engine é sempre melhor. Esse culling também não leva em conta a oclusão por outras entities, então entities que não são tão pequenas, mas estão escondidas por uma parede, ainda são renderizadas. {% endhint %} ### Blocos assíncronos Blocos de [código async](/creator/content-creator-pt/scenes-sdk7/padroes-de-programacao/async-functions.md) não bloqueiam o andamento de todo o resto enquanto esperam: a scene continua rodando, e o bloco async é retomado quando a resposta aguardada chega. Observe que scenes rodam em uma única thread, então isso não é processamento paralelo, apenas evita que a scene fique parada enquanto aguarda respostas externas. Quaisquer processos que dependam de respostas de serviços assíncronos, como `getPlayerData()` ou `getRealm()` devem sempre rodar em blocos async, pois, do contrário, bloqueiam o restante do carregamento da scene enquanto aguardam uma resposta. O mesmo vale para quaisquer chamadas a servidores de terceiros. Observe que a scene será considerada totalmente carregada quando tudo o que não for async estiver concluído. Processos async ainda podem estar em execução quando o jogador entra na scene. Evite situações em que um processo async resulte no carregamento de uma entity que possa prender o jogador dentro da sua geometria. ### Depender de Events Tente fazer com que a lógica da scene dependa o máximo possível de ouvir [events](/creator/content-creator-pt/scenes-sdk7/interatividade/event-listeners.md) em vez de executar verificações a cada frame. O `update()` função em um [system](/creator/content-creator-pt/scenes-sdk7/arquitetura/systems.md) é executado a cada frame, 30 vezes por segundo (idealmente). Evite fazer verificações recorrentes se você puder, em vez disso, assinar um event. Por exemplo, em vez de verificar constantemente os wearables do jogador, você pode assinar o `onProfileChanged` event, e verificar os wearables do jogador somente quando eles mudarem. Se você precisar usar um system, evite fazer verificações ou ajustes em cada frame. Você pode incluir um timer como parte da função update e executar a verificação apenas uma vez por segundo completo, ou em qualquer outro período que faça sentido. ## Otimize modelos 3D Há várias maneiras pelas quais seus modelos 3D podem ser otimizados para ficarem mais leves. Ao trabalhar com o [Creator Hub](/creator/content-creator-pt/scene-editor/primeiros-passos/editor-installation.md), você pode ver estatísticas sobre os recursos usados por modelos 3D na sua scene, e se eles ultrapassam algum dos [limitações da scene](/creator/content-creator-pt/scenes-sdk7/otimizacao/scene-limitations.md). ![](https://2402076176-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) Você pode expandir este menu para ver detalhes. ![](https://2402076176-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) Aqui estão algumas dicas para melhorar esses indicadores: * Sempre que possível, compartilhe textures entre modelos 3D. Uma boa prática é usar uma única texture como um atlas map, compartilhada por todos os modelos na scene. É melhor ter 1 texture compartilhada grande de 1024x1024 pixels do que várias pequenas. > Nota: Evite usar o mesmo arquivo de imagem tanto para a textura albedo quanto para o normal map ou o emissive map de um material. Use arquivos separados, mesmo que idênticos. Atribuir o mesmo arquivo de imagem a diferentes tipos de properties de texture pode introduzir artefatos visuais indesejados quando comprimido para asset bundles. * *.glb* é um formato comprimido, ele sempre pesará menos do que um *.gltf*. Por outro lado, com *.gltf* é fácil compartilhar imagens de texture exportando textures como um arquivo separado. Você pode ter o melhor dos dois mundos usando o [pipeline a seguir](https://github.com/AnalyticalGraphicsInc/gltf-pipeline), que permite que você tenha *.glb* models com arquivos de texture externos. * Evite usar transparências com blending. Transparências com blending precisam contornar várias otimizações de rendering. Se possível, prefira geometria opaca ou com alpha test. * Evite meshes com skinning. Elas podem prejudicar o desempenho significativamente. {% hint style="info" %} **💡 Dica**: Leia mais sobre as melhores práticas de modelos 3D na \[Seção de Modelagem 3D]\(/creator/3d-modeling/3d-models {% endhint %} ### Resgatar um modelo pesado no Blender Quando as estatísticas apontam para um modelo específico, geralmente é mais rápido corrigir o modelo do que contornar o problema no código. As edições mais úteis, no Blender ou em qualquer ferramenta similar: * **Reduza a contagem de triangles** com o modificador Decimate. Esta é uma ferramenta de resgate para modelos que você já tem. Modelos novos ficam melhores quando são modelados em low-poly desde o início. * **Redimensione as textures** para uma potência de dois, 1024x1024 ou menor, e os reempacote no *.glb*. * **Delete faces that the player never sees**, como a parte de baixo e as costas de props. Ative [back-face culling](#backface-culling) em vez de duplicar a geometria. * **Mescle materials** em um, usando uma única texture atlas em vez de uma texture por parte. * **Remova lights, cameras e materials de `_collider` meshes.** O engine os ignora, então são apenas peso. Verifique a contagem de triangles e a contagem de materials antes e depois, depois exporte por cima do mesmo arquivo. Se um preview estiver em execução, ele recarrega com suas alterações. ### Reutilizando o mesmo model muitas vezes As scenes geralmente estão cheias de conteúdo repetido: postes de luz ao longo de uma rua, cadeiras em um room, árvores em um parque. A melhor forma de construir isso é a mais simples — **dar a cada cópia sua própria entity, e apontar todas elas para o mesmo *****.glb***** arquivo.** ```ts // BOM: um arquivo, muitas entities for (const position of lampPostPositions) { const lampPost = engine.addEntity() Transform.create(lampPost, { position }) GltfContainer.create(lampPost, { src: 'assets/scene/lampPost.glb' }) } ``` O engine reconhece que essas entities compartilham uma origem. O arquivo é baixado uma vez, convertido para asset bundle uma vez, e seus meshes e textures são mantidos na memória uma vez — o vigésimo poste de luz custa quase nada além da sua própria posição no mundo. Isso também funciona entre scenes: se uma scene vizinha usar o mesmo arquivo, ele já está na memória. Exportar vinte *.glb* arquivos quase idênticos significa, em vez disso, vinte downloads e vinte cópias na memória. O que isso **não** economiza são draw calls. Vinte postes de luz são vinte objects a desenhar, venham eles de vinte entities ou de um único *.glb* que contém vinte postes de luz modelados nele. A única forma de reduzir essa contagem é unir os meshes na sua ferramenta de modelagem, o que é um verdadeiro trade-off — veja [Instancing vs Duplicating vs Merging](/creator/content-creator-pt/modelacao-3d-e-animacoes/meshes.md#instancing-objects-vs-duplicating-objects) para saber quando isso vale a pena. Algumas dicas relacionadas: * **Agrupe em clusters em vez de um único model gigante.** Se você tiver muitos props espalhados, um bom meio-termo é um *.glb* por grupo — um bloco de rua, móveis suficientes para um cômodo — em vez de um model por prop ou um model para toda a scene. Você reduz o número de objects enquanto mantém cada cluster pequeno o suficiente para que o culling ainda faça algo útil. * **Criando muitas cópias de uma vez?** Pré-carregue o model primeiro com o [`AssetLoad` component](/creator/content-creator-pt/scenes-sdk7/otimizacao/pre-load-resources.md). As cópias são então criadas a partir de um model que já está na memória, em vez de cada uma esperar pelo mesmo download. Construir cada cópia ainda dá trabalho, então uma grande leva pode custar um frame de qualquer maneira — o pré-carregamento remove a espera pelo arquivo, não o custo de criar as cópias. * **Um model muito grande é mais pesado para o engine do que vários pequenos.** O engine distribui o trabalho de construir sua scene por vários frames para evitar travamentos, mas não consegue dividir um único model enorme — isso cai em um frame. Muitas partes menores carregam de forma fluida; uma peça monolítica tem mais chance de causar uma falha visível. * **Repetir um model não introduz novas textures ou geometria.** Vinte postes de luz construídos a partir de um model compartilham os meshes e textures desse model em vez de adicionarem ao conjunto — o vigésimo não custa nada em memória de texture. Materials são a exceção: o engine cria uma instância de material por object renderizado para aplicar o clipping de limites da sua scene, então a contagem de materials acompanha o número de objects que você renderiza, não o número de models que você usa. Essas instâncias ainda compartilham as mesmas textures e variantes de shader, então custam um pouco de memória e não tempo de frame. O que empurra uma scene contra o [limite](/creator/content-creator-pt/scenes-sdk7/otimizacao/scene-limitations.md) é ter muitos *diferentes* models, cada um com seu próprio conjunto sob medida — então consolidar sua scene em torno de uma biblioteca menor de models reutilizados ajuda nisso. ### Backface Culling Para otimização de desempenho, o Backface Culling será definido como **On** em **todos os** nos materials do model uma vez renderizados no engine, independentemente das suas configurações. Se você espera ver o backface ou o interior dos seus models, duplique as faces e inverta as normals. #### Solução de problemas Para verificar se uma scene tem problemas de Backface Culling nos materials, siga estes passos: 1. Abra o `painel de debug` na scene. * Se a scene estiver publicada, digite o `/debug` comando no chat. * Se você estiver no modo Preview na scene., clique no ícone Bug ( ícone de debug ) localizado no canto superior direito da tela. 2. O painel de debug aparecerá no canto inferior direito da tela. 3. Em **Cena Atual**, clique no **Backface debugger** botão. ![](https://2402076176-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. Toggle **Force Backface Culling**: Ele mostra os materials renderizados com Backface Culling On. Esta é a renderização real quando a otimização estiver em produção. Alterne On e Off para identificar materials que precisam de correção. 5. Alterne o **Backface debugger** para identificar facilmente materials que têm Backface Culling Off. Ele destaca: * **Vermelho**: Materials que não têm Backface Culling definido como **On**. * **Verde**: Materials com Backface Culling **On**.


Material com Backface Culling Off (à esquerda) vs. Backface Culling On (à direita)

### Conversão para Asset Bundle Sempre que você publica uma scene, os content servers da Decentraland comprimem cada *.gltf* e *.glb* model nela para o formato asset bundle. Esse formato é *significativamente* mais leve, fazendo as scenes carregarem muito mais rápido e rodarem de forma mais fluida. A conversão começa imediatamente após cada deploy. Normalmente leva apenas alguns segundos, embora possa demorar mais em scenes muito grandes ou quando os servers estão ocupados, já que a conversão roda separadamente para cada plataforma e pode ficar na fila atrás de outras scenes. Você pode [verificar o status da conversão](/creator/content-creator-pt/scene-editor/publicar/publish-scene.md#check-the-conversion-status) da sua scene diretamente. Você também pode executar essa mesma conversão localmente enquanto desenvolve sua scene. Isso torna seu preview mais fluido e permite que você verifique quaisquer problemas com os models comprimidos antes de publicar. Veja [Prévia com assets otimizados](/creator/content-creator-pt/scenes-sdk7/primeiros-passos/preview-scene.md#preview-with-optimized-assets). {% hint style="info" %} **💡 Dica**: Ao planejar um evento na Decentraland, publique sua versão final com pelo menos uma hora de antecedência, para que os models já tenham sido convertidos para asset bundles até lá e você tenha tempo de corrigir qualquer coisa inesperada. Se você não quiser estragar a surpresa antes do evento, você pode implantar uma versão da sua scene que inclua todos os modelos 3D finais na pasta do projeto, mas em que eles não estejam visíveis ou em que seu tamanho esteja definido como 0. {% endhint %} {% hint style="warning" %} **📔 Observação**: Se você fizer *qualquer* qualquer alteração em um arquivo de model 3D, mesmo que seja apenas uma mudança de nome, ele será considerado um novo arquivo e precisará ser convertido novamente para o formato asset bundle. {% endhint %} ## Conectividade Se sua scene se conectar a qualquer server de terceiros ou usar o [messagebus](/creator/content-creator-pt/scenes-sdk7/rede/serverless-multiplayer.md#send-explicit-messagebus-messages) para enviar mensagens entre jogadores, há também algumas coisas que você pode querer ter em mente. * Sua scene deve ter apenas uma conexão ativa de WebSockets por vez. * As chamadas HTTP são canalizadas pelo engine para que apenas uma seja tratada por vez. Quaisquer requests adicionais são colocadas em fila internamente e precisam aguardar até que os outros requests sejam concluídos. Esse processo de fila é tratado automaticamente; você não precisa fazer nada. * Ao usar o [messagebus](/creator/content-creator-pt/scenes-sdk7/rede/serverless-multiplayer.md#send-explicit-messagebus-messages) para enviar mensagens entre jogadores, tenha em mente que todas as mensagens são enviadas a todos os outros jogadores na ilha do server. Evite situações em que uma mensagem recebida resulte diretamente no envio de outra mensagem, pois o número de mensagens pode crescer exponencialmente rapidamente quando há uma multidão na scene. ## UI da Scene As UIs da scene podem se tornar caras para renderizar quando são compostas de muitos elementos individuais. Tenha em mente que cada elemento de UI requer um drawcall separado no engine. {% hint style="info" %} **💡 Dica**: Tente mesclar vários elementos em uma única image. Por exemplo, se você tem um menu com vários elementos de texto, o ideal é ter o texto dos tiles e quaisquer imagens adicionais embutidos na imagem de fundo. Isso poupa o engine de fazer um drawcall adicional por frame para cada elemento de texto. {% endhint %} Evite fazer ajustes na UI a cada frame; isso é especialmente caro e pode acabar ficando enfileirado. Por exemplo, se houver uma health bar na sua UI que deva diminuir ao longo do tempo, provavelmente os jogadores não notarão diferença entre ela atualizar a 10 FPS em vez de 30 FPS (a cada frame). O system que atualiza essa barra pode usar um timer curto que conta 100 milissegundos e só afetar a UI quando esse timer chegar a 0. Evite ter muitos elementos de UI ocultos; eles também afetam o desempenho mesmo sem estarem sendo renderizados. Quando possível, tente criar componentes de UI sob demanda. ## Terreno de paisagem em Worlds Scenes publicadas em um [Decentraland World](https://github.com/decentraland/docs/tree/main/creator/worlds/about.md) são cercados por uma paisagem gerada automaticamente de pastagem, árvores e mar. Renderizar essa paisagem consome parte do orçamento de rendering do jogador. Se sua scene não precisar disso, você pode [desativar o terreno de paisagem](/creator/content-creator-pt/scenes-sdk7/tipos-de-projetos/scene-metadata.md#landscape-terrain) no seu `scene.json` para liberar esses recursos para o conteúdo da sua própria scene. ## Monitorar o Desempenho A melhor métrica para saber quão bem uma scene está performando é o FPS (Frames Per Second). No preview, você pode ver o FPS atual da scene no painel de debug. O ideal é buscar sempre 30 FPS ou mais. Na scene implantada, você pode alternar o painel que mostra essas métricas escrevendo `/showfps` na janela do chat. ### painel de Scene Stats Ao executar uma scene em preview no client desktop, você pode abrir um painel que mostra stats ao vivo sobre o conteúdo da sua scene. Clique no ícone de stats no canto superior direito da tela, ao lado dos ícones de console e debug. painel de Scene Stats O painel conta os triangles, entities, bodies e textures da scene em relação aos seus limites, mostrando qual porcentagem de cada budget está em uso. Um valor fica laranja assim que atinge 80% do seu limite. Ele também mostra contagens simples de materials, geometries, colliders e vídeos ou áudios externos. Passe o hover sobre o ícone de informação ao lado de cada métrica para ver uma explicação do que ela conta e por que isso importa. Os números são atualizados em tempo real à medida que o conteúdo carrega e descarrega, o que torna o painel útil para verificar como estratégias como [lazy loading](#lazy-loading) afetam o que o engine está realmente lidando em um dado momento. Veja [limitações da scene](/creator/content-creator-pt/scenes-sdk7/otimizacao/scene-limitations.md) para detalhes sobre cada limite. Tenha em mente que esses são soft limits: ultrapassar um deles não bloqueará sua scene, mas pode degradar o desempenho para os jogadores. ### Mensagens entre a scene e o engine Um dos principais gargalos no desempenho de uma scene costuma ser o envio de mensagens entre o código da scene e o engine. Quando você executa uma scene em preview, observe que no canto superior direito aparece “Y = Toggle Panel”. Pressione Y no teclado para abrir um painel com algumas informações úteis que são atualizadas em tempo real. À medida que você interage com coisas que envolvem mensagens entre o SDK e o engine, você notará que o número de ‘Processed Messages’ cresce. Você deve observar de perto o número de ‘Pending on Queue’; ele deve estar sempre em 0 ou perto de 0. Isso informa quantas dessas mensagens não foram processadas e foram colocadas em uma fila. Se a contagem de ‘Pending on Queue’ começar a crescer, então você entrou na zona de perigo e deve pensar em fazer mais otimizações na sua scene. {% hint style="warning" %} **📔 Observação**: Não mantenha o painel aberto quando não estiver usando-o, pois isso tem um impacto negativo no desempenho. {% endhint %} Tenha em mente que o desempenho que você observa no preview pode diferir do da produção: * Scenes vizinhas ao redor podem ter um impacto negativo * A compressão dos models 3D das scenes em asset bundles pode ter um impacto positivo * Alguns jogadores que visitam sua scene podem estar usando hardware menos potente É sempre uma boa prática tentar implantar sua scene primeiro em um [Decentraland World](/creator/content-creator-pt/scenes-sdk7/publicacao/publishing-options.md#decentraland-worlds) para fazer testes mais completos. Sempre peça feedback aos jogadores. Nunca tome como certo que a forma como você vivencia a scene é a mesma para todo mundo. ## Otimizar com IA Um agente de IA pode cuidar de boa parte da medição e da correção descritas nesta página para você. A Decentraland fornece [Habilidades de IA](/creator/content-creator-pt/scenes-sdk7/primeiros-passos/vibe-coding.md#install-skills-for-any-ai-agent) skills que ensinam agentes de código (como Claude Code ou Cursor) a otimizar scenes, e o client desktop inclui um [MCP server](/creator/content-creator-pt/scenes-sdk7/primeiros-passos/vibe-coding.md#let-the-ai-see-your-scene-in-world) que permite ao agent inspecionar e medir diretamente a sua scene em execução. Com as `optimize-scene` e `unity-explorer-mcp` skills instaladas e o MCP server conectado, um agent pode: * **Verificar a scene em relação aos seus budgets de conteúdo**: ele lê as mesmas stats ao vivo do painel de Scene Stats e as compara com os [limitações da scene](/creator/content-creator-pt/scenes-sdk7/otimizacao/scene-limitations.md)limites, para que ele possa dizer qual budget está ficando apertado. * **Encontrar os assets responsáveis**: ele classifica os models 3D da sua scene pelo número de triangles, materials e draw calls que cada um contribui, incluindo o que é visível de um ponto de vista específico, para que ele saiba exatamente quais models otimizar primeiro. * **Medir a taxa de quadros real**: ele posiciona o jogador em qualquer ponto da scene e amostra o FPS que um jogador realmente experimenta ali, incluindo travadinhas momentâneas. * **Verificar o próprio trabalho**: depois de cada alteração ele pode medir novamente, para que suas recomendações e correções sejam baseadas em números reais em vez de suposições. Isso transforma a otimização em algo que você pode simplesmente pedir: > "Verifique se a minha scene está dentro dos limites, descubra o que quer que esteja derrubando a taxa de quadros perto do spawn point, corrija e me mostre os números antes e depois." ### Combinar com o Blender MCP server As ferramentas da Decentraland dizem ao agent quais models são os mais pesados, mas elas não editam os models em si. Para ir além, você pode tentar combiná-las com o [Blender MCP server](https://www.blender.org/lab/mcp-server/), que dá ao agent acesso às ferramentas de edição do Blender. Isso permite que o agent abra um model pesado no Blender, reduza sua contagem de triangles, mescle seus materials ou diminua suas textures, e exporte o resultado de volta para a scene como um `.glb` arquivo, onde então ele pode medir novamente a taxa de quadros no mundo. Tenha em mente que edições automatizadas de meshes podem alterar visivelmente a aparência de um model, então sempre revise os resultados e mantenha backups dos seus arquivos originais. --- # 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-pt/scenes-sdk7/otimizacao/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.