> 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 rápido e rodar suavemente para todos os players. Há vários aspectos que você pode otimizar nas suas cenas para garantir a melhor experiência possível para os jogadores que as visitam. Este documento aborda algumas boas práticas que podem fazer uma grande diferença na rapidez com que sua cena carrega e em quão suavemente ela roda para os jogadores que estão nela ou em cenas vizinhas. Tenha em mente que muitos jogadores podem estar visitando Decentraland usando hardware que não foi feito para jogos, via o navegador ou pelo [aplicativo móvel](/creator/content-creator-pt/criar-para-dispositivos-moveis/mobile-client/overview.md) em um telefone — tudo isso limita quanta capacidade de processamento está disponível para sua cena. A experiência de visitar sua cena 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 texturas dos modelos 3D da sua cena. {% hint style="info" %} **📱 Mobile**: Dispositivos móveis geralmente são o client com menos recursos. Se a sua cena for destinada a jogadores em dispositivos móveis, veja também [Construindo para Mobile](/creator/content-creator-pt/criar-para-dispositivos-moveis/mobile-client/overview.md) para orientações específicas para mobile. {% endhint %} O Explorer do Decentraland impõe muitas otimizações em nível de engine. Essas otimizações fazem uma grande diferença, mas o desafio de renderizar várias experiências geradas por usuários simultaneamente em um navegador é enorme. Precisamos da sua ajuda para fazer tudo rodar suavemente. ## Tempo ### Reprodução de vídeo Reproduzir vídeos é uma das coisas mais custosas para o engine lidar. Se a sua cena inclui vídeos, certifique-se de que apenas *UMA* VideoTexture esteja em uso por vez. Você pode ter dezenas de planos compartilhando a mesma VideoTexture sem impacto significativo no desempenho, mas assim que você adiciona uma segunda VideoTexture, seus efeitos na taxa de quadros se tornam muito perceptíveis. Você também deve evitar ter vídeos sendo reproduzidos em regiões onde eles não podem ser vistos. Por exemplo, se você tiver uma tela em um 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 cenas usaram é transmitir um único vídeo com várias regiões mapeadas de forma diferente para diferentes planos. Cada tela de vídeo usa [UV mapping](/creator/content-creator-pt/scenes-sdk7/fundamentos-de-conteudo-3d/materials.md#using-textures) para mostrar apenas uma parte distinta da VideoTexture. Graças a isso, pode parecer que há vídeos separados sendo reproduzidos sem o custo de várias VideoTextures. {% endhint %} {% hint style="info" %} **💡 Dica**: Quando os jogadores estão do lado de fora da sua cena, as VideoTextures não são atualizadas a cada frame. Isso ajuda a reduzir o impacto nas cenas ao redor. Ainda assim, o ideal é só ativar a reprodução de vídeos quando os jogadores [entrarem na sua cena](/creator/content-creator-pt/scenes-sdk7/interatividade/event-listeners.md#player-enters-or-leaves-scene) . {% endhint %} ### Carregamento preguiçoso Se a sua cena for grande ou tiver áreas internas que nem sempre ficam visíveis, você pode optar por não carregar todo o conjunto de entities logo de início. Em vez disso, carregue o conteúdo por região conforme o jogador visita diferentes partes da cena. Isso pode reduzir significativamente o tempo de carregamento da cena e também a quantidade de texturas e conteúdo 3D que o engine precisa lidar em cada frame. Por exemplo, o prédio principal de um museu poderia carregar desde o início, mas as pinturas em cada andar só seriam carregadas para cada jogador conforme ele visitasse cada andar. Veja [esta cena de exemplo](https://github.com/decentraland-scenes/lazy-loading) para ver como isso poderia funcionar. Para obter o melhor resultado em termos de evitar engasgos, 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 engasgos 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 maneira válida de contornar a [limitações da cena](/creator/content-creator-pt/scenes-sdk7/otimizacao/scene-limitations.md). Lembre-se de que a contagem de limitações da cena vale para o conteúdo que está sendo renderizado na cena em um determinado momento, e não para o conteúdo total que poderia ser renderizado. Carregar e descarregar partes da cena deve permitir que você contorne essas limitações. {% hint style="warning" %} **📔 Nota**: Entities que não estão visíveis, mas foram adicionadas ao engine, contam para as limitações da cena. {% endhint %} Você também pode alternar animations para entities que estão longe ou ocultas. Por exemplo, para um NPC que reproduz uma animação idle muito sutil, você poderia fazer com que ela só fosse reproduzida quando o jogador estiver a menos de 20 metros. Use uma trigger area ao redor do NPC e alterne suas animations conforme necessário. {% hint style="info" %} **💡 Dica**: Quando uma entity está longe o suficiente e é pequena o bastante, ela é culled pelo engine. Esse culling ajuda em nível de drawcall; 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 assíncrono](/creator/content-creator-pt/scenes-sdk7/padroes-de-programacao/async-functions.md) não bloqueiam o andamento de todo o resto enquanto esperam: a cena continua rodando, e o bloco assíncrono é retomado quando a resposta aguardada chega. Observe que as cenas rodam em uma única thread, então isso não é processamento paralelo; apenas evita que a cena fique travada enquanto espera por respostas externas. Quaisquer processos que dependam de respostas de serviços assíncronos, como `getPlayerData()` ou `getRealm()` devem sempre rodar em blocos assíncronos, pois, caso contrário, bloqueiam o restante do carregamento da cena enquanto aguardam uma resposta. O mesmo se aplica a quaisquer chamadas para servidores de terceiros. Observe que a cena será considerada totalmente carregada quando tudo o que não for assíncrono estiver concluído. Processos assíncronos ainda podem estar em execução quando o jogador entra na cena. Evite situações em que um processo assíncrono resulte no carregamento de uma entity que possa prender o jogador dentro da geometria dela. ### Dependa de Events Tente fazer com que a lógica da cena dependa de ouvir [events](/creator/content-creator-pt/scenes-sdk7/interatividade/event-listeners.md) o máximo possível, em vez de fazer verificações a cada frame. Os `update()` função em um [system](/creator/content-creator-pt/scenes-sdk7/arquitetura/systems.md) roda em cada frame, 30 vezes por segundo (idealmente). Evite fazer verificações recorrentes se você puder, em vez disso, assinar um evento. Por exemplo, em vez de verificar constantemente os wearables do jogador, você pode assinar o `onProfileChanged` evento e verificar os wearables do jogador apenas 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 por qualquer 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/comece/editor-installation.md), você pode ver estatísticas sobre os recursos usados pelos modelos 3D na sua cena, e se eles passam em algum dos [limitações da cena](/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) 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) Aqui estão algumas dicas para melhorar essas métricas: * Quando possível, compartilhe texturas entre modelos 3D. Uma boa prática é usar uma única texture como atlas map, compartilhada por todos os modelos na cena. É melhor ter 1 texture compartilhada grande de 1024x1024 pixels em vez de várias pequenas. > Observação: evite usar o mesmo arquivo de imagem tanto para a texture albedo quanto para o normal map ou o emissive map de um material. Use arquivos separados, mesmo que sejam idênticos. Atribuir o mesmo arquivo de imagem a diferentes tipos de propriedades de texture pode introduzir artefatos visuais indesejados quando compactado em asset bundles. * *.glb* é um formato compactado, ele sempre pesará menos do que um *.gltf*. Por outro lado, com *.gltf* é fácil compartilhar imagens de texturas exportando texturas 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 textura externos. * Evite usar transparências com blend. Transparências com blend precisam contornar várias das otimizações de renderização. Se possível, prefira geometria opaca ou com alpha tested. * Evite skinned meshes. Elas podem prejudicar significativamente o desempenho. {% hint style="info" %} **💡 Dica**: Leia mais sobre boas 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, normalmente é 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 semelhante: * **Reduza a contagem de triângulos** com o modificador Decimate. Esta é uma ferramenta de resgate para modelos que você já possui. Modelos novos ficam melhores quando são modelados em low-poly desde o início. * **Redimensione texturas** para uma potência de dois, 1024x1024 ou menor, e reempacote-as no *.glb*. * **Exclua faces que o jogador nunca vê**, como as partes inferiores e as costas de props. Ative [back-face culling](#backface-culling) em vez de dobrar a geometria. * **Una materiais** em um só, usando uma única texture de atlas em vez de uma texture por parte. * **Remova lights, cameras e materials de `_collider` meshes.** O engine os ignora, então são puro peso. Verifique a contagem de triângulos e a contagem de materials antes e depois e, em seguida, exporte novamente sobre o mesmo arquivo. Se houver um preview em execução, ele recarrega com suas alterações. ### Reutilizar o mesmo modelo muitas vezes As cenas costumam estar cheias de conteúdo repetido: postes de luz ao longo de uma rua, cadeiras em uma sala, árvores em um parque. A melhor forma de construir isso é a mais simples — **dê a cada cópia a sua própria entity e aponte todas para o mesmo *****.glb***** ficheiro.** ```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 texturas ficam na memória uma vez — o vigésimo poste de luz quase não custa nada além da sua própria posição no mundo. Isso também funciona entre cenas: se uma cena vizinha usar o mesmo arquivo, ele já está na memória. Exportar vinte arquivos quase idênticos, em vez disso, significa vinte downloads e vinte cópias na memória. *.glb* arquivos, em vez disso, significa 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 objetos para desenhar, sejam eles provenientes de vinte entities ou de um único *.glb* que contenha vinte postes de luz modelados nele. A única maneira de reduzir essa contagem é unir os meshes em sua ferramenta de modelagem, o que é um verdadeiro compromisso — veja [Instancing vs Duplicating vs Merging](/creator/content-creator-pt/modelagem-3d-e-animacoes/meshes.md#instancing-objects-vs-duplicating-objects) para saber quando vale a pena. Algumas dicas relacionadas: * **Agrupe em clusters em vez de um modelo gigante.** Se você tiver muitos props espalhados, um bom meio-termo é um *.glb* por grupo — um trecho de rua, os móveis de um cômodo — em vez de um modelo por prop ou um modelo para a cena inteira. Você reduz o número de objetos enquanto mantém cada cluster pequeno o suficiente para que o culling ainda faça algo útil. * **Vai gerar muitas cópias de uma vez?** Pré-carregue o modelo 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 modelo 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 enxurrada pode custar um frame de qualquer forma — o pré-carregamento remove a espera pelo arquivo, não o custo de criar as cópias. * **Um modelo muito grande é mais pesado para o engine do que muitos pequenos.** O engine distribui o trabalho de construir sua cena entre frames para evitar travamentos, mas não consegue dividir um único modelo enorme — isso cai em um só frame. Muitas peças menores carregam de forma suave; uma peça monolítica tem mais chance de causar um engasgo visível. * **Repetir um modelo não introduz novas texturas ou geometria.** Vinte postes de luz construídos a partir de um único modelo compartilham os meshes e texturas desse modelo em vez de adicionar ao conjunto — o vigésimo não custa nada em memória de textura. Os materiais são a exceção: o engine cria uma instância de material por objeto renderizado para aplicar o clipping de limites da sua cena, então a contagem de materials acompanha o número de objetos que você renderiza, não o número de modelos que você usa. Essas instâncias ainda compartilham as mesmas texturas e variantes de shader, então custam um pouco de memória, em vez de tempo de frame. O que leva uma cena ao limite de textura [limite](/creator/content-creator-pt/scenes-sdk7/otimizacao/scene-limitations.md) é ter muitos *diferentes* modelos, cada um com seu próprio conjunto personalizado — então consolidar sua cena em torno de uma biblioteca menor de modelos reutilizados ajuda nisso. ### Backface Culling Para otimização de desempenho, o Backface Culling será definido como **On** on **todos** nos materials do modelo quando renderizados no engine, independentemente das suas configurações. Se você esperar ver o verso ou o interior dos seus modelos, duplique as faces e inverta as normals. #### Solução de problemas Para verificar se uma cena tem problemas de Backface Culling em materials, siga estas etapas: 1. Abra o `debug` painel na cena. * Se a cena estiver publicada, digite `/debug` comando no chat. * Se você estiver no modo Preview na cena., clique no ícone de 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 **Current Scene**, 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) 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 Toda vez que você publica uma cena, os servidores de conteúdo do Decentraland comprimem cada *.gltf* e *.glb* modelo nela para o formato asset bundle. Esse formato é *significativamente* mais leve, fazendo com que as cenas carreguem muito mais rápido e rodem com mais fluidez. A conversão começa imediatamente após cada deploy. Normalmente leva apenas alguns segundos, embora possa demorar mais em cenas muito grandes ou quando os servidores estão ocupados, já que a conversão roda separadamente para cada plataforma e pode ficar na fila atrás de outras cenas. Você pode [verificar o status da conversão](/creator/content-creator-pt/scene-editor/publish/publish-scene.md#check-the-conversion-status) da sua scene diretamente. Você também pode executar a mesma conversão localmente enquanto desenvolve sua cena. Isso deixa seu preview mais fluido e permite verificar quaisquer problemas com os modelos compactados antes de publicar. Veja [Pré-visualizar 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 em Decentraland, publique sua versão final com pelo menos uma hora de antecedência, para que todos os modelos já tenham sido convertidos para asset bundles até lá e você tenha tempo para corrigir qualquer coisa inesperada. Se você não quiser estragar a surpresa antes do evento, pode fazer o deploy de uma versão da sua cena 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" %} **📔 Nota**: Se você fizer *any* uma alteração em um arquivo de modelo 3D, mesmo que seja apenas uma mudança de nome, ele será considerado um arquivo novo e precisará ser convertido para o formato asset bundle novamente. {% endhint %} ## Conectividade Se a sua cena se conecta a qualquer servidor de terceiros ou usa o [messagebus](/creator/content-creator-pt/scenes-sdk7/networking/serverless-multiplayer.md#send-explicit-messagebus-messages) para enviar mensagens entre jogadores, há também algumas coisas que você talvez queira ter em mente. * Sua cena deve ter apenas uma conexão WebSockets ativa por vez. * As chamadas HTTP são canalizadas pelo engine para que apenas uma seja tratada por vez. Quaisquer solicitações adicionais são enfileiradas internamente e precisam esperar até que as outras solicitações sejam concluídas. Esse processo de enfileiramento é tratado automaticamente; você não precisa fazer nada. * Ao usar o [messagebus](/creator/content-creator-pt/scenes-sdk7/networking/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 servidor. Evite situações em que uma mensagem recebida resulte diretamente no envio de outra mensagem, pois o número de mensagens pode crescer rapidamente de forma exponencial quando há uma multidão na cena. ## UI da cena As UIs de cena podem ficar caras para renderizar quando são compostas por muitos elementos individuais. Tenha em mente que cada elemento de UI requer um drawcall separado no engine. {% hint style="info" %} **💡 Dica**: Tente combinar vários elementos em uma única imagem. Por exemplo, se você tiver um menu com vários elementos de texto, o ideal é ter o texto dos tiles e quaisquer imagens adicionais incorporados na imagem de fundo. Isso evita que o engine faça um drawcall adicional por frame para cada elemento de texto. {% endhint %} Evite fazer ajustes na UI a cada frame; isso é especialmente custoso e pode acabar entrando na fila. Por exemplo, se houver uma barra de saúde na sua UI que deva encolher ao longo do tempo, os jogadores provavelmente não notariam diferença entre ela atualizar a 10 FPS em vez de a 30 FPS (em cada frame). O system que atualiza essa barra pode usar um timer curto que conta 100 milissegundos e só afeta a UI quando esse timer chega a 0. Evite ter muitos elementos de UI ocultos; eles também afetam o desempenho mesmo sem serem renderizados. Quando possível, tente criar componentes de UI sob demanda. ## Terreno da paisagem em Worlds Cenas publicadas para um [Decentraland World](https://github.com/decentraland/docs/tree/main/creator/worlds/about.md) são cercadas por uma paisagem gerada automaticamente de campo, árvores e mar. Renderizar essa paisagem consome parte do orçamento de renderização do jogador. Se a sua cena não precisar disso, você pode [desativar o landscape terrain](/creator/content-creator-pt/scenes-sdk7/tipos-de-projetos/scene-metadata.md#landscape-terrain) no seu `scene.json` para liberar esses recursos para o próprio conteúdo da sua cena. ## Monitorar desempenho A melhor métrica para saber quão bem uma cena está performando é o FPS (Frames Per Second). No preview, você pode ver o FPS atual da cena no painel de debug. Seu objetivo deve ser sempre ter 30 FPS ou mais. Na cena implantada, você pode alternar o painel que mostra essas métricas escrevendo `/showfps` na janela de chat. ### painel Scene Stats Ao executar uma cena em preview no client desktop, você pode abrir um painel que mostra estatísticas ao vivo sobre o conteúdo da sua cena. Clique no ícone de estatísticas no canto superior direito da tela, ao lado dos ícones de console e debug. painel Scene Stats O painel conta os triângulos, entities, bodies e texturas da cena em relação aos seus limites, mostrando qual porcentagem de cada orçamento está em uso. Um valor fica laranja quando atinge 80% do seu limite. Ele também mostra contagens simples de materials, geometrias, colliders e vídeos ou áudios externos. Passe o mouse sobre o ícone de informação ao lado de cada métrica para obter uma explicação do que ela contabiliza e por que isso importa. Os números são atualizados em tempo real conforme 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 determinado momento. Veja [limitações da cena](/creator/content-creator-pt/scenes-sdk7/otimizacao/scene-limitations.md) para detalhes sobre cada limite. Tenha em mente que estes são limites flexíveis: ultrapassar um deles não bloqueará sua cena, mas pode degradar o desempenho para os jogadores. ### Mensagens entre a cena e o engine Um dos principais gargalos no desempenho de uma cena geralmente é o envio de mensagens entre o código da cena e o engine. Quando você executa uma cena 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' aumenta. Observe de perto o número de 'Pending on Queue'; ele deve estar sempre em 0 ou perto de 0. Isso indica quantas dessas mensagens não chegaram a ser processadas e foram para uma fila. Se a contagem de 'Pending on Queue' começar a crescer, você entrou na zona de perigo e deve pensar em fazer mais otimizações na sua cena. {% hint style="warning" %} **📔 Nota**: Não mantenha o painel aberto enquanto não estiver usando-o, pois ele tem impacto negativo no desempenho. {% endhint %} Tenha em mente que o desempenho que você observa no preview pode ser diferente do da produção: * As cenas vizinhas ao redor podem ter impacto negativo * A compressão dos modelos 3D das cenas em asset bundles pode ter impacto positivo * Alguns jogadores que visitam sua cena podem estar usando hardware menos potente É sempre uma boa prática tentar fazer o deploy da sua cena primeiro para 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 garantido que a forma como você vivencia a cena é a mesma para todos os outros. ## Otimize com IA Um agente de IA pode cuidar de grande parte da medição e da correção descritas nesta página para você. Decentraland fornece [AI skills](/creator/content-creator-pt/scenes-sdk7/primeiros-passos/vibe-coding.md#install-skills-for-any-ai-agent) que ensinam agentes de código (como Claude Code ou Cursor) a otimizar cenas, 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 agente inspecionar e medir diretamente a sua cena em execução. Com os `optimize-scene` e `unity-explorer-mcp` skills instalados e o MCP server conectado, um agente pode: * **Verificar a cena em relação aos seus orçamentos de conteúdo**: ele lê as mesmas estatísticas em tempo real do painel Scene Stats e as compara com os [limitações da cena](/creator/content-creator-pt/scenes-sdk7/otimizacao/scene-limitations.md)orçamentos * **Encontrar os assets responsáveis**: ele classifica os modelos 3D da sua cena pelo número de triângulos, materials e draw calls que cada um contribui, incluindo o que está visível a partir de um ponto de vista específico, para que saiba exatamente quais modelos otimizar primeiro. * **Medir a taxa de quadros real**: ele posiciona o jogador em qualquer ponto da cena e amostra o FPS que um jogador realmente experimenta ali, incluindo engasgos momentâneos. * **Verificar o próprio trabalho**: após cada alteração, ele pode medir novamente, então suas recomendações e correções são respaldadas por números reais em vez de suposições. Isso transforma a otimização em algo que você pode simplesmente pedir: > "Verifique se a minha cena está dentro dos limites, encontre o que quer que esteja derrubando a taxa de quadros perto do ponto de spawn, corrija isso e me mostre os números antes e depois." ### Combine com o Blender MCP server As ferramentas do Decentraland informam ao agente quais modelos são os mais pesados, mas elas não editam os modelos 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 agente acesso às ferramentas de edição do Blender. Isso permite que o agente abra um modelo pesado no Blender, reduza sua contagem de triângulos, una seus materials ou diminua suas texturas e exporte o resultado de volta para a cena como um `.glb` arquivo, onde então ele pode medir novamente a taxa de quadros no mundo. Tenha em mente que edições automatizadas em meshes podem alterar visivelmente a aparência de um modelo, 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 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-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 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.