>> This looks super exciting, particularly the idea of building a new Open-source B-Rep CAD Kernel.
Yes, I think he's being rather naive about that. Starting with flat surfaces and straight lines is really ignoring the hard problems and will likely require a complete rewrite later. IMHO support for NURBS surfaces is a requirement for CAD and export/import of STEP files as well. Having said that, if he keeps going it will be a good thing. Some related efforts:
I've been keeping an eye on this space as well, and while I agree with your first point, I have to say that I'm really more interested in the groundwork that these kind of efforts may lay for the future. For example, I know that there's currently a company called Foresight Mining Software[1] that is aiming to build a CAD product, in Rust, using the Bevy game engine (also written in Rust) on the backend. Even if it's not entirely FOSS, they are open-sourcing aspects[2] of their work that could help to accelerate the development of FOSS platform, or at the least, could eventually lead to true cross-platform general-purpose mechanical CAD support for platforms like Linux so that users aren't tied to Windows and the Dassault/Autodesk ecosystem.
> Yes, I think he's being rather naive about that.
Oh yes, definitely :-)
Not in the sense that I think it's going to be easy, or anything like that. But I'm definitely (and consciously) focusing on the immediate next steps, while not really having a long-term plan. I do have enough of an idea of what I want to achieve, to know which direction to go in. And I'm doing that one step at a time.
This is definitely not the only way of tackling such a large problem. Someone else might approach this with a big vision and a solid plan, then use that to find the funding. I don't think either approach is inherently better, but the incremental approach is definitely a better fit for me.
> Starting with flat surfaces and straight lines is really ignoring the hard problems and will likely require a complete rewrite later. IMHO support for NURBS surfaces is a requirement for CAD and export/import of STEP files as well.
That's fair. And there are other valid criticisms as well, for example so far everything is single-threaded and CPU-based[1], which most likely won't do long term.
The thing is, I'm not capable of designing and then implementing a multi-threaded NURBS-based CAD kernel. I lack the expertise and experience. But what I can do, is design/implement this CAD kernel in an incremental way, step by step. One could argue, what's happening right now is the design process, and the implementation is just a useful side effect.
And we shouldn't forget, OpenSCAD exists and has its place. Something that's 80% as powerful, but has easy support for chamfers (and maybe some other goodies), would already be very useful to a lot of people. I'd rather focus on that and improve from there, than risk not getting anywhere, because I tried to tackle all the hard problems at once.
> Having said that, if he keeps going it will be a good thing.
Thanks! Maybe coupling the encouragement with criticism makes it more effective, not 100% sure :-)
---
[1] What I mean is, everything in the CAD kernel is CPU-based. The graphics are done using a GPU, of course.
Curves (currently only full circles) are supported, but the focus is on building a flat-faced/straight-edged MVP that support full CSG. It's possible that when this MVP is released, that curved edges/surfaces will be marked as experimental and not have full support for CSG, for example.
This is just a matter of priorities. Gotta start somewhere, then improve from there.
ruststep takes a similar approach to STEPcode but is written in Rust and produces Rust code. I wonder why nobody has a repo of the various STEP specs run through stepcode to produce usable C++ read/writer.
I think working on Open CASCADE may be worth peoples efforts, but I've opted to work on Solvespace instead. The core NURBS code is only about 8000 lines, while OCCT is absolutely huge.
Yes, I think he's being rather naive about that. Starting with flat surfaces and straight lines is really ignoring the hard problems and will likely require a complete rewrite later. IMHO support for NURBS surfaces is a requirement for CAD and export/import of STEP files as well. Having said that, if he keeps going it will be a good thing. Some related efforts:
Another (stalled?) CAD kernel in Rust: https://github.com/ervanalb/arcade
Another one in Rust that can also read STEP: https://github.com/ricosjp/truck
That one reads STEP by using: https://github.com/ricosjp/ruststep
There is a geometric constraint solver written in Rust: https://github.com/Michael-F-Bryan/constraints to be used in another CAD: https://github.com/Michael-F-Bryan/arcs If I recall he moved all his work to gitlab. Here is arcs: https://gitlab.com/Michael-F-Bryan/arcs
All of this is very ambitious and I look forward to a day when a good CAD system written in Rust is readily available.
In the mean time I shall keep plugging away at the Solvespace C++ code: https://solvespace.com/index.pl