- O CADmium tinha como objetivo ser um CAD 3D paramétrico open source executado no navegador, mas atualmente foi descontinuado, e o repositório no GitHub permanece arquivado
- O centro do projeto estava em recombinar um solver de restrições 2D, um kernel b-rep, rastreamento de histórico, UI 3D e formato de arquivo, mantendo uma experiência familiar para usuários de CAD existentes
- Para resolver restrições 2D, a ideia era usar convergência iterativa como em uma simulação física de mola-massa-amortecedor, em vez de resolver uma matriz enorme de uma só vez
- Para o kernel b-rep, pretendia-se usar o Truck, open source em Rust, considerado adequado para execução no navegador graças ao WebAssembly e aos bindings JavaScript
- O formato de arquivo mirava um formato centrado em texto baseado em JSON e JSON Lines, pensando em CLI, git-diff, modificações por scripts e um ecossistema de colaboração e ferramentas auxiliares
Status e objetivo do projeto
- O CADmium era um projeto para criar um novo programa CAD open source
- Atualmente, o projeto foi descontinuado, e o repositório no GitHub é disponibilizado como arquivo
- A distribuição não é mantida
- PRs não são aceitos
- O Discord ainda existe, mas não está ativo
- Os componentes pretendidos para um CAD 3D paramétrico eram cinco
- Solver de restrições 2D
- Kernel b-rep
- Rastreador de histórico
- Interface de usuário 3D
- Formato de arquivo
Abordagem para o solver de restrições 2D
- A abordagem tradicional agrupa todas as incógnitas em um grande vetor, expressa cada restrição como uma equação linear e resolve tudo como uma enorme equação matricial
- Essa abordagem tem a limitação de que a matriz precisa ser quadrada para se obter a matriz inversa
- Se houver restrições demais, a matriz pode ficar comprida e falhar
- Mesmo que restrições redundantes sejam compatíveis entre si, podem surgir problemas por excesso de restrições
- Se houver restrições de menos, o sistema insere suposições para encontrar uma solução, mas elementos do esboço podem sair voando para longe, contrariando a expectativa do modelador
- À medida que o número de incógnitas cresce, grandes equações matriciais ficam mais lentas, o que levou à prática de manter esboços individuais pequenos e simples
- A alternativa do CADmium é tratar o problema de restrições 2D como uma simulação física
- Cada ponto tem massa e velocidade
- Cada restrição se comporta como uma mola que aplica força aos pontos conectados
- Há uma força de atrito proporcional à velocidade
- A simulação avança em pequenos intervalos de tempo até convergir
- Em vez de resolver o problema inteiro de uma vez, pequenas mudanças são repetidas para levar a energia potencial das molas a 0
- O tempo de execução de cada etapa temporal é linearmente proporcional ao número de molas e ao número de incógnitas, então há potencial para lidar com esboços mais complexos
- A abordagem por simulação combina bem com paralelização e também pode ser executada em um compute shader
- Em problemas com restrições demais, se o sistema for internamente consistente, ele é resolvido normalmente; se for inconsistente, as molas encontram um ponto de compromisso
- Problemas com restrições insuficientes encontram a configuração válida mais próxima em vez de disparar ao infinito
- Essa abordagem também pode suportar restrições de desigualdade
- Limitar um comprimento para ser maior que 1 cm e menor que 2 cm
- Limitar o ângulo de um esboço entre 10 e 30 graus
- Ela também pode ser estendida com outras forças, como tratar uma área específica de um polígono fechado como uma força de pressão
- O objetivo básico é oferecer uma experiência que a maioria dos usuários de CAD considere familiar, mas havia espaço para aplicar novas ideias à resolução de restrições 2D
Kernel b-rep e Truck
- Em CAD mecânico, o usuário precisa lidar diretamente com as arestas e faces das peças
- CAD paramétrico usa Boundary Representation, ou b-rep, que representa diretamente as fronteiras da peça como uma estrutura de dados
- Um cubo é representado como um Solid com 6 Faces
- Cada Face tem 4 Edges
- Cada Edge tem 2 Points
- Em superfícies curvas, superfícies NURBS são comumente usadas, permitindo o controle de formas livres e a representação exata de seções cônicas
- b-rep já é difícil apenas como representação geométrica, e a dificuldade aumenta muito ao implementar boolean operations como Union, Intersection e Subtraction
- A biblioteca que lida com esses dados e operações booleanas é um kernel b-rep
- As principais empresas de CAD proprietário criaram seus próprios kernels ao longo de décadas, e kernels proprietários são considerados bons, mas caros
- No lado do CAD open source, o OpenCascade é tratado como o único kernel b-rep open source popular
- É gratuito, mas considerado possivelmente áspero e instável
- Também se aponta que a tela das instruções oficiais de build parece um ambiente Windows antigo
- Truck é um novo kernel b-rep open source em Rust em desenvolvimento
- O repositório no GitHub está disponível publicamente
- Foi escrito em Rust e tem excelente suporte à compilação para WebAssembly
- Pode ser executado em sistemas operacionais e no navegador
- Oferece bindings JavaScript e exemplos
- Isso não significa que Rust seja categoricamente melhor que C++, mas há muitas vantagens importantes para projetos open source
- As ferramentas de build são poderosas, convenientes e bem documentadas
- Há gerenciamento centralizado de pacotes
- Mais garantias de segurança de memória tornam a paralelização mais fácil e segura
- Erros do compilador são amigáveis, facilitando refatorações
- O Truck é um projeto de cerca de 4 anos e é avaliado como já tendo funcionalidades básicas
- Leitura e escrita de arquivos
.step
- Triangulação de superfícies baseada em tolerância fixa
- Suporte a NURBS
- Intersection ou Union de dois Solids, e operação Not de um único Solid
- O Truck é pequeno e leve, e está sendo desenvolvido por uma empresa chamada Ricos
- Também existe a possibilidade de suportar T-Splines em vez de B-Splines, que é o que o B em NURBS significa
- A patente de T-Splines era detida pela Autodesk, mas teria expirado algumas semanas antes
- Em teoria, seria possível adicionar suporte ao Truck
Rastreamento de histórico e ideia de controle de versões
- CAD paramétrico armazena o Feature History do projeto
- A peça é criada empilhando operações como esboços, extrusões e revoluções
- É possível voltar a uma etapa anterior, alterar valores e executar novamente os recursos para obter uma peça diferente
- Ao injetar variáveis como entradas no modelo e alterar seus valores, a peça é atualizada, tornando o modelo parametrizado
- Essa abordagem foi bem-sucedida, mas tem fragilidades como o Topological naming problem, além de haver críticas ao próprio paradigma de CAD paramétrico
- Como abordagem para reduzir fragilidades, surgiu a Resilient Modeling Strategy
- Como chamfer e fillet consomem edges, eles são colocados no fim
- Detail features podem referenciar Core features, mas não referenciam umas às outras
- Se um programa CAD impuser esse tipo de padrão, isso pode parecer uma limitação no início, mas pode facilitar a reutilização e a transferência de projetos
- Há uma ideia de adicionar feature history também aos esboços
- Nos CADs atuais, desenham-se recursos básicos como círculos e retângulos, e depois eles são duplicados e modificados com mirror, linear pattern, sketch fillet etc.
- Esse grafo de dependências é difícil de entender para quem não o criou, e muitas vezes é mais rápido apagar o esboço e começar de novo
- Se sketch features também forem salvos e exibidos na feature tree, as ideias de RMS podem ser aplicadas a um único esboço
- Também inclui a ideia de registrar todos os eventos do usuário em um append-only log
- Se o log for a única fonte da verdade do arquivo, um slider de tempo pode reconstruir um Feature History específico
- Undo/Redo ilimitado se torna possível mesmo após fechar e reabrir o arquivo
- A partir de uma versão passada, é possível ramificar em outra direção e criar uma árvore de tentativas de projeto semelhante ao histórico do git
- O objetivo é uma aplicação CAD em que seja fácil recuperar qualquer estado válido do documento
- Todas as tentativas e erros
- Todos os resultados “finais”
- Estados passados cuja necessidade você não sabia que teria
- Com essa estrutura, é possível manter várias variações de uma peça e também registrar o estado do projeto quando processos downstream como toolpath generation ou FEA foram executados
- A ideia continua: se for possível criar um git para projeto mecânico, não seria possível criar também um GitHub para projeto mecânico?
Interface de usuário 3D baseada no navegador
- O CADmium mira uma forma de fazer CAD no navegador
- O Onshape abriu caminho, mas na prática é descrito como algo que roda em instâncias de nuvem da AWS com GPU ativada e transmite o resultado para o navegador
- Se a conexão com a internet cair, nem mesmo é possível girar a viewport
- Como o Truck pode ser compilado para WebAssembly, o CADmium poderia ser um app Local-First que processa tudo dentro do navegador
- A stack tecnológica usada foi a seguinte
- Three.js: viewport 3D
- Svelte: gerenciamento de estado e reatividade
- Threlte: conexão entre Svelte e Three.js
- Troca de mensagens entre a UI e o kernel b-rep
- Electron: execução local
- TypeScript, TailwindCSS, Vite etc.
- Essa stack permite escrever o app inteiro de forma reativa e declarativa, conectando alterações de dados até a atualização das malhas
- Apps de CAD 3D estão entre as UIs mais complexas; para uma equipe pequena criar um bom produto, o framework precisa assumir boa parte do trabalho
- Como foi criado um proof of concept funcional com essa stack, essa parte não era vista como o fator limitante do CADmium
Formato de arquivo JSON e ecossistema CLI
- O CADmium pretendia usar JSON para tudo
- Para o Operation Log, o plano era usar JSON Lines
- Depois de projetar uma peça, deveria ser possível exportá-la para um formato de intercâmbio mais simples
- O formato de exemplo é uma estrutura JSON que contém operações como
sketch e extrude em um array steps
- Há um exemplo de uso da CLI do CADmium para converter arquivos
.cadmium em .step ou .stl
$ CADmium export my_part.cadmium --format stl
- Os dois elementos necessários para criar um ecossistema são
- Um formato de arquivo simples e fácil de entender
- Uma CLI open source capaz de lidar com esse formato
- Há um caso de uso em que se altera a profundidade de extrusão ou o raio de fillet em um editor de texto
- Também seria possível um caso de uso em que um script troca todos os parafusos M5 por parafusos M6 sem ler uma especificação complexa como a ISO 10303-21
- Se um GitHub para projeto mecânico for criado e de fato usado, também é possível imaginar um GitHub Copilot para projeto mecânico
- A avaliação é que grandes modelos de linguagem funcionam melhor com formatos simples, abertos e baseados em texto do que com formatos binários proprietários complexos
Ajuda necessária e áreas deixadas em espera
- Não se sabe quais ideias terão sucesso ou fracassarão, mas acredita-se que nessa área há oportunidade para um pequeno grupo causar grande impacto na manufatura
- A ajuda necessária é a seguinte
- Programação em Rust e melhorias gerais
- Geometria computacional para patches no Truck
- Suporte com Three.js
- Novo controlador de câmera
- Iluminação melhor
- Pós-processamento
- Encontrar oportunidades de subsídios ou patronos ricos
- Áreas que não serão tratadas agora, mas que se gostaria de revisitar depois
- Venture capital
- toolpath generation, ou CAM
- Finite Element Analysis, ou FEA
- O servidor Discord do CADmium ainda existe, mas, segundo o aviso de status do projeto, não está ativo
1 comentários
Comentários do Hacker News
Estou muito animado com o que o Matt está construindo. O mundo precisa desesperadamente de um CAD paramétrico open source com UI/UX tão fácil de usar quanto o SolidWorks
O maior motivo de isso não ter dado certo até agora é que não existia um kernel paramétrico suficientemente poderoso, e o Truck que o Matt está usando parece exatamente o tipo de projeto necessário. Antes, o OpenCascade era praticamente a única coisa que chegava perto, mas faltam recursos importantes e há muitos bugs e instabilidade
Se o Truck e o CADmium conseguirem fillets estáveis, podem se tornar o verdadeiro sucessor do OpenCascade e a plataforma que vai definir o futuro do CAD paramétrico open source
Mudei recentemente para o Alibre Atom3D; não é open source, mas você paga 200 dólares uma vez só. Enquanto o sistema operacional hospedeiro não mudar drasticamente, você pode continuar abrindo seus projetos, e ele roda sobre o kernel ACIS
Quando vejo "browser-first" e a frase no README sobre "monetizar com uma versão hospedada paga", isso me passa a impressão de que esse projeto pode perder força ou crescer até virar um produto open-core com assinatura obrigatória, com mais dependências de instalação e recursos de segurança, tornando cada vez mais difícil executá-lo de verdade localmente
Testei a versão semanal com o tema OpenDark e ela parece bem polida. Parece mesmo um momento muito interessante para o CAD open source
Quanto mais uso plataformas de CAD, mais sinto que aplicações especializadas, voltadas para domínios de problema específicos, são muito mais úteis do que um CAD genérico. Exportar SVG/DXF/DWG é uma vantagem, mas acho equivocada a direção de um software de desenho que tenta lidar com peças mecânicas produzidas em massa, arquitetura pontual, rodovias, dutos de 50 milhas, circuitos, planejamento de tráfego urbano e arte, tudo ao mesmo tempo
Eu uso o software padrão da indústria para projeto viário, e mesmo assim o modelo de objetos não contém uma entidade "estrada". Componentes horizontais, verticais e de seção transversal não podem ser separados e têm regras claras de interação, mas ainda assim são definidos de forma independente. O projetista deveria gastar menos tempo dizendo ao computador como mostrar algo e mais tempo pensando no resultado em si
Fico curioso por que o QCAD quase nunca é mencionado no HN quando o assunto é ferramenta CAD ou open source
1 - https://www.qcad.org/
Como um dos mantenedores do Solvespace, eu acrescentaria algumas coisas: restrições 2D sozinhas não bastam, e restrições 3D são melhores. Se você fosse escrever isso em C++, eu diria para reutilizar o resolvedor de restrições do Solvespace, como o Dune3D fez, mas se você gosta de Rust, vale olhar o trabalho que Michael F Bryan escreveu em Rust e sobre o qual publicou no blog
https://adventures.michaelfbryan.com/posts/constraints-part-...
No lado do kernel geométrico, há 3 tipos de bugs no kernel do Solvespace que eu queria corrigir, e se resolvesse só isso já daria para ter operações booleanas bem estáveis, mas faltou tempo. Nosso kernel tem menos de 6 mil linhas, então há muito o que aprender com ele. Se quiser entrar em contato sobre isso, pode mandar e-mail para o gmail com este mesmo ID. Faz um tempo que não olho o Truck e eu achava que ele tinha meio que estagnado. Este é um problema realmente difícil, e mesmo no mundo comercial há poucas opções. Até triangular shells NURBS recortadas já é complicado
A árvore de histórico/recursos está intimamente ligada ao problema de topological naming do FreeCAD. O Solvespace lida com isso gerando cada entidade a partir de um conjunto de coisas conhecidas. Se tentar reconstruí-la, em vez de criar uma nova entidade ele retorna o identificador da entidade existente. Em outras palavras, toda entidade "veio de alguma coisa" e se lembra dessa relação. Isso funciona perfeitamente na parte em que lidamos com topological naming, mas não cobre todas as partes do Solvespace. Não é algo que dá para acrescentar facilmente depois; precisa estar presente desde o início
E também queria um link de onde posso testar o CADmium
[1] https://github.com/thekakkun/rust_slvs
Github:
https://github.com/MattFerraro/CADmium
O link está aqui:
https://mattferraro.github.io/CADmium/
Acho que é um trabalho realmente impressionante. Tomara que o CAD físico de código aberto chegue ao nível que o EDA de código aberto alcançou
Dizem que resolver essas equações matriciais fica lento demais quando o número de incógnitas cresce, então surgiu a noção de que cada sketch precisa ser pequeno e simples, mas, quando se investiga a fundo, na prática isso não parece ser um grande problema
Os problemas de desempenho de restrições no FreeCAD vêm principalmente de algoritmos de layout de GUI redundantes e desnecessários, e ele desmorona já com algumas centenas de restrições. A decomposição QR esparsa do Eigen leva cerca de 18 segundos com 2200 restrições, o que não é ruim. Também existem bibliotecas de decomposição QR esparsa que processam 500 mil a 1 milhão de restrições em algo como 18 segundos. É difícil imaginar uma situação em que um sketch de CAD tenha mais de alguns milhares de restrições
[1]: https://github.com/FreeCAD/FreeCAD/issues/11498#issuecomment...
Está sendo usado nas restrições de montagem do FreeCAD e do Ondsel ES
Aprendi CAD há muito tempo com Autodesk Inventor, e o único software de modelagem gratuito que consegui entender depois de mexer por algumas horas foi o Onshape. Nesta área, usabilidade realmente parece ser um grande problema
Por exemplo, no FreeCAD parecia haver bilhões de maneiras de fazer a mesma coisa, mas no fim só existia um jeito certo, e alguns tutoriais acabavam deixando um modelo que não servia
Trabalho muito legal, e parece um problema difícil
Repo: https://github.com/MattFerraro/CADmium
Quase só uso os workbenches Part Design, Sketcher e Spreadsheet. Esses três normalmente funcionam bem juntos. A interoperabilidade entre workbenches é ruim, então dá até medo de expandir para outras áreas. Às vezes também uso o workbench Part, mas, para usar no Part Design, é preciso passar por duas conversões de formato interno, o que é complicado demais
Espero que um dos muitos projetos de CAD de código aberto substitua o FreeCAD algum dia
Não era prático, mas o modelo funcionava até no celular
Também dá para usar o Fusion360, mas, comparado aos pacotes comerciais que já usei, a experiência de usuário é bem horrível
O que eu queria de um CAD gratuito é que alguém trouxesse a robustez e a velocidade do Creo e combinasse isso com a facilidade do SolidWorks. No começo, tudo bem se os recursos forem bem limitados
O processo era: seguir um tutorial que me levava até 80%, improvisar o resto, perceber que aquele tutorial básico tinha estruturado o projeto de um jeito que tornava impossível completar os 20% finais, tentar corrigir etapas anteriores e ver o projeto inteiro desmoronar. E repetir isso
Em CAD, a ordem de trabalho costuma ser tão importante assim? Entrei achando que era um objeto simples e que o FreeCAD não poderia ser tão difícil, mas na prática foi muito difícil
É interessante ver um novo entrante nesta área, especialmente tentando criar um novo kernel, mas a chance de sucesso parece baixa. Os kernels de ponta do setor vêm sendo desenvolvidos há décadas por doutores em CAGD e programadores, com financiamento de empresas automotivas e aeroespaciais. Levará muito tempo só para chegar a um conjunto de funcionalidades minimamente competitivo
Também fico em dúvida sobre qual problema de usuário eles estão tentando resolver. Usuários de CAD não precisam necessariamente de open source. Pode haver restrições de orçamento, mas nesta área open source talvez não seja algo visível diretamente ao usuário como é em ferramentas de desenvolvimento. O Plasticity mostrou que é possível ganhar dinheiro numa faixa de preço baixa mesmo licenciando o Parasolid
Uso ferramentas de CAD paramétrico há mais de 30 anos, e o Onshape é uma solução bastante impressionante para vários problemas que existem no Creo e no SolidWorks. Um ambiente de CAD colaborativo como o Google Docs, em que os dados não se perdem e há desfazer ilimitado construído desde o início sobre banco de dados, e não sobre sistema de arquivos, muda a vida. Mas os recursos de modelagem ainda estão correndo atrás de outras ferramentas
O grande problema de Onshape, Creo e SolidWorks é que eles partem de esboços 2D e depois fazem extrusão, revolução e loft para objetos 3D. As ferramentas 3D são mais um complemento da estrutura básica e quase uma consideração posterior. Plasticity, Rhino e Alias são muito mais 3D-first
O FeatureScript do Onshape é muito legal e poderoso, mas não é tão bom quanto o Grasshopper do Rhino para usuários de CAD criarem suas próprias ferramentas
O CADmium precisa focar em qual mercado ele pode ser uma ferramenta de CAD melhor que as alternativas pagas e gratuitas, e em qual problema de usuário vai resolver. Mesmo no início do desenvolvimento, ainda não é cedo demais para entender as necessidades dos usuários. Open source não é um objetivo por si só
Com ferramentas modernas, o aprendizado tirado de engines antigas e a ausência de dívida de entrada, até uma equipe pequena pode criar algo no mesmo nível ou melhor que um software de 30 anos
Acho que uma equipe pequena e dedicada pode criar um novo kernel paramétrico e pacote CAD. Especialmente se for open source, isso parece ainda mais viável
Usuários de CAD podem se beneficiar muito de uma boa alternativa open source
Em contrapartida, há muitos motivos para evitar software proprietário, e isso é ainda mais forte no caso de SaaS. Hoje em dia tudo está indo cada vez mais para SaaS, e este caso também. Software CAD é uma área em que muitos usuários já investiram centenas de horas para aprender e usar, só para depois serem prejudicados quando sistemas proprietários mudam as condições oferecidas
Sei que devo ser minoria, mas para mim open source é um objetivo absoluto em si. Uso apenas software open source há muito tempo
Ainda assim, não entendo muito bem a parte de que open source não pode ser um objetivo. É parecido com a relação entre KiCAD e Altium. Se for possível oferecer em open source 90% do que o Onshape oferece, acho que as pessoas usariam
Entendo a questão do custo. Uma licença do SolidWorks fica em algo como 3 mil a 5 mil dólares, então a maioria das empresas vai pagar por uma ferramenta validada e usá-la
Só como referência, o Onshape foi feito com menos de 10 milhões de dólares até chegar a um MVP em 3 anos. Hoje em dia não acho que seja necessariamente preciso décadas de trabalho de doutores para criar um novo programa CAD
Foi um excelente resumo do ecossistema de kernels CAD
Gostei especialmente da frase: "o único kernel B-rep open source realmente popular é o OpenCascade, que é o Pontiac Aztek do mundo dos kernels B-rep. É feio, tem só o básico e pode quebrar, mas anda e você pode conseguir de graça"
É exatamente isso mesmo
Fico me perguntando por que isso precisa ser no navegador se a proposta é local-first.
O Solvespace tem a vantagem de ser um único arquivo para baixar e executar.
Além disso, o resolvedor de restrições também foi usado em projetos como CADsketcher e Dune 3D: https://github.com/dune3d/dune3d
O autor disse que acabou usando diretamente o resolvedor do Solvespace porque o código wrapper não expunha todos os recursos necessários e que precisou fazer patches no resolvedor para resolver equações simbolicamente onde fosse aplicável, a fim de torná-lo rápido o suficiente para os tipos de equações gerados.
Também fiquei curioso se isso tem alguma relação com https://github.com/jay3sh/cadmium
O Manifold também não foi mencionado como kernel CAD: https://github.com/elalish/manifold/wiki/Manifold-Library Entendo que ele tem muitas das mesmas desvantagens do OpenCASCADE, mas ainda assim parece digno de menção.
Esse kernel também já foi discutido aqui antes: https://news.ycombinator.com/item?id=35071317
O histórico completo e a possibilidade de edição parecem especialmente interessantes e promissores. Se esse histórico pudesse ser listado em um painel que desse para abrir e fechar, com triângulos de expansão para ocultar os elementos concluídos e permitir foco no trabalho atual, para mim seria um sonho realizado. Isso, claro, se eu conseguisse entender a parte 3D. Até hoje falhei com BRL-CAD, FreeCAD, Solvespace, Alibre Atom etc., e só tive sucesso com ferramentas baseadas em código, parecidas com OpenSCAD.
Poder projetar peças em casa, ajustar no trabalho e fabricar em um makerspace com o equipamento disponível, sem precisar instalar nada, é uma grande vantagem.
Já considerei trocar o código de malha triangular do Solvespace pelo Manifold, mas é muito trabalho, e o que realmente precisamos é corrigir os bugs de NURBS para depender menos do código de malha.
Aliás, o resolvedor de restrições do Solvespace também é usado no workbench Assembly 3 do FreeCAD. Ele está se espalhando bastante por aí ultimamente.
Concordo que um app de CAD 3D tem uma das UIs mais complexas que existem.
Ainda assim, sou cético quanto à ideia de que, para uma equipe pequena criar um bom CAD 3D, um framework precise fazer grande parte do trabalho. Tenho dúvidas de que um framework de UI de uso geral possa ser a solução de longo prazo para CAD 3D.
Às vezes, uma boa UX precisa considerar ao mesmo tempo modelos 3D paramétricos, aproximações de malha, projeção em linhas e patches após remoção de superfícies ocultas, pixels do frame buffer e widgets da UI. Frameworks assumem demais que a informação pode ser facilmente separada e que seu tamanho é limitado.
Pode ajudar na prototipagem, mas, à medida que o projeto cresce, parece que no fim você acaba abandonando o framework nas interações centrais do viewport 3D e preenchendo quase tudo entre OpenGL ou algo parecido e os eventos de mouse/teclado com código próprio.
Frameworks para botões ou listas podem funcionar bem, mas mesmo esses elementos são muito mais dinâmicos em CAD 3D do que em um app comum.
Espero muito que o CADmium me faça sair do OpenSCAD. No OpenSCAD, no começo você não precisa pensar muito; basta empilhar módulo sobre módulo em uma linguagem simples.
O problema é que o OpenSCAD não tem um resolvedor. Há variáveis, mas não há restrições. Quando você vai fazendo mudanças, de repente precisa gastar bastante esforço mental para resolver restrições manualmente, e é fácil introduzir erros.
Ainda assim, não é um problema tão grave a ponto de me fazer migrar para outra ferramenta. Isso porque, na fase de iniciar um modelo, considero o OpenSCAD muito mais fácil do que qualquer outra coisa que já usei.
https://github.com/Ondsel-Development/OndselSolver
Ele é usado no FreeCAD e no Ondsel ES.
Comecei com OpenSCAD, mas, para criar objetos 3D reais, o FreeCAD acabou sendo bem mais produtivo. Às vezes, você quer começar com um retângulo, apagar uma linha e adicionar um semicírculo, mas só percebe isso antes de começar o sketch.
No OpenSCAD, dá a sensação de que você precisa saber de antemão quais primitivos de forma serão necessários e exatamente como modificá-los, e pessoalmente também me incomodava o fato de ele favorecer primitivos 3D em vez de aplicar extrusão/rotação a algo 2D.
É bom ver outras pessoas investindo tempo e talento em CAD open source. Na Ondsel, acreditamos fortemente que CAD open source é muito importante, e fico feliz em ver inovação nessa área.