- CADmium buscaba ser un CAD paramétrico 3D de código abierto que corre en el navegador, pero actualmente está descontinuado y su repositorio de GitHub quedó archivado
- El centro del diseño está en recombinar desde cero un solver de restricciones 2D, un kernel b-rep, seguimiento de historial, una UI 3D y un formato de archivo, manteniendo a la vez una experiencia familiar para usuarios de CAD existentes
- Para resolver restricciones 2D, proponía un enfoque de convergencia iterativa similar a una simulación física de resorte-masa-amortiguador, en lugar de resolver una enorme matriz de una sola vez
- Para el kernel b-rep quería aprovechar Truck, un proyecto open source basado en Rust, y consideraba que su WebAssembly y sus bindings de JavaScript lo hacían adecuado para ejecutarse en el navegador
- El formato de archivo apuntaba a un formato centrado en texto basado en JSON y JSON Lines, pensando en CLI, git-diff, edición por scripts, colaboración y un ecosistema de herramientas auxiliares
Estado y objetivos del proyecto
- CADmium era un proyecto para crear un nuevo programa CAD de código abierto
- Actualmente el proyecto está descontinuado y el repositorio de GitHub se ofrece como archivo
- La distribución ya no se mantiene
- No se aceptan PR
- Discord sigue existiendo, pero ya no está activo
- Los 5 componentes planteados para este CAD paramétrico 3D eran
- Solver de restricciones 2D
- Kernel b-rep
- Rastreador de historial
- Interfaz de usuario 3D
- Formato de archivo
Enfoque del solver de restricciones 2D
- El enfoque tradicional junta todas las incógnitas en un gran vector y expresa cada restricción como una ecuación lineal, para resolverlo como una enorme ecuación matricial
- Este método tiene la limitación de que la matriz debe ser cuadrada para poder calcular su inversa
- Si hay demasiadas restricciones, la matriz puede alargarse y fallar
- Restricciones redundantes pueden causar problemas de sobre-restricción incluso si son compatibles entre sí
- Si hay muy pocas restricciones, se insertan supuestos para encontrar una solución, pero elementos del sketch pueden salir disparados lejos de lo que espera quien modela
- A medida que aumentan las incógnitas, las grandes ecuaciones matriciales se vuelven lentas, y por eso surgió la práctica de mantener cada sketch pequeño y simple
- La alternativa de CADmium era tratar el problema de restricciones 2D como una simulación física
- Cada punto tiene masa y velocidad
- Cada restricción actúa como un resorte que aplica fuerza a los puntos conectados
- Hay una fuerza de fricción proporcional a la velocidad
- La simulación avanza en pequeños intervalos de tiempo hasta converger
- En vez de resolver todo el problema de una vez, repite pequeños cambios para llevar la energía potencial de los resortes a 0
- Como el tiempo de ejecución de cada paso temporal es lineal respecto al número de resortes e incógnitas, podría manejar sketches más complejos
- Este enfoque de simulación se adapta bien a la paralelización y hasta podría ejecutarse en un compute shader
- En problemas sobre-restringidos, si el sistema es internamente consistente se resuelve normalmente; si no lo es, los resortes encuentran un punto de compromiso
- En problemas con pocas restricciones, en vez de salir volando al infinito encuentra la configuración válida más cercana
- Este enfoque también podría soportar restricciones de desigualdad
- Limitar una longitud para que sea mayor a 1 cm y menor a 2 cm
- Limitar un ángulo del sketch a estar entre 10 y 30 grados
- También podría extenderse a otras fuerzas, como tratar el área de un polígono cerrado mediante una fuerza de presión
- La meta base era una experiencia familiar para la mayoría de quienes usan CAD, pero se veía margen para aplicar ideas nuevas en la resolución de restricciones 2D
Kernel b-rep y Truck
- En CAD mecánico, la persona usuaria necesita manipular directamente los bordes y caras de una pieza
- El CAD paramétrico usa Boundary Representation, o b-rep, para representar directamente los límites de una pieza como estructura de datos
- Un cubo se representa como un Solid con 6 Face
- Cada Face tiene 4 Edge
- Cada Edge tiene 2 Point
- En superficies curvas se usan con frecuencia superficies NURBS, que permiten controlar formas libres y representar con exactitud secciones cónicas
- El b-rep ya es difícil solo para representar geometría, y la complejidad sube mucho al implementar boolean operations como Union, Intersection y Subtraction
- La librería que maneja estos datos y operaciones booleanas es el kernel b-rep
- Las principales empresas de CAD privativo construyeron sus propios kernels durante décadas, y esos kernels se consideran buenos pero caros
- En el lado del CAD open source, OpenCascade es visto como el único kernel b-rep open source con popularidad real
- Es gratis, pero se le considera tosco e inestable
- También se señala que su pantalla de instrucciones oficiales de build parece de un entorno Windows antiguo
- Truck es un nuevo kernel b-rep open source en Rust en desarrollo
- Su repositorio en GitHub es público
- Está escrito en Rust y tiene buen soporte para compilar a WebAssembly
- Puede ejecutarse en sistemas operativos y en el navegador
- Ofrece bindings de JavaScript y ejemplos
- Esto no significa que Rust sea categóricamente mejor que C++, pero sí ofrece varias ventajas importantes para proyectos open source
- Herramientas de build potentes, cómodas y bien documentadas
- Gestión de paquetes centralizada
- Más garantías de seguridad de memoria, lo que hace la paralelización más fácil y segura
- Errores del compilador más amables, que facilitan el refactor
- Truck es un proyecto de unos 4 años y ya se considera que tiene funciones básicas
- Lectura y escritura de archivos
.step
- Triangulación de superficies con tolerancia fija
- Soporte para NURBS
- Intersection o Union entre dos Solid, y operación Not sobre un único Solid
- Truck es pequeño y ligero, y está siendo desarrollado por una empresa llamada Ricos
- También se planteaba la posibilidad de soportar T-Splines en lugar de B-Splines, la B de NURBS
- La patente de T-Splines era de Autodesk, pero se menciona que expiró hace unas semanas
- Se consideraba que teóricamente podría añadirse soporte a Truck
Seguimiento de historial y versión
- El CAD paramétrico guarda el Feature History del diseño
- Se construye una pieza acumulando operaciones como sketch, extrusión y revolución
- Se puede volver a un paso anterior, cambiar valores y volver a ejecutar funciones para obtener una pieza distinta
- Si se inyectan variables al modelo como entradas y se cambian sus valores, la pieza se actualiza y el modelo queda parametrizado
- Este enfoque fue exitoso, pero tiene fragilidades como el Topological naming problem, además de críticas al paradigma del CAD paramétrico en sí
- Como enfoque para reducir esa fragilidad surgió la Resilient Modeling Strategy
- Chamfer y fillet consumen edges, así que se colocan al final
- Los detail feature pueden referenciar core feature, pero no entre sí
- Si un programa CAD obligara estos patrones, al principio podría sentirse como una limitación, pero podría facilitar reutilizar y transferir diseños
- También había una idea de añadir feature history a los propios sketches
- En el CAD actual se dibujan features básicos como círculos o rectángulos, y luego se copian o modifican con mirror, linear pattern, sketch fillet, etc.
- Estos grafos de dependencia pueden ser difíciles de entender para quien no los creó, y muchas veces resulta más rápido borrar el sketch y empezar de nuevo
- Si los sketch feature también se guardaran y mostraran en el feature tree, la idea de RMS podría aplicarse incluso a un solo sketch
- También se incluía la idea de registrar todos los eventos de usuario como un append-only log
- Si el log fuera la única fuente de verdad del archivo, se podría reconstruir cualquier Feature History con un deslizador temporal
- Sería posible Undo/Redo ilimitado incluso después de cerrar y volver a abrir el archivo
- También se podría bifurcar desde una versión pasada en otra dirección y crear un árbol de intentos de diseño como un historial de git
- El objetivo era una aplicación CAD donde cualquier estado válido del documento pudiera recuperarse fácilmente
- Toda prueba y error
- Todo resultado “final”
- Estados pasados cuya necesidad aún no se conocía
- Con esta estructura se podrían mantener múltiples variantes de una pieza y registrar también el estado del diseño al ejecutar procesos posteriores como toolpath generation o FEA
- La idea se extendía a que, si se podía crear un git para diseño mecánico, entonces también podría crearse un GitHub para diseño mecánico
Interfaz 3D basada en navegador
- CADmium apuntaba a hacer CAD en el navegador
- Onshape abrió el camino, pero aquí se describe que en realidad corre en instancias cloud de AWS con GPU habilitada y luego transmite el resultado al navegador
- Si se cae la conexión a internet, ni siquiera se puede rotar el viewport
- Como Truck puede compilarse a WebAssembly, CADmium podía convertirse en una app local-first que hiciera todo dentro del navegador
- El stack usado era el siguiente
- Three.js: viewport 3D
- Svelte: gestión de estado y reactividad
- Threlte: conexión entre Svelte y Three.js
- Paso de mensajes entre la UI y el kernel b-rep
- Electron: ejecución local
- TypeScript, TailwindCSS, Vite, etc.
- Este stack permitía escribir toda la app de forma reactiva y declarativa, conectando cambios de datos hasta la actualización de mallas
- Como las apps CAD 3D tienen una de las UI más complejas, un equipo pequeño necesita que el framework haga gran parte del trabajo para poder crear un buen producto
- Como ya se había creado un proof of concept funcional con este stack, se consideraba que esta no era la limitación principal de CADmium
Formato de archivo JSON y ecosistema CLI
- CADmium buscaba usar JSON para todo
- Para el Operation Log planeaba usar JSON Lines
- También se consideraba que, tras diseñar una pieza, debería poder exportarse a un formato de intercambio más simple
- El formato de ejemplo era una estructura JSON con un arreglo
steps que contiene operaciones como sketch y extrude
- Se muestra un ejemplo de uso del CLI de CADmium para convertir archivos
.cadmium a .step o .stl
$ CADmium export my_part.cadmium --format stl
- Los dos elementos necesarios para crear un ecosistema eran
- Un formato de archivo simple y fácil de entender
- Un CLI open source capaz de manejar ese formato
- Se menciona el caso de uso de cambiar la profundidad de una extrusión o el radio de un fillet desde un editor de texto
- También se plantea el caso de cambiar por script todos los tornillos M5 por tornillos M6, sin tener que leer especificaciones complejas como ISO 10303-21
- Si se creara y realmente se usara un GitHub para diseño mecánico, también se podría imaginar un GitHub Copilot para diseño mecánico
- Se considera que los modelos grandes de lenguaje funcionan mejor sobre formatos basados en texto, simples y abiertos, que sobre formatos binarios privativos complejos
Ayuda necesaria y áreas en pausa
- No se sabe qué ideas tendrían éxito o fracasarían, pero se veía en este espacio una oportunidad para que un grupo pequeño tuviera gran impacto en la manufactura
- La ayuda necesaria incluía
- Programación en Rust y mejoras generales
- Geometría computacional para parches de Truck
- Soporte para Three.js
- Un nuevo controlador de cámara
- Mejor iluminación
- Postprocesado
- Oportunidades de subvención o encontrar patrocinadores con dinero
- Las áreas que no se abordarían por ahora, pero que podrían retomarse más adelante, eran
- Capital de riesgo
- Toolpath generation, es decir CAM
- Finite Element Analysis, es decir FEA
- El servidor de Discord de CADmium sigue existiendo, pero según el aviso de estado del proyecto ya no está activo
1 comentarios
Opiniones de Hacker News
Tengo muchas expectativas por lo que Matt está construyendo. El mundo necesita con urgencia un CAD paramétrico de código abierto con una UI/UX tan fácil de usar como SolidWorks.
La razón principal por la que hasta ahora no ha salido bien es que no había un kernel paramétrico lo suficientemente potente, y Truck, que usa Matt, parece ser justo el proyecto necesario. Antes, OpenCascade era casi lo único que se acercaba, pero le faltan funciones importantes y tiene muchos bugs e inestabilidad.
Si Truck y CADmium logran tener filetes estables, podrían convertirse en el verdadero sucesor de OpenCascade y en la plataforma que construya el futuro del CAD paramétrico de código abierto.
Hace poco me pasé a Alibre Atom3D; no es open source, pero solo se pagan 200 dólares una vez. Mientras el sistema operativo anfitrión no cambie demasiado, puedo seguir abriendo mis diseños, y funciona sobre el kernel ACIS.
Cuando leo “browser-first” y la frase del README sobre “monetizar con una versión alojada de paga”, me suena a que este proyecto podría desvanecerse o, al crecer, convertirse en un producto open-core con suscripción obligatoria, con más dependencias de instalación y funciones de seguridad, haciendo cada vez más difícil ejecutarlo realmente de forma local.
Probé la versión semanal con el tema OpenDark y se ve bastante pulida. Parece un momento realmente interesante para el CAD de código abierto.
Mientras más pruebo plataformas CAD, más siento que las aplicaciones especializadas para dominios de problema acotados son mucho más útiles que un CAD de propósito general. La salida a SVG/DXF/DWG es una ventaja, pero creo que un software de dibujo que intenta cubrir piezas mecánicas de producción masiva, arquitectura de una sola vez, autopistas, ductos de 50 millas, circuitos, planeación de transporte urbano y hasta arte va por mal camino.
Incluso usando software estándar de la industria para diseño vial, en el modelo de objetos no existe una “carretera”. Los componentes horizontales, verticales y de secciones no pueden separarse entre sí y sus reglas de interacción son claras, pero se definen de manera independiente. Los diseñadores deberían dedicar menos tiempo a indicarle a la computadora cómo mostrar las cosas, y más a pensar en el resultado en sí.
Me pregunto por qué casi no se menciona QCAD en HN cuando se habla de herramientas CAD o de código abierto.
1 - https://www.qcad.org/
Como uno de los mantenedores de Solvespace, agregaría algunas cosas: las restricciones 2D por sí solas no bastan; las restricciones 3D son mejores. Si estuvieran escribiendo en C++, diría que reutilicen el solucionador de restricciones de Solvespace, como hizo Dune3D, pero si les gusta Rust pueden ver el trabajo que Michael F Bryan escribió en Rust y explicó en su blog.
https://adventures.michaelfbryan.com/posts/constraints-part-...
En cuanto al kernel geométrico, hay tres tipos de bugs en el kernel de Solvespace que me gustaría corregir; si lográramos resolverlos, podríamos manejar operaciones booleanas de forma bastante estable, pero no he tenido tiempo. Nuestro kernel tiene menos de 6 mil líneas, así que habría mucho que aprender. Si quieren contactarme sobre este tema, pueden escribirme al gmail con el mismo ID. No he mirado Truck desde hace un tiempo y pensaba que estaba algo estancado. Este es un problema realmente difícil, y aun en el mundo comercial hay pocas opciones. Incluso triangular shells NURBS recortadas es complicado.
El árbol de historial/funciones está muy relacionado con el problema de topological naming de FreeCAD. Solvespace maneja cada entidad generándola a partir de un conjunto de cosas conocidas. Si se intenta crear de nuevo, no crea una entidad nueva, sino que devuelve el identificador de la entidad existente. Es decir, todas las entidades “vienen de algo” y se recuerda esa relación. En las partes donde manejamos el topological naming funciona perfectamente, pero no cubre todas las partes de Solvespace. Esto hay que incorporarlo desde el principio; no es algo que se pueda añadir fácilmente después.
Y me gustaría saber dónde se puede probar CADmium; ¿hay algún enlace?
[1] https://github.com/thekakkun/rust_slvs
Github:
https://github.com/MattFerraro/CADmium
Aquí está el enlace:
https://mattferraro.github.io/CADmium/
Me parece un trabajo realmente impresionante. Ojalá el CAD físico open source llegue al nivel que alcanzó el EDA open source.
Se decía que resolver estas ecuaciones matriciales se vuelve demasiado lento cuando aumenta la cantidad de incógnitas, y que por eso se instala la idea de que cada boceto debe ser pequeño y simple, pero al investigarlo bastante a fondo, en realidad no es un gran problema.
Los problemas de rendimiento de las restricciones en FreeCAD provienen principalmente de algoritmos de disposición de GUI redundantes e innecesarios, y se derrumba con apenas unos cientos de restricciones. La descomposición QR dispersa de Eigen tarda unos 18 segundos con 2200 restricciones, lo cual no está mal. También hay bibliotecas de descomposición QR dispersa que procesan entre 500 mil y 1 millón de restricciones en unos 18 segundos. Es difícil imaginar una situación en la que un boceto CAD tenga más de varios miles de restricciones.
[1]: https://github.com/FreeCAD/FreeCAD/issues/11498#issuecomment...
Se usa para las restricciones de ensamblaje en FreeCAD y Ondsel ES.
Aprendí CAD hace mucho tiempo con Autodesk Inventor, y el único software de modelado gratuito que pude entender después de tocarlo unas horas fue Onshape. En este campo, la usabilidad parece ser un problema enorme.
Por ejemplo, FreeCAD parece tener miles de millones de formas de hacer lo mismo, pero al final el método real es uno solo, y algunos tutoriales me dejaban con un modelo incorrecto.
Es un trabajo genial, y parece un problema difícil.
Repo: https://github.com/MattFerraro/CADmium
Casi solo uso los workbenches Part Design, Sketcher y Spreadsheet. Esos tres, en general, funcionan bien juntos. La interoperabilidad entre workbenches es mala, así que me da miedo expandirme hacia otros. A veces también uso el workbench Part, pero para usarlo desde Part Design hay que pasar por dos conversiones de formato internas, y eso lo vuelve demasiado engorroso.
Espero que algún día uno de los muchos proyectos de CAD open source reemplace a FreeCAD.
No era práctico, pero el modelo también funcionaba en el teléfono.
Fusion360 también se puede usar, pero comparado con los paquetes comerciales que probé, la experiencia de usuario es bastante horrible.
Lo que espero de un CAD gratuito es que alguien traiga la solidez y velocidad de Creo y las combine con la amabilidad de SolidWorks. No me importa si al principio las funciones son bastante limitadas.
El proceso era seguir un tutorial que me llevaba hasta el 80%, intentar pegar como fuera el resto, darme cuenta de que ese tutorial básico había estructurado el proyecto de una forma que impedía terminar el 20% restante, intentar modificar un paso anterior y ver cómo se derrumbaba todo el proyecto. Y repetir eso.
¿En CAD normalmente importa tanto el orden de las operaciones? Me lancé pensando que era un objeto simple y que FreeCAD no podía ser tan difícil, pero en la práctica fue muy difícil.
Es interesante que aparezca un nuevo participante en este campo, y en especial que intente crear un nuevo kernel, pero sus probabilidades de éxito parecen bajas. Los kernels de primer nivel de la industria han sido desarrollados durante décadas por doctores en CAGD y programadores, con financiamiento de empresas automotrices y aeroespaciales. Incluso llegar a un conjunto básico de funciones competitivas tomará mucho tiempo.
También queda la duda de qué problema de los usuarios intenta resolver. Los usuarios de CAD no necesariamente necesitan código abierto. Puede haber restricciones de presupuesto, pero en este campo el código abierto quizá no sea una función directamente visible para el usuario como lo es en las herramientas para desarrolladores. Plasticity demostró que se puede licenciar Parasolid y aun así ganar dinero con precios bajos.
Llevo más de 30 años usando herramientas CAD paramétricas, y Onshape es una solución bastante sorprendente a varios problemas que tienen Creo o SolidWorks. Un entorno tipo Google Docs para CAD colaborativo, donde los datos no se pierden y que tiene deshacer ilimitado basado desde el inicio en una base de datos en vez de en un sistema de archivos, cambia la vida. Sin embargo, sus funciones de modelado todavía están poniéndose al día con otras herramientas.
La gran desventaja de Onshape, Creo y SolidWorks es que su estructura parte de bocetos 2D para extruir, girar o hacer loft hacia objetos 3D. Las herramientas 3D son más bien un añadido de la estructura básica y casi una idea posterior. Plasticity, Rhino y Alias son mucho más 3D primero.
FeatureScript de Onshape es muy genial y potente, pero para que los usuarios de CAD creen sus propias herramientas no es tan bueno como Grasshopper de Rhino.
CADmium debería enfocarse en en qué mercado será una herramienta CAD mejor que las alternativas de pago o gratuitas, y qué problema de usuario va a resolver. Aunque esté en una etapa temprana de desarrollo, no es demasiado pronto para entender las necesidades de los usuarios. El código abierto no es un objetivo en sí mismo.
Con herramientas modernas, aprendizajes de motores antiguos y sin deuda de entrada, un equipo pequeño puede crear algo a la par o mejor que software de 30 años.
Creo que un equipo pequeño y dedicado puede crear un nuevo kernel paramétrico y paquete CAD, especialmente si es de código abierto.
Los usuarios de CAD pueden beneficiarse mucho de una buena alternativa de código abierto.
En cambio, hay muchas razones para evitar el software propietario, y más aún si es SaaS. Porque últimamente todo va cada vez más hacia SaaS, y este caso también. El software CAD es un campo donde muchos usuarios ya se han quemado después de invertir cientos de horas en aprenderlo y usarlo, para luego ver cómo un sistema propietario cambiaba sus condiciones de servicio.
Sé que somos pocos, pero para mí el código abierto es un objetivo absoluto en sí mismo. Desde hace muchísimo tiempo uso únicamente software de código abierto.
Aun así, no estoy tan seguro de la parte de que el código abierto no pueda ser un objetivo. Es parecido a la relación entre KiCAD y Altium. Si se puede ofrecer como código abierto el 90% de lo que ofrece Onshape, creo que la gente podría usarlo.
Entiendo el punto de los costos. Una licencia de SolidWorks ronda los 3.000 a 5.000 dólares, así que la mayoría de las empresas pagará por una herramienta probada.
Como referencia, Onshape se creó con menos de 10 millones de dólares hasta llegar a un MVP en 3 años. No creo que hoy sea imprescindible contar con décadas de personal con doctorado para crear un nuevo programa CAD.
Es un excelente resumen del ecosistema de kernels CAD.
En especial me gustó la frase: “El único kernel B-rep de código abierto popular es OpenCascade, que es el Pontiac Aztek de los kernels B-rep. Es feo, tiene solo funciones básicas y puede fallar, pero anda y se puede conseguir gratis”.
Es totalmente cierto.
Si es local-first, me pregunto por qué tendría que hacerse en el navegador
Solvespace tiene la ventaja de ser una sola descarga/ejecutable
Además, su solucionador de restricciones se usó en proyectos como CADsketcher y Dune 3D: https://github.com/dune3d/dune3d
El autor dice que usó directamente el solucionador de Solvespace porque el código wrapper no exponía todas las funciones que necesitaba, y que tuvo que parchear el solucionador para que resolviera simbólicamente las ecuaciones donde fuera aplicable, con el fin de hacerlo lo suficientemente rápido para los tipos de ecuaciones que genera
También me pregunto si tiene relación con https://github.com/jay3sh/cadmium
Como kernel CAD, Manifold tampoco fue mencionado: https://github.com/elalish/manifold/wiki/Manifold-Library Entiendo que tiene muchas de las mismas desventajas que OpenCASCADE, pero aun así parece digno de mención
Este kernel también se discutió antes aquí: https://news.ycombinator.com/item?id=35071317
El historial completo y la posibilidad de edición me parecen especialmente interesantes y prometedores. Si ese historial pudiera listarse en un panel que se pueda abrir y cerrar, y se agregaran triángulos desplegables para ocultar los elementos ya completados y así poder concentrarse en el trabajo actual, para mí sería un sueño hecho realidad. Eso sí, con la condición de que pudiera entender la parte 3D. Hasta ahora he fracasado con todo lo que probé: BRL-CAD, FreeCAD, Solvespace, Alibre Atom, etc.; lo único con lo que tuve éxito fueron herramientas basadas en código similares a OpenSCAD
Cuando diseñas una pieza en casa, la modificas en el trabajo y tienes que fabricarla en un makerspace con el equipo disponible, no tener que instalar nada es una gran ventaja
Alguna vez consideré reemplazar el código de mallas triangulares de Solvespace por Manifold, pero es mucho trabajo, y lo que realmente hace falta es corregir los bugs de NURBS para depender menos del código de mallas
Como referencia, el solucionador de restricciones de Solvespace también se usa en el workbench Assembly 3 de FreeCAD. Últimamente se está extendiendo por todos lados
Estoy de acuerdo en que las apps de CAD 3D tienen una de las interfaces más complejas
Pero soy escéptico respecto a la idea de que, para que un equipo pequeño haga un buen CAD 3D, el framework tenga que encargarse de muchas cosas. Me pregunto si un framework de UI de propósito general puede ser una solución a largo plazo para CAD 3D
Una buena UX a veces tiene que considerar simultáneamente modelos 3D paramétricos, aproximaciones de malla, proyecciones a líneas y parches después de eliminar superficies ocultas, píxeles del framebuffer y widgets de UI. Los frameworks asumen demasiadas cosas: que la información se divide fácilmente y que su tamaño es limitado
Puede ayudar para prototipar, pero cuando el proyecto crezca, creo que en las interacciones centrales del viewport 3D terminarán abandonando el framework y llenando casi todo entre OpenGL o algo similar y los eventos de mouse/teclado con código propio
Un framework para botones o listas está bien, pero incluso esos elementos son mucho más dinámicos en CAD 3D que en una app promedio
De verdad espero que CADmium me permita alejarme de OpenSCAD. En OpenSCAD al principio no hay que pensar demasiado; basta con apilar módulos sobre módulos en un lenguaje simple
El problema es que OpenSCAD no tiene solucionador. Hay variables, pero no restricciones. A medida que haces cambios, de pronto tienes que pensar mucho para resolver restricciones manualmente, y es fácil introducir errores
Aun así, el problema no es tan grave como para pasarme a otra herramienta. Creo que, en la etapa inicial de un modelo, OpenSCAD es mucho más fácil que cualquier otra cosa que haya usado
https://github.com/Ondsel-Development/OndselSolver
Se usa en FreeCAD y Ondsel ES
Empecé con OpenSCAD, pero al crear objetos 3D reales FreeCAD me resultó mucho más productivo. A veces quieres empezar con un rectángulo, borrar una línea y agregar un semicírculo, pero antes de empezar el sketch no sabes que eso es lo que quieres
En OpenSCAD se siente como si tuvieras que saber de antemano qué primitivas de forma necesitas y el método exacto para modificarlas; además, personalmente me molestaba que fomentara las primitivas 3D en lugar de aplicar extrusión/rotación a 2D
Me alegra ver que otras personas inviertan tiempo y talento en CAD open source. En Ondsel creemos que el CAD open source es muy importante, y nos alegra ver innovación en esta área