hannobraun
> I wouldn't be suprised if the author of fornjot had similar feelings if they ever considered that approach.
Yeah, I don't think I have it in me to work on a non-trivial project in C++ :)
(Not saying that's the wrong thing to do, in general. I'm not the one to do it, is all.)
> fornjot is a hobby project.
This is not correct! Fornjot started as a hobby, but it has been my main focus since the start of 2022. I rely on my sponsors to support that work. Since around March/April 2022 I've been earning enough from sponsorships to cover my costs.
> So the fact that they start from scratch and may take years is not a deterrent. Rather its part of the appeal, I would assume. ;)
It's true that Fornjot is enormously ambitious. But I also think lots of people (chiefly those from the professional CAD world) are kind of missing the point on what it would take for the project to be successful.
OpenSCAD exists and has a user base. Roughly matching its feature set and incrementally improving from there, could already make Fornjot useful to a lot of people. I certainly don't plan to stop there, but I'm just saying, there's an incremental path here. It's not just "100 man-years for an industrial-grade CAD kernel or bust".
Rust was chosen as a modeling language for two reasons:
1. Since the whole project is written in Rust, it was the most straight-forward choice. No dealing with bindings to another language or a scripting language runtime for the time being. 2. To provide an interesting alternative. I suspect that there can be a nice niche for Rust, creating infrastructure for writing models (e.g. libraries for generating screw threads, that kind of stuff).
I don't think that Rust is a great language for defining CAD models. Long-term, I suspect that the preferred choice for Fornjot will be something else. But for the time being, this decision allows me to focus on the CAD kernel.
> There also seems to be a goal overlap between Fornjot and DieselCAD
Do you have a link for DieselCAD? Searching on Google only got me car results.
The average guy can keep doing what they're doing. Fornjot will not take GUI-based CAD away from them.
I've written more about that here: https://www.fornjot.app/blog/why-fornjot-is-using-boundary-r...
> Another direction you could take is to define just the API, and use the opencascade kernel (like FreeCAD) until the rest of your code is ready.
A CAD kernel is the central dependency for any CAD program, and I feel that it would be wrong to just use one and accept its limitations. I need to be able to take ownership, to work on it directly. OpenCASCADE is a huge pile of C++ code, which is the opposite of all that. (Not saying it's wrong to use in general, just that I'm the wrong guy to work on a huge pile of C++ code.)
I've considered using Truck[1], but decided not to do that for now. I really want to see what I can come up with. If that doesn't work out, at least I'll be in a much better decision to decide what other option would be best.
I've written down some preliminary thoughts here: https://github.com/hannobraun/Fornjot/issues/101#issuecommen...
And let me emphasize, these are just preliminary thoughts. I can see cases where what I wrote there won't work, and I'm sure there are many more problematic cases I haven't thought of yet.
There's still a lot of work to do before any of that even becomes relevant for Fornjot. I'll keep thinking about it in the background, but I don't expect to come up with a meaningful solution before I had a chance to really dive into the topic.
CadQuery has its own approach, which I have yet to study in detail: https://cadquery.readthedocs.io/en/latest/selectors.html
For example, you're not allowed to define a point that happens to lie on a surface. You must instead explicitly define the point in terms of the surface. By extruding from a sketch that lies in the surface, or by saying "extrude until the shape hits the surface", or by specifying some kind of constraint.
I hope that it is practical to design CAD models in a way, such that these relationships are always explicit, and I hope that this will enable the CAD kernel to not have to rely on messy floating point stuff comparisons. But as I said, not no idea if it's going to work out like that.
I know I want it, and that's about the extent of the design work. There's loads of more basic capabilities to add, before it makes sense to tackle constraints.
> Shouldn't this be a separate project?
Maybe. Not right now, I think. Not much of a point, as long as I'm the one doing most of the work.
The kernel is available now as a separate library though, that can be used independently. If it attracts its own set of users and contributors, it might make sense to have a separate website and repository.
Support for architecture use cases is currently listed on Fornjot's feature wishlist: https://github.com/hannobraun/Fornjot/discussions/146
As is noted there, I lack any expertise in this field, and it's largely unclear what specifically would be required to support it. Feedback is very welcome!
> isn't it kind of similar to OpenSCAD?
Yes, OpenSCAD is one example (the most prominent, I think) of the Code-CAD approach.
The Fornjot FAQ addresses OpenSCAD: https://www.fornjot.app/faq/
Second question. (Sorry, there isn't a way to link to specific questions in the FAQ yet. I've made a note to add that.)
> I do question whether Rust is the write choice for defining models,
You're not the only one :-)
As I've written in reply to other comments (here and elsewhere), it was just the easiest option to start with, given that the rest of the project is also written in Rust. Fornjot is architected to be language-agnostic, so we're not bound to Rust on the modeling side.
> but it does seem like a cool project.
Thank you!
Fornjot is written in Rust, so starting with Rust as the modeling language was the most straight-forward option. I do agree that Rust is not ideal for this use case.
Fornjot is architected to be language-agnostic. Long-term, I hope there will be a selection of interoperable options for the modeling language.
> The modeling language for Fornjot is Rust. To me, this seems like an akward language to write models in.
I fully agree! Given that Fornjot is written in Rust, starting with Rust as the modeling language was just the most straight-forward option.
But Fornjot is architected to be language-agnostic. Right now, it uses a plugin system based on dynamic linking, and you could plug anything in there that can generate C-ABI-compatible structs (the plan is to replace that with a system based on WASM).
In addition, I've started splitting Fornjot into self-contained libraries[1]. Once that effort is complete, there will be lots of ways to make Fornjot available to other languages.
That said, I think there's merit in having options when using Code-CAD, and Rust is certainly different enough from the typical alternatives to be valuable. I don't think it will ever be the best option for regular CAD modeling, but it might have a niche in infrastructure code that CAD models (written in other languages) use.
> I do wonder what kind of limitations the author ran into with OpenSCAD
Lack of bevels/chamfers, no way to refer to existing geometry (to sketch something on a face and extrude that, for example), no constraint-based modeling, weird and limited language. Those are a few off the top of my head.
I don't want to speak badly about OpenSCAD. It's obviously very useful to a lot of people, and I myself keep coming back to it for my own projects (Fornjot isn't ready to replace it). But there are many good reasons to want something else.
> and why they decided building a replacement code-CAD program was the best way to go.
What would the alternative be, in your mind? Trying to join the OpenSCAD project, saying "I want to change everything", would just be rude.
I don't want to fork a big C++ project either, as I don't know the language very well and have no interest in learning it. I'm also not convinced that starting with a fork of something would be better, in the long run. There's value in looking at the problem with fresh eyes.
In addition to the article that agucova posted, OpenSCAD is also specifically called out in the FAQ: https://www.fornjot.app/faq/
Second question. (Sorry, there isn't a way to link to specific questions in the FAQ yet. I've made a note to add that.)
I have had similar thoughts: Having a low-level representation that only makes sure that a geometric object you reference actually exists (and does other low-level validations), then have a wrapper around that, that provides higher-level operations and makes sure your model is also manifold.
This isn't thought out yet, just some stuff I've pondered. Thanks for providing more input to my thought process!
Could you give a bit more detail on what you mean by that? The plan for Fornjot is to use WebAssembly as the intermediate representation for models: https://github.com/hannobraun/Fornjot/issues/71
Chamfered edges are definitely planned!
> edit: Models are defined as Rust code. > > Oh...
Not sure how to interpret that "Oh.." :-)
Rust is the only modeling language supported right now (give that the rest of the project was written in Rust, it was the easiest solution), but Fornjot is architected to be language-agnostic.
I (author of Fornjot) don't have any near-term plans to add support for other languages, but I hope that people will start experimenting (and someone already has: https://github.com/WeirdConstructor/Fornjot/tree/wlambda_int...).
I don't think Rust is the ideal language for this problem, but with Fornjot itself written in Rust, it was the easiest one to support. Gotta start somewhere.
Making models more convenient to define is planned (https://github.com/hannobraun/Fornjot/issues/72), support for other modeling languages is on the wishlist (https://github.com/hannobraun/Fornjot/discussions/146).
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.
> 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.
> 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.
What's there right now are basic 2D graphics, a user interface based on an in-game console (designed as a prototyping tool; we planned to replace it with a proper UI), some buggy beginnings of a mouse-based interface, networking code (client/server; the clients can see each other in the game), and some basic physics.
When you connect to the game, you start in orbit above a planet and can use the in-game console to execute commands that change your orbit. You can't really do much else other than fly around. So there's not really any game play or anything interesting to do, really.
If we had continued development from there, we could have started adding some real game play pretty much right away, but to get the basics right would have required a lot of iteration, and we would have been weighed down by all the technical infrastructure that was already there. Plus, none of that technical infrastructure was very polished, so it would have required a lot of updating and rework along the way.
So yeah, still years of work ahead, I suppose.