- A Rive abriu o código do Rive Renderer, desenvolvido internamente, permitindo usar em todas as plataformas uma base única de renderização ajustada ao conteúdo, às animações e aos runtimes da Rive
- O objetivo do renderizador é manter animações a 120fps e alta qualidade de antialiasing mesmo desenhando muitos gráficos vetoriais e texto nítido
- Antes, a empresa dependia de vários renderizadores, como Skia e a HTML Canvas API, e recursos ausentes em um backend dificultavam o lançamento para todas as plataformas
- Com um renderizador único, fica mais consistente adicionar efeitos como blur, drop shadow, glow, tapered stroke em vários runtimes
- A implementação reduz caminhos vetoriais com antialiasing a patches triangulares e aproveita o pipeline paralelo de rasterização de triângulos da GPU; pode ser ativada em iOS, Android e Web, e já está integrada aos runtimes de Unity e Unreal
Lançamento do Rive Renderer e contexto de desenvolvimento
- O Rive Renderer é um renderizador desenvolvido internamente para o conteúdo, as animações e os runtimes da Rive
- Ele tem como meta entregar animações a 120fps e qualidade limpa de antialiasing mesmo em situações com muitos gráficos vetoriais e texto na tela
- O desenvolvimento interno levou 2 anos e deu à Rive um controle mais direto sobre toda a experiência, desde o momento em que os designers criam no Rive Editor até quando os usuários visualizam e interagem no runtime
- O sistema foi otimizado para gerar intencionalmente apenas conteúdo que rode com rapidez no runtime, permitindo que designers se preocupem menos com a implementação de performance e foquem mais na criação
Limites da estrutura com vários renderizadores e efeito de um renderizador único
- No início, a Rive usava soluções de renderização open source já existentes, como Skia e a HTML Canvas API
- A estrutura bring-your-own-renderer, que permite ao usuário conectar facilmente o renderizador de sua escolha, continua sendo suportada
- Mas, sem um renderizador próprio consistente e otimizado, o roadmap do produto e o desenvolvimento de novos recursos acabavam presos a limitações de cada plataforma
- Em uma estrutura com vários renderizadores, quando um recurso não existe em um deles, ele não funciona em todos os backends onde a Rive roda, o que dificulta lançar esse recurso
- Entre os efeitos que ficam mais fáceis de adicionar com um renderizador único estão blurs, drop shadows, glows, tapered strokes
Como funciona a implementação e suporte a plataformas
- O Rive Renderer se baseia em uma abordagem geométrica que reduz caminhos vetoriais com antialiasing a patches triangulares exclusivos
- Ela aproveita o pipeline massivamente paralelo de rasterização de triângulos disponível por padrão em GPUs de desktop e mobile
- Usa hardware 3D para desenhar curvas de Bézier com um método específico de triangulação
- O uso de renderizadores de terceiros continua possível, mas o Rive Renderer é recomendado para os recursos próprios da Rive e para a experiência geral
- Em iOS, Android e Web, é possível ativar o Rive Renderer seguindo a documentação oficial
- O código está disponível no GitHub, já integrado aos runtimes de Unity e Unreal, com mais integrações previstas
1 comentários
Opiniões no Hacker News
Acabei de estar no estande da GDC, e pareceu realmente ótimo como um programa que permite que designers de UI/UX façam mais coisas diretamente em jogos
Normalmente, o designer passa alguns dias trabalhando no Figma e depois entrega para o programador, que responde que não dá para implementar por este ou aquele motivo, e o vai e vem continua
Isso fica ainda pior porque a Unreal Engine não tem um bom framework de UI adequado para jogos AAA, mas o fluxo de trabalho dessa ferramenta é o melhor que vi até agora e parece se integrar naturalmente à Unreal Engine e aos Blueprints
Pessoalmente, estou bem animado porque parece permitir que designers de UI/UX trabalhem sem ajuda de programadores. Programadores de jogos, em geral, também costumam odiar trabalho de UI
Parece algo explicável pela diferença de mentalidade entre sentar para trabalhar e sentar para jogar
Foi quase o primeiro momento em que me senti como um velho gritando que a versão moderna é terrível demais
Há muita pesquisa ativa em renderização de gráficos vetoriais 2D com tesselação na GPU, e é bem legal ver uma tecnologia nessa linha, como o trabalho do Raph Levien, chegar a um produto real
Nunca usei Rive, então fico curioso se ele é dedicado a criar animações bonitas ou se também dá para criar UIs dinâmicas do tipo que se faria com uma biblioteca de GUI em modo imediato
https://rive.app/game-ui
https://rive.app/blog/how-age-of-learning-uses-rive-to-a-b-t...
Já criei UIs bastante complexas com Rive, mas ainda não explorei a área de adicionar elementos programaticamente ou alterar textos da UI conforme eventos externos
Acho que esse experimento já foi feito com Flash. A Macromedia/Adobe distribuía o player de graça e cobrava pelas ferramentas; o Rive também parece querer abrir o player como open source e cobrar pelo editor
O Rive é um pouco diferente, pois parece mirar desenvolvedores de jogos que usam outras plataformas, como Unity ou Unreal, por exemplo quem quer embutir coisas como cinemáticas
Ainda assim, ter um player open source significa que o Rive quer controlar a experiência inteira, e isso me lembra Flash
Venho esperando isso desde o anúncio. Antes, eles usavam Skia, e o app inteiro e a saída de renderização eram feitos em Flutter. Agora o Flutter tem um novo motor de renderização, o Impeller, mais otimizado para problemas específicos do Flutter do que o Skia
Quando perguntei anteriormente à equipe do Impeller o que achavam do renderer da Rive, disseram que ele é excelente para gráficos vetoriais, mas que o Impeller também precisa lidar com problemas de renderização relacionados a UI, como exibir texto corretamente, então não são comparáveis um a um
Agora que esse renderer virou open source, espero que as duas equipes possam aprender uma com a outra
Gosto do produto e da empresa Rive, e também gosto de open source, mas isto é a abertura sob licença MIT de uma camada de abstração de renderização que faz parte do runtime do Rive, para o qual o conteúdo precisa ser criado no Rive Editor
Fico curioso sobre o objetivo da abertura do código e que comunidade maior eles querem construir em torno disso
Também me pergunto se há outros projetos que poderiam se beneficiar apenas adotando o renderer
Pessoalmente, também tenho interesse. Atualmente uso canvasAPI e pixi, e frequentemente esbarro nos limites de desenho 2D dentro do orçamento de frame de 16 ms
[0] https://github.com/rive-app/rive-renderer
Parece realmente incrível, a ponto de eu querer usar em um projeto pessoal de hobby
Como parece oferecer uma API Cairo/Skia/canvas/NanoVG mais ou menos padronizada, com coisas como moveTo e lineTo, espero que não exija muito esforço para aprender
Pelo menos aqui aparece lineTo: https://github.com/rive-app/rive-renderer/blob/main/renderer...
Fico curioso para saber como esse desempenho de renderização se compara ao Skia ou ao Pathfinder. O Pathfinder também consegue, se o hardware der suporte, processar na computação da GPU a etapa de transformar caminhos em triângulos
Como uma abordagem mais abrangente de renderização 2D baseada em compute, também existe o Vello
Minha avaliação inicial é que o desempenho provavelmente depende muito do hardware, especialmente do suporte a pixel local storage. Pelo que vi até agora, Apple Silicon é o ponto ideal. Ele dá suporte em hardware a binning e ordenação por tiles, e funciona bem mesmo serializando a execução do fragment shader dentro do tile
Em outros hardwares, imagino que o custo dessa serialização de chamadas seja bem maior
Um dos motivos pelos quais ainda não fiz benchmarks profundos no Vello é que a história de desempenho ainda não está completa. Atualmente há um problema ao coletar bounding boxes com operações atômicas de dispositivo, e uma implementação protótipo[2] que usa monoides para redução de segmentos mostra resultados bem melhores
Além disso, há planos de usar operações f16, o que pode trazer ganhos grandes, especialmente em mobile. Para várias etapas de somas prefixadas, a ideia é usar subgrupos, que estão entrando no WebGPU[3]
No geral, fico feliz que este renderer tenha sido lançado como open source, e também é bom ver mais atividade em renderização rápida de gráficos vetoriais na GPU. Quero ver um futuro em que a renderização de caminhos na CPU seja considerada ultrapassada, e esta abertura nos aproxima mais dessa direção
[1]: https://dawn.googlesource.com/dawn/+/refs/heads/main/docs/da...
[2]: https://github.com/linebender/vello/issues/259
[3]: https://github.com/gpuweb/gpuweb/issues/4306
Parece um conjunto sólido de escolhas técnicas feito por pessoas que sabem o que estão fazendo, e vale muito a pena conferir diretamente o desempenho e a qualidade
Esses renderers com GPU em primeiro lugar têm abordagens ligeiramente diferentes, e é bem provável que cada um tenha áreas em que seja o melhor dentro de um espaço multidimensional de qualidade, desempenho, suporte a hardware/driver e dificuldade de integração. Se um dos quatro não agradar, vale verificar os outros
Pessoalmente, fico muito feliz com isso
Nos últimos cerca de 6 meses, venho defendendo a adoção do Rive em vez do Lottie e de soluções antigas para vários clientes, de empresas de saúde com apps mobile nativos a empresas e produtos profundamente ligados a games. Agora finalmente vejo isso entrando nos trilhos e em estado “pronto para adoção”
Nessas discussões, a última preocupação potencial que restava era o fato de o renderer mais novo ser fechado e ainda não estar em sua forma final
Com esta decisão e o trabalho geral da equipe do Rive, estou animado com a possibilidade de esse espaço de problemas continuar melhorando. Recursos como sombras e blur também serão muito interessantes quando forem lançados
Lottie está se consolidando bastante como formato de arquivo, tem um fluxo de trabalho bem estabelecido e é relativamente simples
Fico curioso para saber o que o Rive faz muito melhor a ponto de valer a pena promovê-lo
Repositório: https://github.com/rive-app/rive-renderer
Relacionado: https://news.ycombinator.com/item?id=39754770 (Build System Schism: The Curse of Meta Build Systems)
Esse problema parece continuar gerando softwares que tentam resolvê-lo, sem uma solução definitiva
O motivo disso parecer um pouco estranho é que, dada uma função de amostragem de pixels e uma métrica de espaço de cores, existe uma renderização objetivamente correta para qualquer cena de gráficos vetoriais. Cada valor de pixel de saída deveria ser a cor representável mais próxima da convolução dessa função com a cena, e a cena pode ser representada como uma função de R^2 para R, enquanto as cores podem ser representadas em um sistema de cores linear
Parece possível conseguir isso lidando bem com computação em GPU e com os limites de erro ao calcular numericamente a tesselação de curvas ou a integração simbólica exata de curvas
Além disso, uma solução assim também parece facilitar o ajuste do nível de aproximação para uma renderização mais rápida
Se tivéssemos apenas um computador paralelo decente, não seria tão difícil, mas, na prática, é preciso adaptar a lógica de renderização a uma combinação específica do amontoado de hacks suportado pela infraestrutura de GPU, e cada um deles tem restrições e trade-offs muito peculiares
Acho que você vai gostar do artigo que está por sair sobre expansão de strokes amigável a GPUs. O ponto central é justamente lidar, com métodos numéricos que têm limites de erro, com a integração simbólica exata de uma determinada métrica de curvatura de curvas
Se tiver curiosidade, já dá para ver isso no código shader/flatten.wgsl do main do Vello