1) You don't want just 2D constraints, 3D is better. If you were writing in C++ I'd say just take our constraint solver (Like Dune3D did). Since you're loving Rust, I can point you to the work of Michael F Bryan who wrote one in Rust and blogged about it here: https://adventures.michaelfbryan.com/posts/constraints-part-...
I think his code is over at gitlab. I haven't looked at it in a couple years. He wrote that after I nerd-sniped him ;-)
2) For geometry kernels... I've got 3 classes of bugs I want to squash in the Solvespace kernel and then it should do booleans pretty reliably, but I haven't had the time. Ours is just under 6k LOC so you could learn a lot from it. My email is the same ID at gmail if you want to ping on this topic. Its been a while since I looked at Truck and I thought it had stagnated a bit. This is a really hard problem, which is why there are so few options out there even in the commercial world. Even triangulating a trimmed NURBS shell is tricky.
3) History/feature tree is closely related to the "topological naming problem" that FreeCAD has. Solvespace handles this by creating each entity from a set of known things. If you try to recreate (regenerate in our lingo) it will just return a handle to the existing entity rather than creating a new one. In other words, every entity "came from something" and that relationship is remembered. Where we handle topological naming it works perfectly. But not everything in solvespace is covered by this. You need to bake this in from the start, it's not something you can easily bolt on afterward.
4) where is the link to try out CADmium?
> Another downside is that solving this kind of matrix equation gets prohibitively slow when you have a lot of unknowns, which gives rise to the conventional wisdom that individual sketches should be small and simple.
I've gotten quite deep into this, and this is really not a problem in practice[1]
1. FreeCAD's main issues with constraint performance come from a redundant & unnecessary GUI layout algorithm, which falls over with just a few hundred constraints.
2. Eigen's sparse QR decomposition benchmarks at 18s for 2200 constraints, which is really not too bad
3. There are sparse QR decomposition libraries that can handle 500k-1M constraints in about 18s. I can't imagine a CAD sketch with more than a few thousand constraints.
[1]: https://github.com/FreeCAD/FreeCAD/issues/11498#issuecomment...
Awesome work! It seems like a hard problem
I also question what user problems this is trying to solve. CAD users don't necessarily need things to be open source. They may have limited budgets, but open source is not a user facing feature in this space the way it might be for some developers. Plasticity has shown that it is possible to license Parasolid and make money at a very low price point.
I've been using parametric CAD tools for 30+ years. I find that Onshape is a pretty amazing solution to many of the issues that exist with Creo or Solidworks. I never loose data. Having the equivalent of Google Docs for collaborative CAD with unlimited undo based on a ground up database instead of a file system is life changing. That said, its modeling capabilities are still playing catch up with other tools.
A big downside to Onshape (and Creo and Solidworks) is that it started as 2D sketches to extrude/revovle/loft etc into 3D objects. 3D tools are an add on and afterthought to the fundamentals. Plasticity (and Rhino and Alias) are all much more 3D first.
Onshape's FeatureScript is really cool and powerful, but it is not as good for CAD users to build their own tools as say Grasshopper in Rhino.
I would focus on what user problems are being solved. How will CADmium be a better CAD tool for a certain market than any of the others paid or free? Even though this is very early days in the development process, it's not too early to try to understand user needs. Open source is not in and of itself a goal.
Favorite quote from this:
"The only popular open-source b-rep kernel is OpenCascade, which is the Pontiac Aztek of b-rep kernels: It is ugly, barebones, and it might break down on you, but it is drivable and you can get one for free."
SO true!
Solvespace has the benefit of being a single download/executable.
It also has a constraint solver which has been used in a couple of projects: CADsketcher as you noted, and Dune 3D: https://github.com/dune3d/dune3d where the author noted:
>I ended up directly using solvespace's solver instead of the suggested wrapper code since it didn't expose all of the features I needed. I also had to patch the solver to make it sufficiently fast for the kinds of equations I was generating by symbolically solving equations where applicable.
Any relation to: https://github.com/jay3sh/cadmium ?
Also, for CAD kernels, Manifold was not mentioned: https://github.com/elalish/manifold/wiki/Manifold-Library --- while I understand it to have many of the same disadvantages as OpenCASCADE, it does seem worth mentioning.
Interestingly the kernel was previously discussed here:
https://news.ycombinator.com/item?id=35071317
It seems really interesting/promising, esp. the compleat history and editability (I'd love to see that history listed in a pane which could be opened/closed --- add a series of disclosure triangles which would allow hiding finished elements so that one could focus on the current task and it would be a dream come true for me --- if I can puzzle out the 3D stuff, so far I've crashed and burned on all the apps I've tried (BRL-CAD, FreeCAD, Solvespace, Alibre Atom...) --- the only thing I've been successful w/ is OpenSCAD and similar coding tools).
I agree.
> If you want to make a good one and you only have a small team, the framework had better do a lot of heavy lifting!
I am skeptical that general-purpose UI frameworks can be a good long-term solution for 3D CAD. At times, a nice UX will need to think about many of the following at once:
- the parametric 3D model
- its mesh approximation
- its hidden-surface projection into lines and patches
- the pixels in the frame buffer
- UI widgets.
Maybe the frameworks will help for prototyping, but if the project grows, I expect at some point they will end up ditching frameworks for the core 3D viewport interactions, and have mostly their own code in between OpenGL (or similar) and mouse/keyboard events.
Frameworks for buttons, lists, etc. will probably be fine, but even those tend to be much more dynamic in 3D CAD than in average apps.
I am a mostly (and increasingly) happy FreeCAD user (though I agree with your framing) but OMG I am happy for you, and I will try to get involved when I can.
Best of luck.
I know that ISO 10303-243 uses JSON but in hindsight I think that was a mistake.
He missed BRL-CAD, which also does brep. The interface is clunky but the kernel seems advanced.
> In practice many optimizations are made.
And I’m sure there’s a good reason to do physics. But, do iterative solvers like gmres or whatever have trouble with these kinds of problems?
See that discussion forum here:
https://github.com/tlalexander/open-cad-foundation/discussio...
Many times I have used traditional solvers to map out an old building where no angles are 90°. I measure a bunch of distances (with some inaccuracy of course) and spend hours fighting with the solver to get to something that satisfies most of the measurements.
This takes time because I am in essence doing exactly the converging spring forces simulation that you propose. Except much slower :-)
The good side is that all CADs have a very steep learning curve, with most tutorials made by people who are oblivious to the ignorant masses. The landscape is so complex today, that it's easier to use a vector drawing tool and transform it into a 3D model than to use any CAD to make a cylinder.
What would people recommend for a CAD program to run on Linux that I could use now (that is either free or cheap). I have simple requirements, I want to make a box for some electronics, but need the ability to import (and extrude etc) SVGs.
I couldn't see the SVG feature when I looked at dune, and I had some problems when I used freeCAD, but was planning on looking into it again.
What would people suggest?
On another note, please don't use Discord for development: https://drewdevault.com/2021/12/28/Dont-use-Discord-for-FOSS...
use IRC or Matrix but not Discord.
On a related note, we really, really need a worthy replacement for EAGLE. It's only a couple years away from EOL, and KiCAD is light years away from being feature-equivalent.
Does CADmium suffer from a topological naming problem like FreeCAD?
Why is it that open source programs always want me to use an awful (and proprietary) chat app?
JavaScript should be limited to 1997 Netscape 3.0 performance to stop this kind of garbage. And WASM should never have been attempted, and should be removed.
Write real native software if you’re trying to make something good for end users.
The biggest reason this hasn't happened so far is the lack of a truly capable parametric kernel, Truck, the kernel that Matt is using looks like an incredible project and exactly whats needed. The only other kennel till now that been close to being whats needed is OpenCascade, but its lacks important features, is buggy and at times quite unstable.
Once Truck (and CADmium) lands stable fillets (surprisingly one of the hardest features to make stable) it will prove itself as the perfect successor to OpenCascade and and the perfect platform to build the future of open source parametric CAD upon.