> 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
Há vários aspetos que 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 em quão rapidamente a sua scene carrega e quão suavemente funciona para os jogadores que estão nela ou em scenes vizinhas.
Tenha em mente que muitos jogadores podem estar a visitar a Decentraland utilizando hardware que não foi feito para jogos, através do browser, ou a partir do [app mobile](/creator/content-creator-pt/scenes-sdk7/criar-para-mobile/building-for-mobile.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.
{% hint style="info" %}
**📱 Mobile**: Os dispositivos móveis são normalmente o client com mais restrições de recursos. Se a sua scene tiver como alvo jogadores em mobile, veja também [Building for Mobile](/creator/content-creator-pt/scenes-sdk7/criar-para-mobile/building-for-mobile.md) para orientações específicas para mobile.
{% endhint %}
O explorer da Decentraland aplica muitas otimizações ao nível do engine. Estas otimizações fazem uma grande diferença, mas o desafio de renderizar várias experiências geradas por utilizadores em simultâneo num browser é grande. Precisamos da sua ajuda para fazer tudo funcionar sem problemas.
## Temporalização
### Video playing
Reproduzir vídeos é uma das coisas mais dispendiosas para o engine processar. Se a sua scene incluir vídeos, certifique-se de que apenas *UM* VideoTexture está a ser usada de cada vez. Pode ter dezenas de planos a partilhar a mesma VideoTexture sem impacto significativo no desempenho, mas assim que adicionar uma segunda VideoTexture, os seus efeitos na framerate tornam-se muito percetíveis.
Também deve evitar ter vídeos a reproduzir em regiões onde não podem ser vistos. Por exemplo, se tiver um ecrã no interior, alterne o vídeo usando uma trigger area com base no momento em que o jogador entra e sai.
{% hint style="info" %}
**💡 Dica**: Um truque que várias scenes têm usado é transmitir um único vídeo com várias regiões que são mapeadas de forma diferente para diferentes planos. Cada ecrã de vídeo usa [UV mapping](/creator/content-creator-pt/scenes-sdk7/essenciais-de-conteudo-3d/materials.md#using-textures) para mostrar apenas uma parte distinta da VideoTexture. Graças a isso, pode parecer que estão a ser reproduzidos vídeos separados sem o custo de múltiplas VideoTextures.
{% endhint %}
{% hint style="info" %}
**💡 Dica**: Quando os jogadores estão fora da sua scene, as VideoTextures não são atualizadas em cada frame. Isto ajuda a reduzir o impacto nas scenes circundantes. Ainda assim, o ideal é ligar a reprodução de quaisquer vídeos apenas quando os jogadores [entram na sua scene](/creator/content-creator-pt/scenes-sdk7/interatividade/event-listeners.md#player-enters-or-leaves-scene) .
{% endhint %}
### Lazy loading
Se a sua scene for grande, ou tiver áreas interiores que nem sempre estão visíveis, pode optar por não carregar todo o conjunto de entities desde o início. Em vez disso, carregue o conteúdo por região à medida que o jogador visita diferentes partes da scene. Isto pode reduzir significativamente o tempo de carregamento da scene, bem como a quantidade de textures e conteúdo 3D que o engine precisa de processar em cada frame.
Por exemplo, o edifício principal de um museu poderia carregar desde o início, mas as pinturas em cada piso só seriam carregadas para cada jogador à medida que visitassem cada piso.
Veja [esta scene de exemplo](https://github.com/decentraland-scenes/lazy-loading) sobre como isso poderia funcionar.
Para obter o melhor resultado em termos de evitar engasgos, oculte entities alterando a propriedade da shape para false. `visible` Com esta abordagem, adiciona-as ao engine ao criá-las, mas simplesmente não torna os seus models visíveis.
Uma alternativa é não adicionar as entities ao engine até serem necessárias. Isto pode resultar em alguns engasgos quando as entities aparecem pela primeira vez, e também podem demorar alguns segundos até ficarem visíveis. A vantagem desta abordagem é que é 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á a ser renderizado na scene em qualquer momento, e não para o conteúdo total que poderia ser renderizado. Carregar e descarregar partes da scene deve permitir-lhe contornar essas limitações.
{% hint style="warning" %}
**📔 Nota**: As entities que não estão visíveis mas são adicionadas ao engine contam para as limitações da scene.
{% endhint %}
Também pode ligar ou desligar animações para entities que estão longe ou ocultas. Por exemplo, para um NPC que reproduz uma animação idle muito subtil, poderia fazer com que essa animação só fosse reproduzida quando o jogador estivesse a menos de 20 metros de distância. Use uma trigger area à volta do NPC e ligue ou desligue as suas animações em conformidade.
{% hint style="info" %}
**💡 Dica**: Quando uma entity está longe e é suficientemente pequena, é cullada pelo engine. Esta culling ajuda ao nível de drawcall, mas remover entities do engine é sempre melhor. Esta culling também não tem em conta a oclusão por outras entities, por isso entities que não são tão pequenas mas estão escondidas por uma parede continuam a ser renderizadas.
{% endhint %}
### Blocos async
Blocos de [código async](/creator/content-creator-pt/scenes-sdk7/padroes-de-programacao/async-functions.md) são processados numa thread separada do resto da scene, para evitar bloquear o progresso de tudo o resto.
Quaisquer processos que dependam de respostas de serviços assíncronos, como `getPlayerData()` ou `getRealm()` devem correr sempre em blocos async, caso contrário bloqueiam o restante carregamento da scene enquanto aguardam uma resposta. O mesmo se aplica a quaisquer chamadas para servidores de terceiros.
Note que a scene será considerada totalmente carregada quando tudo o que não é async estiver concluído. Os processos async podem ainda estar a correr quando o jogador entra na scene. Evite situações em que um processo async resulte no carregamento de uma entity que possa potencialmente deixar o jogador preso dentro da sua geometria.
### Baseie-se em Eventos
Tente fazer com que a lógica da scene dependa de ouvir [eventos](/creator/content-creator-pt/scenes-sdk7/interatividade/event-listeners.md) sempre que possível, em vez de executar verificações em cada frame.
O `update()` function num [system](/creator/content-creator-pt/scenes-sdk7/arquitetura/systems.md) corre em cada frame, 30 vezes por segundo (idealmente). Evite fazer verificações recorrentes se puder, em vez disso, subscrever-se a um evento.
Por exemplo, em vez de verificar constantemente os wearables do jogador, pode subscrever-se ao `onProfileChanged` evento e verificar os wearables do jogador apenas quando eles mudarem.
Se tiver de usar um system, evite fazer verificações ou ajustes em cada frame. Pode incluir um temporizador como parte da função update e executar a verificação apenas uma vez por cada segundo completo, ou qualquer período que faça sentido.
## Otimizar modelos 3D
Há várias formas de otimizar os seus models 3D para que sejam mais leves.
Ao trabalhar com o [Creator Hub](/creator/content-creator-pt/scene-editor/comecar/editor-installation.md), pode ver estatísticas sobre os recursos usados pelos models 3D na sua scene, e se ultrapassam algum dos [limitações da scene](/creator/content-creator-pt/scenes-sdk7/otimizacao/scene-limitations.md).
Pode expandir este menu para ver detalhes.
Aqui estão algumas dicas para melhorar estas métricas:
* Quando possível, partilhe textures entre models 3D. Uma boa prática é usar uma única texture como atlas map, partilhada por todos os models na scene. É melhor ter 1 texture partilhada grande de 1024x1024 pixels em vez de várias pequenas.
> Nota: Evite usar o mesmo ficheiro de imagem tanto para a albedo texture como para o normal map ou o emissive map de um Material. Use ficheiros separados, mesmo que sejam idênticos. Atribuir o mesmo ficheiro de imagem a diferentes tipos de propriedades de textura pode introduzir artefactos visuais indesejados quando comprimido para asset bundles.
* *.glb* é um formato comprimido, irá sempre pesar menos do que um *.gltf*. Por outro lado, com *.gltf* é fácil partilhar imagens de textura exportando textures como um ficheiro separado. Pode ter o melhor dos dois mundos usando o [pipeline seguinte](https://github.com/AnalyticalGraphicsInc/gltf-pipeline), que permite ter *.glb* models com ficheiros de textura externos.
* Evite usar transparências em blend. As transparências em blend têm de contornar bastantes otimizações de rendering. Se possível, privilegie geometria opaca ou com alpha test.
* Evite skinned meshes. Podem prejudicar significativamente o desempenho.
{% hint style="info" %}
**💡 Dica**: Leia mais sobre as melhores práticas de models 3D na \[Secção de Modelação 3D]\(/creator/3d-modeling/3d-models
{% endhint %}
### Backface Culling
Para otimização de desempenho, o Backface Culling será definido para **On** em **todos** os materials do model, uma vez renderizados no engine, independentemente das respetivas definições.
Se espera ver a face posterior ou o interior dos seus models, duplique as faces e inverta os normals.
#### Resolução de problemas
Para verificar se uma scene tem problemas de Backface Culling em materials, siga estes passos:
1. Abra o `debug` panel na scene.
* Se a scene estiver publicada, escreva o comando `/debug` no chat.
* Se estiver no modo Preview na scene., clique no ícone do Bug (
) localizado no canto superior direito do ecrã.
2. O debug panel aparecerá no canto inferior direito do ecrã.
3. Em **Current Scene**, clique no **Backface debugger** .
4. Toggle **Force Backface Culling**: Mostra os materials renderizados com Backface Culling On. Este é o rendering 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
Cerca de uma vez por dia, os servidores de conteúdo da Decentraland executam um processo para comprimir todos os *.gltf* e *.glb* models em cada scene recém-publicada para o formato asset bundle. Este formato é *significativamente* mais leve, tornando as scenes muito mais rápidas a carregar e mais suaves a correr no browser.
{% hint style="info" %}
**💡 Dica**: Quando planear um evento na Decentraland, certifique-se de que publica a sua scene com um dia de antecedência, para que os models já tenham sido todos convertidos para asset bundles até lá. Se não quiser estragar a surpresa antes do evento, pode publicar uma versão da sua scene que inclua todos os models 3D finais na pasta do projeto, mas em que estes não estejam visíveis ou em que o respetivo tamanho esteja definido como 0.
{% endhint %}
{% hint style="warning" %}
**📔 Nota**: Se fizer *qualquer* alteração a um ficheiro de model 3D, mesmo que seja apenas uma mudança de nome, será considerado um ficheiro novo e terá de ser convertido novamente para o formato asset bundle.
{% endhint %}
## Conectividade
Se a sua scene se ligar a quaisquer servidores de terceiros ou usar 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 talvez queira ter em mente.
* A sua scene deve ter apenas uma ligação WebSockets ativa de cada vez.
* As chamadas HTTP são encaminhadas pelo engine para que apenas uma seja processada de cada vez. Quaisquer pedidos adicionais são colocados internamente numa fila e têm de esperar até que os outros pedidos estejam concluídos. Este processo de enfileiramento é tratado automaticamente, não precisa de 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 para todos os outros jogadores na ilha do servidor. Evite situações em que uma mensagem recebida resulte diretamente no envio de outra mensagem, uma vez que o número de mensagens pode crescer rapidamente de forma exponencial quando há uma multidão na scene.
## UI da scene
As UIs da scene podem tornar-se dispendiosas de 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 numa única imagem. Por exemplo, se tiver um menu com vários elementos de texto, o ideal é que o texto dos tiles e quaisquer imagens adicionais sejam incorporados na imagem de fundo. Isso poupa ao engine ter de fazer um drawcall adicional por frame para cada elemento de texto.
{% endhint %}
Evite fazer ajustes à UI em cada frame; isso é especialmente dispendioso e pode acabar por ser enfileirado. Por exemplo, se houver uma barra de vida na sua UI que deva encolher ao longo de um período de tempo, os jogadores provavelmente não notariam diferença se ela atualizasse a 10 FPS em vez de a 30 FPS (em cada frame). O system que atualiza esta barra pode usar um temporizador breve que conta 100 milissegundos e só afetar a UI quando esse temporizador chegar a 0.
Evite ter muitos elementos de UI ocultos; estes também têm impacto no desempenho, mesmo que não estejam a ser renderizados. Quando possível, tente criar componentes de UI sob demanda.
## Monitorizar Desempenho
A melhor métrica para saber quão bem uma scene está a correr é o FPS (Frames Per Second). No Preview, pode ver o FPS atual da scene no debug panel. Deve apontar para ter sempre 30 FPS ou mais.
Na scene publicada, pode alternar o panel que mostra estas métricas escrevendo `/showfps` na janela de chat.
Um dos principais estrangulamentos no desempenho de uma scene é normalmente o envio de mensagens entre o código da scene e o engine.
Quando corre uma scene em Preview, note que no canto superior direito aparece “Y = Toggle Panel”. Carregue em Y no teclado para abrir um panel com alguma informação útil que é atualizada em tempo real.
À medida que interage com coisas que envolvem mensagens entre o SDK e o engine, vai notar que o número de ‘Processed Messages’ aumenta. Deve monitorizar atentamente o número de ‘Pending on Queue’; este deve estar sempre em 0 ou próximo de 0. Isto indica quantas destas mensagens não chegaram a ser processadas e foram colocadas numa fila. Se a contagem de ‘Pending on Queue’ começar a aumentar, então entrou na zona de perigo e deve considerar fazer mais otimizações à sua scene.
{% hint style="warning" %}
**📔 Nota**: Não mantenha o panel aberto quando não o estiver a usar, uma vez que isso tem um impacto negativo no desempenho.
{% endhint %}
Tenha em mente que o desempenho que experiencia em 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 a sua scene podem estar a usar hardware menos potente
É sempre uma boa prática tentar publicar primeiro a sua scene no [ambiente de teste](/creator/content-creator-pt/scenes-sdk7/publicacao/publishing.md#the-test-server) para fazer testes mais aprofundados.
Peça sempre feedback aos jogadores. Nunca assuma que a forma como você experiencia a scene é igual para todos os outros.
---
# 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.