Hacker News Reader

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.

[1] https://www.foresightmining.com/

[2] https://github.com/ForesightMiningSoftwareCorporation

Hey, author of Fornjot here.

> 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.

>> Starting with flat surfaces and straight lines is really ignoring the hard problems and...

is this flat surfaces only?

Looks to me like curves are passed to the lowest level: https://github.com/hannobraun/Fornjot/blob/main/src/kernel/g...

phkahler is probably referring to the milestone I'm currently working on: https://www.fornjot.app/blog/straight-edges-flat-faces-simpl...

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.

There is also STEPcode [1], which can read and write STEP using C++, it has been kept up to date by the BRL-CAD people and is used by them.

I think modifying Open CASCADE Technology would be a lot easier than starting again.

[1] https://github.com/stepcode/stepcode

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.

> I wonder why nobody has a repo of the various STEP specs run through stepcode to produce usable C++ read/writer.

They get built as part of STEPcode.