Unity 6.6 tira o WebGPU da fase experimental e o mantém desativado
A Unity lançou o Unity 6.6 em 1º de setembro. É uma versão com suporte, o que significa que recebe o mesmo compromisso de estabilidade de uma LTS até a chegada da 6.7, além de ser a última parada da linha Unity 6 antes dessa LTS. Para quem publica para navegadores, o principal destaque é uma frase da publicação da equipe de Web Graphics feita uma semana antes: "a partir do Unity 6000.6, a API gráfica WebGPU não é mais experimental; agora ela é um recurso totalmente compatível."
A Unity vinha oferecendo o WebGPU como backend experimental desde a versão 6.1, no início de 2025. Nós falamos sobre isso na época e, desde então, acompanhamos a evolução nos navegadores, desde o Safari lançar suporte ao WebGPU até todos os principais navegadores implementarem a API. Agora o motor também se atualizou.
O tour da própria Unity pelas novidades da versão 6.6
O que o WebGPU habilita
O motivo pelo qual o WebGPU é importante especificamente no Unity são os compute shaders. O WebGL 2 nunca teve esse recurso, portanto todas as funcionalidades do Unity que dependiam de computação por GPU simplesmente não estavam disponíveis em builds web. Com o WebGPU selecionado, os builds web passam a contar com GPU Resident Drawer e oclusão por GPU, upscaling com Spatial-Temporal Post-Processing, VFX Graph com partículas simuladas por GPU, Adaptive Probe Volumes e compute skinning. As cenas de demonstração usadas pela Unity na publicação foram Fantasy Kingdom, uma cidade estilizada e densa, e o interior de uma nave espacial repleto de partículas do VFX Graph, ambas executadas em um navegador.
As partículas do VFX Graph são simuladas por GPU, por isso nunca estiveram disponíveis no WebGL 2. Imagem: Unity.
Também há um modo de compatibilidade mais leve para hardwares que declaram suporte ao WebGPU, mas não conseguem lidar com o conjunto completo de recursos. Assim, o mesmo build funciona em mais dispositivos sem que o desenvolvedor precise fazer nada.
O que a Unity decidiu não fazer
O WebGPU não vem ativado por padrão. O WebGL 2 continua sendo a API gráfica padrão para builds web. Para usar o WebGPU, é preciso abrir as configurações do Web Player, desmarcar a seleção automática da API gráfica e adicionar o WebGPU à lista. Em tempo de execução, o Unity testa as APIs por ordem de prioridade e recorre à próxima quando a primeira não está disponível.
O WebGPU precisa ser adicionado manualmente à lista de APIs gráficas. Imagem: Unity.
Duas ressalvas da publicação são do tipo que pode custar um dia de trabalho para quem não prestar atenção. Primeiro, os navegadores só disponibilizam o WebGPU em um contexto seguro. Portanto, um build executado a partir de um arquivo local ou de um host HTTP comum recorre silenciosamente ao WebGL 2, deixando você sem entender por que seus recursos de computação desapareceram. Segundo, nas palavras da própria Unity: "nem todos os dispositivos que declaram suporte ao WebGPU oferecem experiências consistentes." É por isso que a versão 6.6 adiciona o Graphics Device Filtering, um conjunto de regras que força o fallback em navegadores, GPUs ou drivers específicos que você identificou como problemáticos.
O restante das novidades para a web na versão 6.6 envolve tamanho e memória. O WebAssembly64 permite que um build para navegador acesse até 16 GB de memória, em vez do antigo limite de 4 GB, no Chrome e Edge 128 ou posteriores e no Firefox 129 ou posterior. O Progressive Asset Loading entrega os assets cena por cena, em vez de exigir um único download inicial. Assim, o jogador pode começar pela primeira cena enquanto o restante é carregado em segundo plano. Ambos os recursos atacam os dois motivos pelos quais historicamente era difícil convencer alguém a adotar jogos web feitos no Unity: eles eram grandes e ficavam sem memória.
O restante da versão
Fora do navegador, o Fast Enter Play Mode agora é o padrão para novos projetos, recarregando a cena sem fazer um domain reload. A Unity apresenta essa mudança como uma preparação para a migração ao CoreCLR no Unity 7. Finalmente, dicionários passam a ter serialização nativa no Inspector. Uma nova janela Build Analysis acompanha o histórico e as métricas dos builds, enquanto os Content Directories organizam conteúdo local com integração ao Addressables e suporte ao DirectStorage no Windows e no Xbox. O exemplo apresentado pela Unity para as melhorias de shaders é um build cujo tempo caiu de 1 hora e 46 minutos para 32 minutos após a conversão de variantes de palavras-chave em ramificações dinâmicas.
O que isso significa para os jogos web
Nós trabalhamos diretamente com three.js e WebGPU, portanto a promoção do backend da Unity não é tanto uma ameaça competitiva, mas uma confirmação. A computação por GPU no navegador agora é um caminho compatível no motor com a maior base instalada. Isso significa que mais jogos serão lançados dependendo desse recurso, mais jogadores encontrarão casos extremos de compatibilidade e os fornecedores de navegadores sentirão mais pressão para resolvê-los. Escrevemos sobre a situação do WebGPU e do WebGL em jogos e sobre as opções de motores para a web, e a recomendação continua válida nos dois casos: publique com o WebGPU ativado e um fallback para WebGL 2, teste em hardware básico de verdade e trate a frase "o navegador diz que é compatível" como apenas o começo da investigação.
Manter o WebGPU desativado por padrão é a decisão correta para uma versão com suporte, mas também revela algo. A API está pronta. O conjunto de dispositivos ainda não é uniforme, e o motor que precisa rodar em todos eles sabe disso melhor do que ninguém.