Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This looks super exciting, particularly the idea of building a new Open-source B-Rep CAD Kernel. In fact that's (for me) by far the most exciting part! Open cascade is dated, somewhat difficult to work with and nowhere near as capable as commercial Kernels such as Parasolid.

Its going to be a mammoth undertaking to build a new kernel, the existing ones have taken tens of thousands of man years to get to where they are now. I do believe it's possible to start afresh though, by carefully selecting features to support and getting an MVP running it would then be possible to build something very impressive. Starting with a code first cad tool is a good idea, it purposely keeps things simple, and expectations lower.

I do believe there is a commercial market for this to - a cheaper and easer to use kernal to build cad products on would be very welcome, I could see the potatial for commercial investment in a open source kernal. I have a Mechanical/Industrial Design background as well as Software and often get tempted to try and build various CAD tool ideas I have, having a good modern foundation to build upon would be brilliant.



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

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


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.


Hey, author of Fornjot here. Thank you for the encouraging words!

> I do believe there is a commercial market for this to - a cheaper and easer to use kernal to build cad products on would be very welcome, I could see the potatial for commercial investment in a open source kernal. I have a Mechanical/Industrial Design background as well as Software and often get tempted to try and build various CAD tool ideas I have, having a good modern foundation to build upon would be brilliant.

I'd love to get there one day! I've already been in contact with potential commercial users (well, one), but very understandably, they'd like to see more progress before taking a bet on such an early-stage project.

For now, I'm relying on sponsorship from the community. It's not enough to cover my living costs yet, but the growth is there. I'm optimistic that it will reach a sustainable level before I run out of money.


My issues with OpenCascade and CGAL is that they are hard to compile. Any project using them is kinda a pain to build. This hurts developer adoption and puts up a barrier between the end users and the developers. In OSS, that barrier should be much more porous.

Rust projects (which Fornjot is) build nicely almost everywhere and can trivially target Wasm. Being in Rust will get a whole lot more folks involved in the project. One need not support every feature of OCC or CGAL.

Dated is the wrong term, it reinforces the temporal bigotry in tech.


I've never heard a person referred to as dated, so I'm not sure it directly implies any ageism towards people.

With tech itself, newer stuff usually performs better, is easier to use, and has better features.

Older stuff sometimes has one or two of them, but more newer has all of them more often than older, once the new thing reaches maturity(If that ever happens, since it often takes the aforementioned thousands of man years referenced in the thread)

Web3 is sadly changing this though.


Dated is a term that is often applied with a broad brush to software in the past. Giving undo credence to new over the old is what I am referring to with the phrase "temporal bigotry". New is not better, it is just new. The better part has to be proven. The ability to make poor choices, write bad code and ignore already working solutions is timeless.


Then again OCCT runs on JS & WASM in your browser

https://github.com/donalffons/opencascade.js

have it run in your browser

https://donalffons.github.io/opencascade.js-examples/demos/b...


You can even get an OpenCascade IDE running in your browser! https://github.com/zalo/CascadeStudio




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: