3D + 2D: teste de engine gráfica WASM multiplataforma

A experiência na Adobe e o nascimento do Renderlet

• Trabalhou na infraestrutura de grandes aplicativos da Adobe, como Photoshop e Acrobat.
• Fazer uma base de código robusta funcionar em desktop, web, mobile e nuvem era uma grande dor de cabeça.
• Para fazer o Lightroom e o Photoshop rodarem na web, passou por um processo complexo envolvendo JavaScript, PNaCl do Google, asm.js e, por fim, WebAssembly.
• Foi necessário repensar a arquitetura de GPU, fazer builds single-thread funcionarem e reorganizar a UI em torno de web components.
• O build web hoje funciona bem, mas chegar até aqui foi uma longa jornada de 10 anos.

O potencial do WebAssembly

• A stack gráfica é a parte que mais gera gargalos de portabilidade.
• Em certo momento, percebeu que o WebAssembly (Wasm) oferecia uma solução para esse problema.
• Wasm pode rodar em qualquer lugar, ser embutido em qualquer coisa e oferece desempenho suficiente para gráficos em tempo real.
• Por isso, largou o emprego e começou a aventura de criar do zero um framework gráfico portátil e embutível baseado em WASM.
• A proposta é oferecer uma camada de alto nível para que desenvolvedores de aplicativos possam criar facilmente os gráficos que desejam, ao mesmo tempo em que disponibiliza recursos de baixo nível para aproveitar ao máximo tudo o que aplicações de alto desempenho exigem, incluindo a GPU.

Apresentando o Renderlet

• O nome Renderlet foi escolhido para enfatizar o aspecto embutível.
• É possível criar e conectar módulos gráficos próprios e interoperar facilmente com qualquer coisa e dentro de qualquer ambiente.
• Assim como a Unity facilitou a criação de jogos multiplataforma, a ideia é fazer o mesmo para todos os aplicativos visuais.

Processo de desenvolvimento e pedido de feedback

• Participou da YC como fundador solo, mas concentrou a maior parte do tempo nos últimos 6 meses em construir este projeto.
• Ainda não está pronto para um lançamento em open alpha, mas deve estar em breve, e ele quer escrever sobre isso, mostrar o projeto e receber feedback.
• Isso é algo com que sonhava como desenvolvedor de aplicativos, e ele quer saber o que as outras pessoas pensam.

A combinação de Rive e Renderlet

• Quando a Rive chamou atenção ao abrir o código do seu engine vetorial 2D, isso despertou interesse.
• O renderer da Rive é construído sobre uma API 2D de alto nível semelhante a SVG, enquanto o renderer Wander do Renderlet expõe uma API 3D de baixo nível sobre a GPU.
• O Renderlet pode executar a biblioteca Rive Renderer usando um backend de GPU, permitindo que qualquer aplicativo 3D tenha um backend vetorial 2D.
• Isso já foi implementado, e é possível ver funcionando no Vimeo e explorar os detalhes técnicos em profundidade no GitHub.

Opinião do GN⁺

• O Renderlet apresenta uma abordagem inovadora para resolver os problemas tradicionais de portabilidade em aplicativos gráficos complexos. Isso pode se tornar uma ferramenta poderosa para desenvolvedores oferecerem uma experiência de usuário consistente em várias plataformas.
• O desenvolvedor do Renderlet, com base em sua experiência na Adobe, entende bem as necessidades reais do mercado e as limitações técnicas, o que aumenta as chances de sucesso do projeto.
• No entanto, como o Renderlet ainda está em estágio inicial e não chegou a um lançamento open alpha, seu desempenho e estabilidade em ambientes reais ainda não foram validados.
• Para que essa tecnologia seja adotada com sucesso, será necessário amplo apoio da comunidade e participação ativa dos desenvolvedores. Como projeto open source, as contribuições e o feedback da comunidade podem influenciar fortemente seu crescimento.
• Outros projetos ou frameworks com propostas semelhantes incluem Unity, Unreal Engine e Godot, mas o Renderlet adota uma abordagem diferenciada com maior foco em leveza e portabilidade baseadas em Wasm.

[GN⁺]

Comentários no Hacker News

• É melhor pular a etapa PAL e ir direto para SetupRuntime. Desenvolvedores que não trabalham com gráficos não conhecem bem esses detalhes, e não é desejável criar etapas extras desnecessárias na API. Como o PAL não é usado em outros lugares, é melhor usar WebGPU. (IPal deveria ser um membro de IRuntime e está pronto para ser removido no contexto do WebGPU).

  • Recomendação de uso do WebGPU: omitir a etapa PAL, iniciar diretamente com SetupRuntime, necessidade de simplificar a API, integração de IPal ao IRuntime e remoção planejada.

• Este projeto pode se tornar um ótimo widget toolkit para criar GUIs multiplataforma e uma base incrível para modelos de interação. O backend em C/C++ e o alvo WASM permitem construir FFI em praticamente qualquer linguagem.

  • Possibilidade de desenvolvimento de GUI multiplataforma: possibilidade de construir FFI em várias linguagens, vantagens do backend C/C++ e do alvo WASM.

• Fico curioso sobre os planos para suporte a texto e fontes. Alguns motores gráficos não oferecem suporte a texto de todas as formas desejadas. A pergunta é se será possível carregar arquivos OTF ou WOFF2 e exibir strings arbitrárias.

  • Pergunta sobre suporte a texto e fontes: suporte a diferentes formas de exibição de texto, possibilidade de carregar arquivos OTF/WOFF2 e mostrar strings.

• Grande interesse no projeto. Há algumas perguntas sobre runtime, event loop, FFI e propriedade de ponteiros de janela. Existe interesse em plugins de áudio e VST, e há restrições quanto ao event loop e ao gerenciamento de janelas. O JUCE é a solução de fato, mas está envelhecido e é incômodo de usar.

  • Interesse em plugins de áudio e VST: perguntas sobre runtime, event loop, FFI e gerenciamento de janelas, com potencial como alternativa ao JUCE.

• Este projeto é realmente incrível e é algo com que venho sonhando há anos. O WASM tem muito potencial como unidade portátil para computação gráfica, de áudio e multimídia.

  • Destaque para o potencial do WASM: possibilidades do WASM como unidade portátil para computação gráfica, de áudio e multimídia.

• Estou trabalhando para fazer o WASM rodar no Godot Engine. Fico curioso sobre como vocês superaram os problemas de acessibilidade do shared array buffer no Safari e a questão do acesso a redes de anúncios, que é importante para jogos online. Também foi apontada a questão entre build single-thread e build normal.

  • Trabalho com Godot Engine e WASM: problemas de acessibilidade do shared array buffer no Safari, acesso a redes de anúncios e questão entre build single-thread e build normal.

• Fico feliz em ver mais projetos na área de gráficos 3D/WASM. Pergunta se há dicas para entrar na YC. Vem portando o Unreal Engine 5 para WebGPU e WebAssembly há anos. Já possui um renderizador multithread e um sistema de streaming de assets, de modo que o usuário não precisa baixar o jogo/app inteiro antes. Além disso, não é necessário carregar a aplicação inteira na memória de uma vez. Também construiu uma plataforma completa de hospedagem e backend para que desenvolvedores possam publicar projetos online.

  • Port do Unreal Engine 5 para WebGPU e WebAssembly: renderizador multithread, sistema de streaming de assets, sem necessidade de baixar o jogo/app inteiro, além de plataforma de hospedagem e backend.

• A apresentação no wasm I/O foi impressionante, e é bom ver esse trabalho recebendo atenção.

  • Reação positiva à apresentação no wasm I/O: conteúdo marcante da apresentação e reconhecimento do trabalho.

• Pergunta se vocês leram o artigo de Ian Hickson, principal desenvolvedor do Flutter. Ele explica o conceito de ter um framework de UI totalmente multiplataforma usando WASM, que é a mesma ideia adotada pelo Flutter.

  • Uso de WASM relacionado ao Flutter: conceito de framework de UI multiplataforma e sua relação com o Flutter.

• Recomenda fortemente o manifold como kernel CAD que pode ser integrado ao app.

  • Recomendação de kernel CAD: sugestão do manifold para integração ao aplicativo.