Eu comecei o Petunia3D com uma ideia pequena: um editor para criar assets low-poly rápido — desenhar a silhueta, gerar a malha, fazer UV, pintar. Sem precisar dominar um DCC gigante. Só que, quanto mais eu avançava na interface, mais uma pergunta crescia: até que ponto dá para esconder complexidade sem começar a limitar quem usa?

Essa tensão aparece em todo o projeto. O usuário não deveria precisar entender o funcionamento interno do editor só para extrudar uma forma. Ao mesmo tempo, se eu esconder demais, o artista experiente bate no teto na primeira semana.

O problema com a stack de UI

A escolha óbvia em Rust seria o egui — maduro, immediate mode, muita gente usando. E eu ainda não descartaria ele. Mas parte dos problemas que encontrei pode não estar na biblioteca em si, e sim na tentativa de fazê-la se comportar como interfaces construídas com outra filosofia. Forçar um immediate-mode a parecer um editor dockable tradicional gera uma camada de gambiarra que depois cobra caro em manutenção.

Antes de migrar tudo, eu prefiro o caminho contrário: usar o egui de maneira mais próxima do que ele foi projetado para fazer, aproveitar melhor as bibliotecas auxiliares do ecossistema e medir até onde conseguimos chegar assim.

E as alternativas experimentais?

Ao mesmo tempo, não ficaria só nas soluções mais conhecidas. Rust tem vários projetos de UI novos — Floem, GPUI, Slint, Iced — e mesmo quando ainda não estão prontos para carregar o projeto inteiro, eles costumam trazer ideias que resolvem partes específicas do problema. Uma abordagem de layout aqui, um modelo de reatividade ali.

Entre essas opções, eu não escolheria só pela quantidade de features. A mais madura carrega uma arquitetura maior do que preciso; as experimentais encaixam melhor na separação que quero entre viewport 3D e interface, mas ainda não as colocaria no caminho crítico.

A separação que importa

O que mais me interessa hoje é tratar o renderer 3D e a interface como mundos separados desde o começo. Se o viewport começar a conhecer regras da UI, criamos uma dependência que depois fica difícil de desfazer — e é exatamente esse tipo de acoplamento que mata editores pequenos quando eles crescem.

Para a V1 eu começaria com o stack atual usado do jeito nativo, mantendo a fronteira limpa o suficiente para testar uma GUI alternativa depois sem reescrever o editor.

Como vou decidir de verdade

Em teoria essa separação deveria deixar tudo mais rápido e manutenível, mas eu não consideraria isso resolvido sem medir: frame time com cenas grandes, custo de seleção e hit testing, comportamento em hardware fraco. A arquitetura pode estar mais bonita e ainda assim continuar lenta — e performance em PC modesto é requisito, não bônus.

O próximo experimento é instrumentar esses números antes de qualquer migração. O código está aberto no repositório.