(I'm the author of Fornjot.) > 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++ :)…
Ah, sorry! I missed that bit in the README and got confused :)
Hey, author of Fornjot here. 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…
Code-first CAD is the way to go for some users and some use cases. I personally won't make any stronger claim than that, nor will I accept any sweeping claims to the opposite. The average guy can keep doing what they're…
Hey, creator of Fornjot here. I had experimented with f-rep for years before switching to b-rep for the current iteration of Fornjot. I came to the conclusion that f-rep, while neat, is too limited for what I intend to…
FreeCAD is GUI-based though, not code-first like Fornjot. A better comparison would be CadQuery (https://cadquery.readthedocs.io/en/latest/intro.html) or Cascade Studio (https://zalo.github.io/CascadeStudio/), both of…
I will definitely keep reading and learning, as well as gaining practical implementation experience. We'll have to see how that goes, and what the solution will end up being. > Another direction you could take is to…
> How do you solve that in "code CAD"? I mean referring to a geometry that's a result of some previous operations, not one that you manually created. I've written down some preliminary thoughts here:…
I have a concept in mind, but have no idea yet whether it's going to work out: My idea is to require relationships between geometric objects to always be explicit. For example, you're not allowed to define a point that…
No idea :) 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.
Hey, creator of Fornjot here. > 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…
Hey, creator of Fornjot here. 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…
Hey, creator of Fornjot here. > 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…
Hey, creator of Fornjot here. 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…
I agree that a geometric constraint solver is very valuable. Having one built-in is a goal for Fornjot. We're not nearly there, though!
I've been reading Boundary Representation Modelling Techniques by Ian Stroud. Not the most approachable book, and I haven't read nearly all of it, but I already found it very valuable.
Hey, author of Fornjot here. > 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…
Hey, author of Fornjot here. > 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…
Hey, author of Fornjot here. 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…
Interesting, thanks for elaborating! 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…
Some of that documentation exists in the issue tracker. But that vision is something I refine as I learn more about use cases and the problem space. So it's not like I can just write down the ideal state right now :-)
Hey, author of Fornjot here. 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:…
Hey, author of Fornjot here. 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…
Fornjot is architected to be language-agnostic. Rust is just the easiest language to support, given that the rest of the project is written in it too. I (author of Fornjot) don't have any near-term plans to add support…
Exactly. All a model does, is build a C-ABI-compatible data structure. And even though Rust is currently the only language supported, Fornjot is architected to be language-agnostic. I don't think Rust is the ideal…
(I'm the author of Fornjot.) > 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++ :)…
Ah, sorry! I missed that bit in the README and got confused :)
Hey, author of Fornjot here. 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…
Code-first CAD is the way to go for some users and some use cases. I personally won't make any stronger claim than that, nor will I accept any sweeping claims to the opposite. The average guy can keep doing what they're…
Hey, creator of Fornjot here. I had experimented with f-rep for years before switching to b-rep for the current iteration of Fornjot. I came to the conclusion that f-rep, while neat, is too limited for what I intend to…
FreeCAD is GUI-based though, not code-first like Fornjot. A better comparison would be CadQuery (https://cadquery.readthedocs.io/en/latest/intro.html) or Cascade Studio (https://zalo.github.io/CascadeStudio/), both of…
I will definitely keep reading and learning, as well as gaining practical implementation experience. We'll have to see how that goes, and what the solution will end up being. > Another direction you could take is to…
> How do you solve that in "code CAD"? I mean referring to a geometry that's a result of some previous operations, not one that you manually created. I've written down some preliminary thoughts here:…
I have a concept in mind, but have no idea yet whether it's going to work out: My idea is to require relationships between geometric objects to always be explicit. For example, you're not allowed to define a point that…
No idea :) 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.
Hey, creator of Fornjot here. > 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…
Hey, creator of Fornjot here. 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…
Hey, creator of Fornjot here. > 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…
Hey, creator of Fornjot here. 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…
I agree that a geometric constraint solver is very valuable. Having one built-in is a goal for Fornjot. We're not nearly there, though!
I've been reading Boundary Representation Modelling Techniques by Ian Stroud. Not the most approachable book, and I haven't read nearly all of it, but I already found it very valuable.
Hey, author of Fornjot here. > 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…
Hey, author of Fornjot here. > 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…
Hey, author of Fornjot here. 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…
Interesting, thanks for elaborating! 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…
Some of that documentation exists in the issue tracker. But that vision is something I refine as I learn more about use cases and the problem space. So it's not like I can just write down the ideal state right now :-)
Hey, author of Fornjot here. 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:…
Hey, author of Fornjot here. 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…
Fornjot is architected to be language-agnostic. Rust is just the easiest language to support, given that the rest of the project is written in it too. I (author of Fornjot) don't have any near-term plans to add support…
Exactly. All a model does, is build a C-ABI-compatible data structure. And even though Rust is currently the only language supported, Fornjot is architected to be language-agnostic. I don't think Rust is the ideal…