Skip to content

O navegador discretamente se tornou uma plataforma real para engines

Por Oleg Sidorkin, CTO da Cinevva

Há dois meses, escrevemos que a renderização no navegador havia tido seu melhor mês de todos os tempos e presumimos que fosse um pico. Não era. Era o início de uma tendência, e essa tendência tem uma direção definida. O navegador está se tornando um lugar onde você lança um jogo de verdade, não um lugar para onde você porta um jogo pequeno.

O que chegou desde março

Vamos à lista. O Babylon.js 9 trouxe iluminação em clusters para milhares de luzes dinâmicas, iluminação volumétrica e uma reformulação completa do splatting gaussiano. O Three.js r184 adicionou HTMLTexture, que renderiza DOM interativo e em tempo real como textura sobre uma superfície 3D. O PlayCanvas v2.17 trouxe splatting gaussiano controlado pela GPU no WebGPU, com harmônicos esféricos f16, ordenação na GPU e descarte por frustum. O Godot 4.7 beta adicionou exportações web em wasm64 que eliminam o antigo limite de 4 GB de memória, além de saída HDR real e luzes de área. O Chrome 146 trouxe um modo de compatibilidade do WebGPU que funciona com OpenGL ES 3.1 e Direct3D 11, enquanto o próprio WebGPU alcançou o status de Recomendação Candidata do W3C. Qualquer uma dessas novidades já tornaria um trimestre notável. Todas chegaram em cerca de oito semanas.

“Bom o bastante para uma demo” virou “bom o bastante para lançar”

Os recursos que chegaram não são brinquedos. A iluminação em clusters é o que permite iluminar uma cena com milhares de luzes dinâmicas sem derrubar a taxa de quadros. O splatting gaussiano é o que permite inserir ambientes capturados com realismo fotográfico em um jogo, mantendo taxas de quadros interativas. A ordenação e o descarte controlados pela GPU fazem a diferença entre uma demo técnica que engasga e um jogo que se mantém a 60 FPS. Essas são as técnicas usadas por engines nativas para lançar jogos AAA, e agora elas rodam em uma aba. O trabalho no modo de compatibilidade é igualmente importante na outra direção. Ele permite que o WebGPU alcance o hardware barato e antigo que a maioria dos jogadores realmente possui, e não apenas máquinas de desenvolvimento com GPUs de ponta.

Temos construído sobre essa base, à mão

Não estamos apenas repetindo o que lemos em um comunicado de imprensa. Passamos os últimos tempos construindo um mundo aberto que roda no navegador, em mais de sessenta experimentos exploratórios, desde implementações básicas e rudimentares de terreno até marching cubes na GPU e LOD com streaming. Documentamos essa jornada em uma série completa e em um artigo mais longo sobre a metodologia. Quase todos os recursos acima correspondem a um problema que enfrentamos do jeito mais difícil. Quando a iluminação em clusters chega a uma engine web popular, isso representa um trecho do nosso próprio código que podemos apagar.

A objeção morreu, o hábito não

“Não dá para fazer um jogo de verdade no navegador” foi verdade por muito tempo, e deixou de ser enquanto a maior parte da indústria estava olhando para o outro lado, em direção à IA. O teto técnico que justificava lançar primeiro um cliente nativo e deixar uma versão web para talvez nunca deixou de existir. O que resta é o hábito. Engines, estúdios e cadeias de ferramentas ainda são construídos com base na premissa de que o navegador é a plataforma inferior.

Essa premissa é a oportunidade. Construímos a Cinevva apostando que o navegador se tornaria o lugar padrão para lançar e descobrir jogos, não uma alternativa de último caso. A pilha de renderização acabou de passar dois meses comprovando essa aposta. Os estúdios que atualizarem primeiro seu modelo mental terão uma plataforma de distribuição sem o atrito da instalação e com um público a apenas um clique de distância. Os que esperarem acabarão portando seus jogos para ela, mas somente depois que todos os outros já estiverem por lá.


Conteúdo relacionado: