- CADmium visait à devenir une CAO 3D paramétrique open source exécutée dans le navigateur, mais le projet est aujourd’hui arrêté et le dépôt GitHub reste archivé
- Le cœur de sa conception consistait à recomposer un solveur de contraintes 2D, un noyau b-rep, un suivi d’historique, une UI 3D et un format de fichier, tout en conservant une expérience familière pour les utilisateurs de CAO existants
- Pour la résolution des contraintes 2D, l’idée était de faire converger le système par itérations, comme dans une simulation physique ressort-masse-amortisseur, plutôt que de résoudre d’un seul coup une énorme matrice
- Pour le noyau b-rep, le projet comptait s’appuyer sur Truck, un projet open source en Rust, jugé adapté à l’exécution dans le navigateur grâce à WebAssembly et à ses bindings JavaScript
- Le format de fichier visait une approche centrée sur le texte, basée sur JSON et JSON Lines, en pensant aux CLI, aux git-diff, aux modifications par script ainsi qu’à un écosystème d’outils collaboratifs et d’assistance
État et objectifs du projet
- CADmium était un projet visant à créer un nouveau logiciel de CAO open source
- Le projet est aujourd’hui arrêté, et son dépôt GitHub est disponible sous forme d’archive
- Les distributions ne sont plus maintenues
- Les PR ne sont plus acceptées
- Le Discord existe encore, mais il n’est plus actif
- La CAO 3D paramétrique visée reposait sur 5 composants
- Un solveur de contraintes 2D
- Un noyau b-rep
- Un système de suivi d’historique
- Une interface utilisateur 3D
- Un format de fichier
Approche du solveur de contraintes 2D
- L’approche classique consiste à regrouper toutes les inconnues dans un grand vecteur, à exprimer chaque contrainte sous forme d’équation linéaire, puis à résoudre le tout comme une énorme équation matricielle
- Cette approche impose que la matrice soit carrée pour pouvoir calculer son inverse
- S’il y a trop de contraintes, la matrice peut devenir trop longue et échouer
- Même si des contraintes redondantes sont compatibles entre elles, elles peuvent provoquer un problème de surcontrainte
- S’il y a trop peu de contraintes, le solveur insère des hypothèses pour trouver une solution, mais des éléments de l’esquisse peuvent s’envoler très loin, contrairement aux attentes du modeleur
- Plus le nombre d’inconnues augmente, plus les grandes équations matricielles deviennent lentes, ce qui a conduit à la pratique consistant à garder chaque esquisse petite et simple
- L’alternative envisagée par CADmium consiste à traiter le problème de contraintes 2D comme une simulation physique
- Chaque point possède une masse et une vitesse
- Chaque contrainte agit comme un ressort appliquant une force aux points connectés
- Une force de frottement proportionnelle à la vitesse est présente
- La simulation avance par petits pas de temps jusqu’à convergence
- Au lieu de résoudre tout le problème d’un seul coup, le système applique de petites variations répétées pour ramener à zéro l’énergie potentielle des ressorts
- Le temps d’exécution de chaque pas de temps étant linéaire par rapport au nombre de ressorts et au nombre d’inconnues, cela pourrait permettre de gérer des esquisses plus complexes
- L’approche par simulation se prête bien à la parallélisation et pourrait même s’exécuter dans un compute shader
- En cas de surcontrainte, si le système est cohérent, il se résout normalement ; s’il ne l’est pas, les ressorts trouvent un compromis
- En cas de contraintes insuffisantes, au lieu de partir à l’infini, le système trouve la configuration valide la plus proche
- Cette approche pourrait aussi prendre en charge des contraintes d’inégalité
- Limiter une longueur à plus de 1 cm et moins de 2 cm
- Limiter l’angle d’une esquisse entre 10 et 30 degrés
- Elle pourrait également être étendue à d’autres forces, par exemple en traitant une aire donnée d’un polygone fermé comme une force de pression
- L’objectif de base est de proposer une expérience familière pour la plupart des utilisateurs de CAO, tout en considérant que la résolution de contraintes 2D laisse de la place à de nouvelles idées
Noyau b-rep et Truck
- En CAO mécanique, l’utilisateur doit manipuler directement les arêtes et faces des pièces
- La CAO paramétrique utilise une représentation explicite des frontières de la pièce sous forme de structure de données, appelée Boundary Representation, ou b-rep
- Un cube est représenté comme un Solid comportant 6 Faces
- Chaque Face comporte 4 Edges
- Chaque Edge comporte 2 Points
- Pour les surfaces courbes, les surfaces NURBS sont couramment utilisées ; elles permettent de contrôler des formes libres et de représenter précisément les coniques
- La b-rep est déjà difficile en tant que représentation géométrique, et la difficulté augmente fortement lorsqu’il faut implémenter des opérations booléennes comme Union, Intersection ou Subtraction
- Une bibliothèque qui gère ces données et ces opérations booléennes est un noyau b-rep
- Les grands éditeurs de CAO propriétaires ont développé leurs propres noyaux pendant des décennies, et les noyaux propriétaires sont considérés comme bons, mais coûteux
- Côté CAO open source, OpenCascade est généralement considéré comme le seul noyau b-rep open source populaire
- Il est gratuit, mais peut être jugé brut et instable
- L’apparence de la page officielle d’instructions de build, qui rappelle un ancien environnement Windows, est pointée du doigt
- Truck est un noyau b-rep open source en Rust en cours de développement
- Son dépôt GitHub est public
- Il est écrit en Rust et dispose d’un bon support de compilation vers WebAssembly
- Il peut s’exécuter sur les systèmes d’exploitation et dans le navigateur
- Il fournit des bindings JavaScript et des exemples
- Cela ne signifie pas que Rust serait catégoriquement meilleur que C++, mais il présente de nombreux avantages importants pour un projet open source
- Ses outils de build sont puissants, pratiques et bien documentés
- Il dispose d’une gestion centralisée des paquets
- Ses garanties de sûreté mémoire plus nombreuses rendent la parallélisation plus simple et plus sûre
- Les erreurs du compilateur sont amicales, ce qui facilite les refactorings
- Truck est un projet âgé d’environ 4 ans et il est considéré comme disposant déjà des fonctionnalités de base
- Lecture et écriture de fichiers
.step
- Triangulation de surfaces selon une tolérance fixe
- Support de NURBS
- Intersection ou Union de deux Solids, opération Not sur un seul Solid
- Truck est petit et léger, et il est développé par une entreprise appelée Ricos
- Il pourrait aussi prendre en charge les T-Splines, plutôt que les B-Splines correspondant au B de NURBS
- Le brevet sur les T-Splines était détenu par Autodesk, mais aurait expiré il y a quelques semaines
- Il est considéré comme théoriquement possible d’ajouter ce support à Truck
Suivi d’historique et idée de gestion de versions
- La CAO paramétrique stocke le Feature History de la conception
- Les pièces sont créées en empilant des opérations comme des esquisses, des extrusions et des révolutions
- On peut revenir à une étape antérieure, modifier des valeurs et réexécuter les fonctions pour obtenir une autre pièce
- En injectant des variables comme entrées dans le modèle puis en changeant leurs valeurs, la pièce se met à jour et le modèle devient paramétré
- Cette approche a réussi, mais elle comporte des fragilités comme le Topological naming problem, et le paradigme de la CAO paramétrique lui-même fait aussi l’objet de critiques
- Une approche visant à réduire ces fragilités est apparue sous le nom de Resilient Modeling Strategy
- Les chamfers et fillets consomment des edges, ils sont donc placés à la fin
- Les Detail features peuvent référencer des Core features, mais ne se référencent pas entre elles
- Si un logiciel de CAO impose de tels patterns, cela peut d’abord sembler restrictif, mais rendre les conceptions plus faciles à réutiliser et à transférer
- Il existe aussi l’idée d’ajouter un feature history aux esquisses
- Dans les logiciels de CAO actuels, on dessine des primitives comme des cercles ou des rectangles, puis on les duplique ou les modifie avec mirror, linear pattern, sketch fillet, etc.
- Ce graphe de dépendances est difficile à comprendre pour quelqu’un qui ne l’a pas créé ; il est souvent plus rapide de supprimer l’esquisse et de recommencer
- Si les features d’esquisse sont elles aussi stockées et affichées dans le feature tree, les idées de RMS peuvent être appliquées à une esquisse unique
- Le projet inclut aussi l’idée d’enregistrer tous les événements utilisateur dans un append-only log
- Si ce log devient la source unique de vérité du fichier, un curseur temporel peut reconstruire un Feature History donné
- Il devient possible de faire des Undo/Redo illimités même après avoir fermé puis rouvert le fichier
- On peut bifurquer depuis une version passée dans une autre direction et créer un arbre d’essais de conception comparable à l’historique git
- L’objectif est une application de CAO permettant de restaurer facilement tout état valide d’un document
- Tous les essais et erreurs
- Tous les livrables « finaux »
- Les anciens états dont on ne savait pas encore qu’on aurait besoin
- Avec cette structure, il devient possible de conserver plusieurs variantes d’une pièce, ainsi que l’état de conception utilisé lors de l’exécution de processus aval comme la toolpath generation ou la FEA
- L’idée va jusqu’à se demander : si l’on peut créer un git pour la conception mécanique, ne pourrait-on pas aussi créer un GitHub pour la conception mécanique ?
Interface utilisateur 3D basée sur le navigateur
- CADmium vise une manière de faire de la CAO dans le navigateur
- Onshape a ouvert la voie, mais il est décrit comme s’exécutant en réalité sur des instances cloud AWS avec GPU, dont le résultat est streamé vers le navigateur
- Si la connexion Internet est coupée, même la rotation du viewport n’est plus possible
- Comme Truck peut être compilé en WebAssembly, CADmium peut devenir une application Local-First qui traite tout dans le navigateur
- La stack technique utilisée est la suivante
- Three.js : viewport 3D
- Svelte : gestion d’état et réactivité
- Threlte : connexion entre Svelte et Three.js
- Passage de messages entre l’UI et le noyau b-rep
- Electron : exécution locale
- TypeScript, TailwindCSS, Vite, etc.
- Cette stack permet d’écrire toute l’application de manière réactive et déclarative, en reliant les changements de données jusqu’à la mise à jour des meshes
- Une application de CAO 3D fait partie des UI les plus complexes ; pour qu’une petite équipe puisse créer un bon produit, le framework doit prendre en charge beaucoup de travail
- Comme un proof of concept fonctionnel a été créé avec cette stack, cette partie n’est pas considérée comme le facteur limitant de CADmium
Format de fichier JSON et écosystème CLI
- CADmium voulait utiliser JSON pour tout
- Le projet prévoyait d’utiliser JSON Lines pour l’Operation Log
- Une fois une pièce conçue, elle devait pouvoir être exportée vers un format d’échange plus simple
- Le format d’exemple est une structure JSON contenant des opérations comme
sketch et extrude dans un tableau steps
- Un exemple d’utilisation de la CLI CADmium consiste à convertir un fichier
.cadmium en .step ou .stl
$ CADmium export my_part.cadmium --format stl
- Les deux éléments nécessaires pour créer un écosystème sont les suivants
- Un format de fichier simple et facile à comprendre
- Une CLI open source capable de manipuler ce format
- Un cas d’usage consiste à modifier la profondeur d’extrusion ou le rayon d’un fillet dans un éditeur de texte
- Il serait aussi possible, sans lire une spécification complexe comme ISO 10303-21, d’utiliser un script pour remplacer toutes les vis M5 par des vis M6
- Si un GitHub pour la conception mécanique est créé et réellement utilisé, on peut aussi imaginer un GitHub Copilot pour la conception mécanique
- Le jugement est que les grands modèles de langage fonctionnent mieux avec des formats textuels simples et ouverts qu’avec des formats binaires propriétaires complexes
Aide nécessaire et domaines mis de côté
- Il est impossible de savoir quelles idées réussiront ou échoueront, mais ce domaine est vu comme une occasion pour un petit groupe d’avoir un grand impact sur l’industrie manufacturière
- L’aide nécessaire est la suivante
- Programmation Rust et améliorations générales
- Géométrie algorithmique pour patcher Truck
- Support Three.js
- Nouveau contrôleur de caméra
- Meilleur éclairage
- Post-traitement
- Recherche de subventions ou de riches mécènes
- Les domaines non traités pour l’instant mais à revoir plus tard sont les suivants
- Capital-risque
- Toolpath generation, c’est-à-dire CAM
- Finite Element Analysis, c’est-à-dire FEA
- Le serveur Discord de CADmium existe encore, mais d’après l’information sur l’état du projet, il n’est plus actif
1 commentaires
Avis de Hacker News
J’attends beaucoup de ce que Matt est en train de construire. Le monde a cruellement besoin d’un CAD paramétrique open source avec une UI/UX aussi facile à utiliser que SolidWorks
La principale raison pour laquelle cela n’a pas vraiment fonctionné jusqu’ici est l’absence d’un noyau paramétrique suffisamment puissant, et Truck, qu’utilise Matt, ressemble exactement au projet qu’il faut. Jusqu’à présent, OpenCascade était quasiment le seul à s’en approcher, mais il lui manque des fonctions importantes et il souffre de nombreux bugs et problèmes de stabilité
Si Truck et CADmium parviennent à proposer des congés stables, ils pourraient devenir le véritable successeur d’OpenCascade et la plateforme qui façonnera l’avenir du CAD paramétrique open source
Je suis récemment passé à Alibre Atom3D : ce n’est pas open source, mais il suffit de payer 200 dollars une seule fois. Tant que l’OS hôte ne change pas radicalement, je peux continuer à ouvrir mes conceptions, et il fonctionne au-dessus du noyau ACIS
Quand je lis « browser-first » et, dans le README, « monétisation via une version hébergée payante », j’ai l’impression que ce projet risque soit de s’essouffler, soit de grossir jusqu’à devenir un produit open-core avec abonnement obligatoire, avec toujours plus de dépendances d’installation et de fonctionnalités de sécurité, rendant l’exécution réellement locale de plus en plus difficile
J’ai essayé la version hebdomadaire avec le thème OpenDark, et l’ensemble paraît assez soigné. C’est vraiment une période intéressante pour le CAD open source
Plus j’essaie de plateformes de CAD, plus j’ai l’impression que les applications spécialisées, adaptées à un domaine de problème étroit, sont bien plus utiles que le CAD généraliste. La sortie SVG/DXF/DWG est un atout, mais je pense qu’un logiciel de dessin qui cherche à couvrir à la fois des pièces mécaniques produites en masse, de l’architecture ponctuelle, des autoroutes, des pipelines de 50 miles, des circuits, de la planification de trafic urbain et de l’art fait fausse route
Même dans le logiciel de conception routière standard du secteur que j’utilise, le modèle objet ne contient pas d’objet « route ». Les composants horizontaux, verticaux et de coupe ne peuvent pas être séparés, et leurs règles d’interaction sont claires, mais ils sont définis chacun indépendamment. Les concepteurs devraient passer moins de temps à indiquer à l’ordinateur comment afficher les choses, et davantage à réfléchir au résultat lui-même
Je me demande pourquoi QCAD est si rarement mentionné sur HN quand il est question d’outils CAD ou d’open source
1 - https://www.qcad.org/
En tant que l’un des mainteneurs de Solvespace, j’ajouterais quelques points : les contraintes 2D seules ne suffisent pas, et les contraintes 3D sont préférables. Si vous écriviez en C++, je vous dirais de reprendre le solveur de contraintes de Solvespace comme l’a fait Dune3D, mais si vous aimez Rust, vous pouvez regarder le travail que Michael F Bryan a écrit en Rust et décrit sur son blog
https://adventures.michaelfbryan.com/posts/constraints-part-...
Côté noyau géométrique, il y a trois types de bugs que j’aimerais corriger dans le noyau de Solvespace ; une fois ceux-ci réglés, il pourrait gérer les opérations booléennes de manière assez fiable, mais je n’en ai pas eu le temps. Notre noyau fait moins de 6 000 lignes, il y aurait donc beaucoup à apprendre. Si vous voulez me contacter à ce sujet, envoyez-moi un mail sur Gmail avec le même ID. Je n’ai pas regardé Truck depuis un moment et je pensais qu’il stagnait un peu. C’est un problème vraiment difficile, et même dans le monde commercial les options sont limitées. Rien que trianguler des coques NURBS découpées est délicat
L’historique/l’arbre de fonctions est étroitement lié au problème de nommage topologique de FreeCAD. Solvespace gère cela en générant chaque entité à partir d’un ensemble de choses connues. Quand on essaie de la recréer, il ne crée pas une nouvelle entité mais renvoie le handle de l’entité existante. Autrement dit, chaque entité « vient de quelque chose » et cette relation est mémorisée. Cela fonctionne parfaitement dans les parties où nous traitons le nommage topologique, mais toutes les parties de Solvespace ne sont pas couvertes. C’est quelque chose qu’il faut intégrer dès le départ ; ce n’est pas facile à ajouter après coup
Et je serais curieux d’avoir un lien pour savoir où essayer CADmium
[1] https://github.com/thekakkun/rust_slvs
Github :
https://github.com/MattFerraro/CADmium
Le lien est ici :
https://mattferraro.github.io/CADmium/
Je trouve que c’est vraiment un travail impressionnant. J’aimerais que le CAD physique open source atteigne le niveau auquel l’EDA open source est parvenu.
On disait que résoudre ce genre d’équations matricielles devenait trop lent quand le nombre d’inconnues augmentait, d’où l’idée reçue selon laquelle chaque esquisse doit rester petite et simple, mais après avoir creusé assez loin, en réalité ce n’est pas un si gros problème.
Les problèmes de performance des contraintes dans FreeCAD viennent surtout d’algorithmes de placement GUI redondants et inutiles, et ça s’écroule déjà avec seulement quelques centaines de contraintes. La décomposition QR creuse d’Eigen prend environ 18 secondes pour 2 200 contraintes, ce qui n’est pas mauvais. Il existe aussi des bibliothèques de décomposition QR creuse capables de traiter 500 000 à 1 million de contraintes en à peu près 18 secondes. Il est difficile d’imaginer un cas où une esquisse CAD aurait plus de quelques milliers de contraintes.
[1] : https://github.com/FreeCAD/FreeCAD/issues/11498#issuecomment...
Il est utilisé pour les contraintes d’assemblage dans FreeCAD et Ondsel ES.
J’ai appris le CAD il y a longtemps avec Autodesk Inventor, et le seul logiciel de modélisation gratuit que j’ai pu comprendre après quelques heures de prise en main, c’était Onshape. Dans ce domaine, l’utilisabilité semble vraiment être un gros problème.
Par exemple, avec FreeCAD, on a l’impression qu’il existe des milliards de façons de faire la même chose, mais qu’au final il n’y a qu’une seule vraie méthode, et certains tutoriels laissaient derrière eux un modèle incorrect.
C’est un beau travail, et le problème semble difficile.
Repo : https://github.com/MattFerraro/CADmium
J’utilise presque uniquement les ateliers Part Design, Sketcher, Spreadsheet. Ces trois-là fonctionnent globalement bien ensemble. L’interopérabilité entre ateliers est mauvaise, ce qui me fait peur dès qu’il faut aller ailleurs. J’utilise parfois aussi l’atelier Part, mais pour l’utiliser dans Part Design il faut passer deux fois par une conversion de format interne, ce qui est beaucoup trop pénible.
J’espère qu’un jour l’un des nombreux projets de CAD open source remplacera FreeCAD.
Ce n’était pas pratique, mais le modèle fonctionnait même sur téléphone.
Fusion360 est utilisable, mais comparé aux suites commerciales que j’ai essayées, son expérience utilisateur est assez épouvantable.
Ce que j’aimerais dans un CAD gratuit, c’est que quelqu’un apporte la robustesse et la vitesse de Creo en les combinant avec la convivialité de SolidWorks. Ce ne serait pas grave si les fonctionnalités étaient assez limitées au début.
Le processus consistait à suivre un tutoriel qui m’amenait à 80 %, à essayer tant bien que mal de bricoler le reste, puis à me rendre compte que ce tutoriel de base avait structuré le projet d’une manière qui empêchait de terminer les 20 % restants, puis à essayer de modifier une étape précédente et voir tout le projet s’effondrer. Et je recommençais.
En CAD, l’ordre des opérations est-il généralement aussi important ? Je pensais que c’était un objet simple et que FreeCAD ne pouvait pas être si difficile, alors je me suis lancé, mais en réalité c’était très difficile.
Il est intéressant de voir arriver un nouvel entrant dans ce domaine, surtout s’il cherche à créer un nouveau noyau, mais ses chances de réussite semblent faibles. Les meilleurs noyaux du secteur ont été développés pendant des décennies par des docteurs en CAGD et des programmeurs, avec le soutien financier de constructeurs automobiles et d’entreprises de l’aérospatiale. Il faudra déjà beaucoup de temps pour atteindre un ensemble de fonctionnalités de base compétitif.
Je me demande aussi quel problème utilisateur il cherche à résoudre. Les utilisateurs de CAD n’ont pas forcément besoin d’open source. Il y a certes des contraintes budgétaires, mais dans ce domaine, l’open source n’est peut-être pas une fonctionnalité directement visible pour l’utilisateur comme dans les outils de développement. Plasticity a montré qu’il était possible de gagner de l’argent à bas prix tout en licenciant Parasolid.
J’utilise des outils de CAD paramétrique depuis plus de 30 ans, et Onshape est une solution assez remarquable à plusieurs problèmes présents dans Creo ou SolidWorks. Un environnement façon Google Docs pour le CAD collaboratif, où les données ne disparaissent pas, avec une annulation illimitée conçue dès le départ sur une base de données plutôt que sur un système de fichiers, change vraiment la vie. En revanche, ses fonctionnalités de modélisation sont encore en train de rattraper les autres outils.
Le gros défaut d’Onshape, Creo et SolidWorks est qu’ils partent d’une esquisse 2D pour extruder, faire tourner ou lisser en loft des objets 3D. Les outils 3D sont plutôt un ajout au modèle de base, presque une réflexion après coup. Plasticity, Rhino et Alias sont beaucoup plus 3D-first.
FeatureScript d’Onshape est très élégant et puissant, mais pour qu’un utilisateur de CAD crée ses propres outils, ce n’est pas aussi bon que Grasshopper de Rhino.
CADmium doit se concentrer sur le marché où il deviendra un meilleur outil de CAD que les alternatives payantes ou gratuites, et sur le problème utilisateur qu’il résout. Même en début de développement, il n’est jamais trop tôt pour comprendre les besoins des utilisateurs. L’open source n’est pas un objectif en soi.
Avec des outils modernes, les enseignements tirés des anciens moteurs et l’absence de dette d’entrée, une petite équipe peut créer quelque chose d’équivalent, voire de meilleur, qu’un logiciel vieux de 30 ans.
Je pense qu’une petite équipe dévouée peut créer un nouveau noyau paramétrique et un package CAD. C’est encore plus vrai si c’est open source.
Les utilisateurs de CAD pourraient tirer un grand bénéfice d’une bonne alternative open source.
À l’inverse, il existe de nombreuses raisons d’éviter les logiciels propriétaires, et elles sont encore plus fortes quand il s’agit de SaaS. Aujourd’hui, tout va de plus en plus vers le SaaS, et c’est aussi le cas ici. Les logiciels de CAD sont un domaine où beaucoup d’utilisateurs se sont déjà fait piéger après avoir investi des centaines d’heures à apprendre et utiliser un système propriétaire, avant que celui-ci ne change ses conditions.
Je sais que nous sommes une minorité, mais pour moi, l’open source est un objectif absolu en soi. Cela fait très longtemps que je n’utilise que des logiciels open source.
Cela dit, je ne suis pas sûr de comprendre pourquoi l’open source ne pourrait pas être un objectif. C’est un peu comme la relation entre KiCAD et Altium. Si l’on peut fournir en open source 90 % de ce qu’offre Onshape, je pense que les gens pourraient l’utiliser.
Je comprends l’argument du coût. Une licence SolidWorks coûte environ 3 000 à 5 000 dollars, donc la plupart des entreprises paieront pour utiliser un outil éprouvé.
À titre de référence, Onshape a été créé avec moins de 10 millions de dollars jusqu’à la réalisation d’un MVP en trois ans. Je ne pense pas qu’il faille nécessairement des décennies de travail de docteurs pour créer un nouveau programme de CAD aujourd’hui.
C’est un excellent résumé de l’écosystème des noyaux de CAD.
J’aime particulièrement cette phrase : « Le seul noyau B-rep open source populaire est OpenCascade, et c’est la Pontiac Aztek des noyaux B-rep. C’est moche, ça n’a que les fonctionnalités de base et ça peut tomber en panne, mais ça roule, et on peut l’obtenir gratuitement. »
C’est vraiment exact.
Si l’approche est local-first, je me demande pourquoi il faudrait le faire dans le navigateur
Solvespace a l’avantage d’être un unique fichier à télécharger/exécuter
De plus, son solveur de contraintes a été utilisé dans des projets comme CADsketcher et Dune 3D : https://github.com/dune3d/dune3d
L’auteur dit avoir utilisé directement le solveur de Solvespace parce que le code wrapper n’exposait pas toutes les fonctionnalités nécessaires, et avoir dû patcher le solveur pour résoudre symboliquement les équations lorsque c’était possible, afin de le rendre suffisamment rapide pour les types d’équations générées
Je me demande aussi si cela a un lien avec https://github.com/jay3sh/cadmium
Manifold n’a pas non plus été mentionné comme noyau CAD : https://github.com/elalish/manifold/wiki/Manifold-Library Je comprends qu’il présente beaucoup des mêmes inconvénients qu’OpenCASCADE, mais il semble tout de même mériter d’être cité
Ce noyau avait déjà été discuté ici : https://news.ycombinator.com/item?id=35071317
L’historique complet et la possibilité de l’éditer me semblent particulièrement intéressants et prometteurs. Si cet historique pouvait être listé dans un panneau ouvrable et refermable, avec des triangles de dépliage pour masquer les éléments terminés afin de se concentrer sur le travail en cours, ce serait pour moi un rêve devenu réalité. À condition toutefois que je parvienne à comprendre la partie 3D. Jusqu’ici, j’ai échoué avec BRL-CAD, FreeCAD, Solvespace, Alibre Atom, etc., et je n’ai réussi qu’avec des outils basés sur du code, proches d’OpenSCAD
Quand on doit concevoir une pièce chez soi, la modifier au travail, puis la fabriquer avec l’équipement disponible dans un makerspace, ne pas avoir à installer quoi que ce soit est un gros avantage
J’ai déjà envisagé de remplacer le code de maillage triangulaire de Solvespace par Manifold, mais cela représente beaucoup de travail, et ce dont on a vraiment besoin, c’est de corriger les bugs NURBS pour moins dépendre du code de maillage
À titre de référence, le solveur de contraintes de Solvespace est aussi utilisé dans l’atelier Assembly 3 de FreeCAD. Il se répand un peu partout ces temps-ci
Je suis d’accord pour dire qu’une appli de CAO 3D fait partie des UI les plus complexes
En revanche, je suis sceptique quant à l’idée qu’un framework doive faire une grande partie du travail à la place d’une petite équipe pour créer une bonne CAO 3D. Je doute qu’un framework d’UI généraliste puisse être une solution à long terme pour la CAO 3D
Une bonne UX doit parfois tenir compte simultanément d’un modèle 3D paramétrique, d’une approximation par maillage, d’une projection en lignes et patches après élimination des parties cachées, des pixels du framebuffer et des widgets d’UI. Les frameworks partent trop souvent du principe que l’information se découpe facilement et reste de taille limitée
Ils peuvent aider pour le prototypage, mais à mesure que le projet grossit, je pense qu’on finit par abandonner le framework pour les interactions du viewport 3D principal, et par remplir en grande partie avec son propre code l’espace entre OpenGL, ou équivalent, et les événements souris/clavier
Les frameworks conviennent pour les boutons ou les listes, mais même ces éléments sont bien plus dynamiques dans une CAO 3D que dans une application moyenne
J’espère vraiment que CADmium permettra de s’éloigner d’OpenSCAD. Avec OpenSCAD, au début, on n’a pas besoin de penser très grand : on empile simplement des modules sur des modules avec un langage simple
Le problème, c’est qu’OpenSCAD n’a pas de solveur. Il y a des variables, mais pas de contraintes. À force de modifier, on se retrouve soudain à devoir beaucoup réfléchir pour résoudre les contraintes à la main, avec un fort risque d’introduire des erreurs
Malgré tout, le problème n’est pas assez grave pour me faire passer à un autre outil, car au démarrage d’un modèle, OpenSCAD est de loin plus facile que tout ce que j’ai essayé jusqu’ici
https://github.com/Ondsel-Development/OndselSolver
Il est utilisé dans FreeCAD et Ondsel ES
J’ai commencé avec OpenSCAD, mais quand il s’agit de créer de vrais objets 3D, FreeCAD s’est révélé bien plus productif. Parfois, on veut commencer par un rectangle, supprimer une ligne et ajouter un demi-cercle, mais on ne le sait pas avant de commencer l’esquisse
Avec OpenSCAD, j’ai l’impression qu’il faut connaître à l’avance les primitives géométriques nécessaires et la manière exacte de les modifier ; et le fait qu’il encourage les primitives 3D plutôt que l’extrusion/la révolution appliquées à de la 2D m’a aussi personnellement dérangé
Ça fait plaisir de voir d’autres personnes investir du temps et du talent dans la CAO open source. Chez Ondsel, nous croyons que la CAO open source est très importante, et nous sommes heureux de voir de l’innovation dans ce domaine