Empecé Petunia3D con una idea pequeña: un editor para crear assets low-poly rápido — dibujar la silueta, generar la malla, hacer UV, pintar. Sin necesidad de dominar un DCC gigante. Pero cuanto más avanzaba en la interfaz, más crecía una pregunta: ¿hasta qué punto se puede esconder complejidad sin empezar a limitar al usuario?

Esa tensión atraviesa todo el proyecto. El usuario no debería necesitar entender el funcionamiento interno del editor solo para extruir una forma. Al mismo tiempo, si escondo demasiado, el artista experimentado choca con el techo en la primera semana.

El problema con el stack de UI

La opción obvia en Rust sería egui — maduro, immediate mode, muy usado. Y aún no lo descartaría. Pero parte de los problemas que encontré puede no estar en la biblioteca en sí, sino en el intento de hacerla comportarse como interfaces construidas con otra filosofía. Forzar a un toolkit immediate-mode a parecerse a un editor dockable tradicional genera una capa de soluciones improvisadas que después cobra caro en mantenimiento.

Antes de migrar todo, prefiero el camino contrario: usar egui de una manera más cercana a aquello para lo que fue diseñado, aprovechar mejor las bibliotecas auxiliares del ecosistema y medir hasta dónde llegamos así.

¿Y las alternativas experimentales?

Al mismo tiempo, no me quedaría solo con las soluciones más conocidas. Rust tiene varios proyectos nuevos de UI — Floem, GPUI, Slint, Iced — e incluso cuando aún no están listos para cargar todo el proyecto, suelen traer ideas que resuelven partes específicas del problema. Un enfoque de layout aquí, un modelo de reactividad allá.

Entre estas opciones, no elegiría solo por cantidad de features. La más madura carga una arquitectura mayor de la que necesito; las experimentales encajan mejor en la separación que quiero entre viewport 3D e interfaz, pero aún no las pondría en el camino crítico.

La separación que importa

Lo que más me interesa hoy es tratar el renderer 3D y la interfaz como mundos separados desde el principio. Si el viewport empieza a conocer reglas de la UI, creamos una dependencia difícil de deshacer después — y ese tipo de acoplamiento es exactamente lo que mata a los editores pequeños cuando crecen.

Para la V1 empezaría con el stack actual usado de forma nativa, manteniendo la frontera lo bastante limpia para probar una GUI alternativa después sin reescribir el editor.

Cómo voy a decidir de verdad

En teoría esta separación debería dejar todo más rápido y mantenible, pero no lo consideraría resuelto sin medir: frame time con escenas grandes, costo de selección y hit testing, comportamiento en hardware modesto. La arquitectura puede estar más bonita y seguir lenta — y el rendimiento en PCs modestos es requisito, no bono.

El próximo experimento es instrumentar esos números antes de cualquier migración. El código está abierto en el repositorio.