> There are other disadvantages to Code-CAD, of course. Making a sketch and applying some constraints can be very easy with a nice GUI, while having to type it all out would be very tedious.
> For that reason, I think the ideal CAD program would use a hybrid approach: Being code-first for all the reasons presented above, but letting you edit that code through graphical tools, where it makes sense. I'm not aware of any system that works like that, at least to the extent that is possible in principle. I believe that creating such a system would be a worthwhile effort.
As for 2D CAD apps, such feature already exists since 1980s when AutoLISP created for AutoCAD (opensource apps with similar scripting: QCAD, LibreCAD).
As for 3D CAD apps, and especially opensource, FreeCAD has ability to generate shapes or sketches with script and it would be possible to edit resulted geometry manually with GUI tools.
As far as I understand, neither of the examples you mention allow for proper bi-directional editing.
> FreeCAD has ability to generate shapes or sketches with script and it would be possible to edit resulted geometry manually with GUI tools.
That sounds like the "normal" flow, where the first GUI editing action is destructive (= requires you to "emit" the parameterized geometry).
I think what is alluded to there, is something more akin to a visual Markdown editor, or newer visual React editors like Utopia[0], which are a departure from the old generation of WYSIWYG editors like Dreamweaver, where an edition action in either the code or the visual mode wreaked havoc on the state of the other mode.
Consider that if you do not like or miss something from the available OSS solutions that are or could be made scriptable (FreeCAD or others, e.g. SolveSpace), you need to touch source.
FreeCAD & SolveSpace are C++. After 30+ years of that language and four years of Rust I won't touch the former with a ten foot pole unless it's an extraordinarily well paid gig.
I wouldn't be suprised if the author of fornjot had similar feelings if they ever considered that approach.
fornjot is a hobby project. 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. ;)
> 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".
We can debate the merits of tools... but deliberately selecting any tool because it is "trendy" seems like a bad idea to openly state. Writing a CAD Kernel is extremely difficult (thus why there are, like, 3-4 in use in all CAD packages right now, Parasolid is everywhere)... so the last thing we need is a trendy tool over a pragmatic one.
Maybe "trendy" is a bad way to express it but I like the idea that 'yeah, we know it's a huge job to start from scratch, but so what? in 20 years it won't be starting from scratch any more, and should we just accept that the last cad kernel in history has already been written and a company owns it, and surely there are things that would be good, that can only be decided on day one and can't be retroactively decided in any existing kernel.' etc etc
I know rust isn't magic or anything but I also know that paradigms and frameworks matter, and starting from scratch in a strict environment like rust where there is just a lot of pain in the neck rigor in every molecule, seems like it could have a great effect on something that needs to eventually grow into a huge and complex thing where the higher levels really really need to trust the lower levels to always be bulletproof correct.
Rust's concerns were originally security, but security is just correctness, and correctness is valuable everywhere.
And even the "trendy" aspect... I'm fine with it if it's consciously expressed up front like that. Rust plus webgpu? ok, sounds like a reasonable starting premis. Why not?
Security is correctness but correctness is not just security. CAD kernels being complex beasts want correctness algorithmically and that is the biggest most difficult part.
If anything you want a formal verification language.
All the README and docs are written by non-native speakers. This is very obvious, I think. The company behind this is Japanese.
The 'Trendy' comes from the wish to use titles for the guiding priciples that start with the letter 'T' because 'truck' does.
That's what I learned when I submitted a PR with an "improved" README that kept the alliteration but had all three guiding principles start with the letter 'U' instead. It got refused. :)
Think of it what you will but for me it's fine if the README and parts of the docs are a bit Anglish sounding as long as the code is solid and I can understand what is meant.
Not trying to discourage you, but a reliable geometric kernel takes around a decade of work to develop, for a team of PhDs.
Based on the docs, you've only implemented some very basic topological operations (and rendering, for some reason). The hard part is going to be implementing the rest: boolean operations, offset surfaces, lofted surfaces, blended surfaces, etc. and then there's the problem of version control / edit history. Efficiently and accurately implementing each of these can be a year-long research project in itself... You need a solid understanding of 3D topology, numerical methods, 3D differential geometry, etc.
Nevertheless, I wish you luck! I will check back in a year or so.
I absolutely wish the same... I am just not hoping for anything anytime soon, and that's OK. It's like asking a person to swallow a whale. Theoretically possible but it will take a while.
It's also tricky to implement a kernel in a good, modular, well-designed manner. Take a look at OpenCASCADE, the kernel used by FreeCAD. And holding back FreeCAD. It's been in development for 24 years and it hasn't hit anywhere close to Parasolid yet.
It could very well be a company in disguise writing this (or the author being paid to work on it full time but we're not aware of the company behind it, because they will be doing offerings later based on it).
But yeah, 100% this. Anyone familiar with the space knows these programs are massively complex and require years of work and knowledge - at least the polygonal approach :) Implicit surfaces / f-rep on the other hand... <3
I think there would absolutely be a market for a CAD program that was made specifically, and only for, hobbyists. Same for CAM.
Right now... almost all CAD programs are designed for professionals, and the hobbyist versions are just cut-down professional CAD programs. The biggest exception I see is SketchUp, which has a very simple and direct way of drawing directly on objects, and it's very easy to pick up, but it has no understanding of solids, parametric measurements, assemblies, or any of that. And so SketchUp is super popular with woodworkers, home remodeling agencies, small businesses, all these people we wouldn't normally think of as "big professional CAD users" even if that means they lose out on some of the improvements that professional CAD packages have (especially because SketchUp really hasn't changed much in over a decade).
A 3D solid parametric modeler with the ease of use of getting started with SketchUp. SketchUp with solids. I can dream.
> Plasticity really focused on UX, and license a kernel
Its good that author of Plasticity (@nkalen on HN) had finally switched[0] to use Parasolid (and abandoned previous plans to use Russian C3D kernel) after Russia started full scale invasion of Ukraine in 2022[1]... in eight years since Russia invaded Ukraine in 2014.[2]
> CAD program that was made specifically, and only for, hobbyists.
I see "hobbyists" as "prosumers", they want the same tools the professional use. Take a look at photography or wood working for example, people are spend thousands on professional level tools. I don't believe there is a market for hobbyist only cad software, that would be like making a camera that is only useful for hobbyist photographers. If it's good enough for a hobbyist it's good for a professional.
CAD for casual users, and true amateurs? Yes there is a market for that.
I would agree... but SketchUp is an example of how I think there is an audience for simpler tools.
SketchUp, most professional CAD modelers would think it is basically unusable. No constraints? No parametric modeling of any kind? No actual conception of solids (just faces and lines)? You just draw directly on the models without a 2D Sketch first, or dragging in a primitive? And yet... SketchUp is still really popular, within its own niche. It's not something you'd find anywhere on a "best CAD programs" list, but if you are an interior designer, or another field with simple 3D needs, odds are you'll find SketchUp everywhere.
So... it doesn't have to be a powerful CAD program to find an audience. It just has to be a tool that provides CAD to people who are in a very different field than CAD modelers.
Another example that I'm banging my head against: BobCAD-CAM. The 3D capabilities compared to most modelers are... pretty garbage. But if you are just trying to machine simple parts on a router, I will admit that if you don't stretch its capabilities, it is pretty fast and simple, and the integrated CAM is functional. I wouldn't really recommend it to anyone over separate tools (a CAD designer would hate it, a professional CAM user would hate it, but someone who is neither might find it a good tool that at least gets the job done).
The problem is CAD is too broad a term here, and we are mostly sticking to "cad for designing physical stuff".
Sketchup is certainly used by professionals, it has a number of niches where it's super successful. Particularly architecture and interior design, it's well used for quickly visualising and translating plans. You would never you it for product design, as you said.
I think (maybe wrongly) most people in the thread will be thinking "3D Parametric Solid Modelling CAD for Product Design", such as SolidWorks or freeCad. Even if you build a "simple" app in that product category it will still have to tackle all the same hard problems in its kernel as a pro app. It maybe even needs to be more robust.
If you're trying to design stuff for the real world, I think the closest thing you'll get to that is probably Fusion360- same engine as most other Autodesk stuff (I think) but easier to get started with, and your skills and habits can mostly move with you to bigger packages if you need to.
For other stuff like designing miniatures and stuff, I dunno, I don't do very much of that
Yeah, on the big kernels the time just getting filleting working robustly can be measured in developer-careers.
The core problem isn't memory safety, it's due to difficulties with the mathematical foundation of NURBS surfaces. For example, the intersection of two NURBS surfaces can't be exactly represented by a NURBS curve.
See for example Ian Stroud
”Boundary Representation Modelling Techniques” for a light introduction. The OpenCascade project is a fairly complete example of a complete one. But there is no ”by the book” way to do it - it requires both design and engineering savvy.
The simple explanation is the capability to model 3D shapes in a way that you can output the data to the rest of the manufacturing process. Hence what manifacturing process you target at least partially dictates your constraints.
The output could be - engineering drawings, CNC machines, 3D printers. Or another 3D modeling application down the pipeline.
In a way ”CAD kernel” alone is a worthless as a spec since it’s too general, just like ”a vehicle” is a useless spec for engineering.
CAD kernel- for modeling what, by whom, and where.
Naturally questions of numerical robustness and exactness of presentation soon enter the picture. How large or precise features do you need to model, for example.
In solvespace such curves are represented by handles to the two intersecting surfaces and a series of points along the curve. This is an exact representation (you can compute as many additional points on the curve as needed) but it's not analytic by any means. Exact NURBS curves are used when possible too.
Exactly, I'm sure you're familiar with the kinds of difficulties and complications that creates. Rather than representing that curve analytically, you have to keep track of the procedural tree that generated it. Then things like offsetting that curve, checking that curve for intersections, etc. are more complicated.
And then you export. Rather than exporting the entire procedural tree (which would require shipping the entire kernel), you approximate the curves with NURBS trimming curves. When you import from another CAD tool you need to deal with edges that only intersect within a given tolerance, and sometimes that tolerance is awful (Catia, I'm looking at you). Operations on toleranced edges are a huge source of complications.
And so on and so on. It would all be so much easier if the NURBS math could be exact
I remember hearing some anecdote about Solidworks development where someone was brought back to meet the Fikket TEAM, a team of like 10 people who just worked on fillers fr 15 years. That being said, the fileting in solidworks is killer
The last comment in that thread is me pointing to a related discussion about a bug in solvespace. Someone tried to cut a cone shape out of a flat surface and the boolean failed because of the degenerate normal at the vertex of the cone. It was days of discussion to select which few lines of code would be best to fix it.
BTW the solvespace NURBS kernel is under 10kloc and is fairly simple for what it's capable of. The bugs can be crazy to track down and require a deep understanding of what's going on in the code and geometry, but oh so rewarding to fix if that's your kind of puzzle.
About the scope of the job, remember that that which took 10 years 10 years ago, often does not take 10 years today. And there is nothing wrong with starting a 10 year project anyway, any day. They all have to start some time.
I think it is great we get another OSS B-Rep kernel, even more so in Rust. Who cares how long it takes? I can assure the naysayers it will take forever if you never start.
Some slightly condescending sounding comments here seem to assume that whoever posted this on HN is the author. And/or that there is a single author.
There is a Japanese company behid this[1].
Having worked in Japan my assumption would be there is a team of developers behind this with a single person doing the public facing commits/GH repo stuff.
Well, for one, having a renderer mixed into a geometry kernel is already a red flag for me. It's like starting to write an OS by deciding what the mascot should be... A geometry kernel shouldn't be concerned with rendering at all. 75% of the documentation is about managing the camera, the lights, the materials, etc. This isn't what a kernel should do.
There is no renderer mixed into anything. I would suggest you look at the actual crates. There is the truck-rendimpl crate and that is not relied on by any other truck-* crate that does actual B-Rep stuff.
I also think you confuse the book/tutorial with the documentation on docs.rs.
My impression is that the former is very much a work in progress. I never looked at it until now.
> It's like starting to write an OS by deciding what the mascot should be...
Honestly this isn't a great comparison. Plenty of projects decide branding early on. Deciding on a logo or mascot isn't really too different than picking a name. It's probably going to be one of the first three or so things you do when starting a project if someone on the project is at least moderately graphically inclined.
A better comparison to what you described would be someone starting to write an OS from scratch by writing the desktop environment first.
-"Rust and WebGPU. Advanced optimizations using Rust ..."
-"Safe implementation using Rust to eliminate core dumped ..."
My take - I do not give a flying hoot what it is written in. When / if I see end result that actually matters to users: say a tool competitive with something like Solidworks wake me up. And just for perspective - I do not remember SW ever core dumping on me even though it is written in "unsafe" C++.
> I do not remember SW ever core dumping on me even though it is written in "unsafe" C++.
The save-spamming impulse that I've developed from SW or AutoCAD just outright crashing on me (back when I used it regularly) makes me feel like I've had an entirely different experience from you.
No idea about AutoCAD. SW - I used it to create complete 3D model of fitness equipment approximately of high end treadmill complexity. The resulting model went to 2 factories to produce all the parts (except fasteners obviously). Haven't had single crash but of course I can bet that I did not use all the functionality. So maybe there are parts of SW that are less "stellar" but I did not encounter those.
45 comments
[ 25.3 ms ] story [ 2604 ms ] thread> There are other disadvantages to Code-CAD, of course. Making a sketch and applying some constraints can be very easy with a nice GUI, while having to type it all out would be very tedious.
> For that reason, I think the ideal CAD program would use a hybrid approach: Being code-first for all the reasons presented above, but letting you edit that code through graphical tools, where it makes sense. I'm not aware of any system that works like that, at least to the extent that is possible in principle. I believe that creating such a system would be a worthwhile effort.
As for 2D CAD apps, such feature already exists since 1980s when AutoLISP created for AutoCAD (opensource apps with similar scripting: QCAD, LibreCAD).
As for 3D CAD apps, and especially opensource, FreeCAD has ability to generate shapes or sketches with script and it would be possible to edit resulted geometry manually with GUI tools.
[0] https://www.fornjot.app/blog/code-cad-advantages/
> FreeCAD has ability to generate shapes or sketches with script and it would be possible to edit resulted geometry manually with GUI tools.
That sounds like the "normal" flow, where the first GUI editing action is destructive (= requires you to "emit" the parameterized geometry).
I think what is alluded to there, is something more akin to a visual Markdown editor, or newer visual React editors like Utopia[0], which are a departure from the old generation of WYSIWYG editors like Dreamweaver, where an edition action in either the code or the visual mode wreaked havoc on the state of the other mode.
[0]: https://utopia.app/
See "Modify" commands in LibreCAD.[0]
[0] https://wiki.librecad.org/index.php?title=Commands_and_tools...
[0] https://news.ycombinator.com/item?id=35071317#35073677
FreeCAD & SolveSpace are C++. After 30+ years of that language and four years of Rust I won't touch the former with a ten foot pole unless it's an extraordinarily well paid gig.
I wouldn't be suprised if the author of fornjot had similar feelings if they ever considered that approach.
fornjot is a hobby project. 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. ;)
> 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".
We can debate the merits of tools... but deliberately selecting any tool because it is "trendy" seems like a bad idea to openly state. Writing a CAD Kernel is extremely difficult (thus why there are, like, 3-4 in use in all CAD packages right now, Parasolid is everywhere)... so the last thing we need is a trendy tool over a pragmatic one.
Maybe "trendy" is a bad way to express it but I like the idea that 'yeah, we know it's a huge job to start from scratch, but so what? in 20 years it won't be starting from scratch any more, and should we just accept that the last cad kernel in history has already been written and a company owns it, and surely there are things that would be good, that can only be decided on day one and can't be retroactively decided in any existing kernel.' etc etc
I know rust isn't magic or anything but I also know that paradigms and frameworks matter, and starting from scratch in a strict environment like rust where there is just a lot of pain in the neck rigor in every molecule, seems like it could have a great effect on something that needs to eventually grow into a huge and complex thing where the higher levels really really need to trust the lower levels to always be bulletproof correct.
Rust's concerns were originally security, but security is just correctness, and correctness is valuable everywhere.
And even the "trendy" aspect... I'm fine with it if it's consciously expressed up front like that. Rust plus webgpu? ok, sounds like a reasonable starting premis. Why not?
If anything you want a formal verification language.
The 'Trendy' comes from the wish to use titles for the guiding priciples that start with the letter 'T' because 'truck' does.
That's what I learned when I submitted a PR with an "improved" README that kept the alliteration but had all three guiding principles start with the letter 'U' instead. It got refused. :)
Think of it what you will but for me it's fine if the README and parts of the docs are a bit Anglish sounding as long as the code is solid and I can understand what is meant.
Based on the docs, you've only implemented some very basic topological operations (and rendering, for some reason). The hard part is going to be implementing the rest: boolean operations, offset surfaces, lofted surfaces, blended surfaces, etc. and then there's the problem of version control / edit history. Efficiently and accurately implementing each of these can be a year-long research project in itself... You need a solid understanding of 3D topology, numerical methods, 3D differential geometry, etc.
Nevertheless, I wish you luck! I will check back in a year or so.
It's also tricky to implement a kernel in a good, modular, well-designed manner. Take a look at OpenCASCADE, the kernel used by FreeCAD. And holding back FreeCAD. It's been in development for 24 years and it hasn't hit anywhere close to Parasolid yet.
But yeah, 100% this. Anyone familiar with the space knows these programs are massively complex and require years of work and knowledge - at least the polygonal approach :) Implicit surfaces / f-rep on the other hand... <3
Edit: Durr: 株式会社ＲＩＣＯＳ / RICOS Co. Ltd.
Right now... almost all CAD programs are designed for professionals, and the hobbyist versions are just cut-down professional CAD programs. The biggest exception I see is SketchUp, which has a very simple and direct way of drawing directly on objects, and it's very easy to pick up, but it has no understanding of solids, parametric measurements, assemblies, or any of that. And so SketchUp is super popular with woodworkers, home remodeling agencies, small businesses, all these people we wouldn't normally think of as "big professional CAD users" even if that means they lose out on some of the improvements that professional CAD packages have (especially because SketchUp really hasn't changed much in over a decade).
A 3D solid parametric modeler with the ease of use of getting started with SketchUp. SketchUp with solids. I can dream.
Both are really focused on UX, and license a kernel
Plasticity though is gorgeous, especially for a solo developer. Wow.
Its good that author of Plasticity (@nkalen on HN) had finally switched[0] to use Parasolid (and abandoned previous plans to use Russian C3D kernel) after Russia started full scale invasion of Ukraine in 2022[1]... in eight years since Russia invaded Ukraine in 2014.[2]
N.B. https://en.wikipedia.org/wiki/Russo-Ukrainian_War
[0] https://news.ycombinator.com/item?id=30696305
[1] https://twitter.com/nk/status/441096177933905920
[2] https://twitter.com/nk/status/1507672831559151620
I see "hobbyists" as "prosumers", they want the same tools the professional use. Take a look at photography or wood working for example, people are spend thousands on professional level tools. I don't believe there is a market for hobbyist only cad software, that would be like making a camera that is only useful for hobbyist photographers. If it's good enough for a hobbyist it's good for a professional.
CAD for casual users, and true amateurs? Yes there is a market for that.
SketchUp, most professional CAD modelers would think it is basically unusable. No constraints? No parametric modeling of any kind? No actual conception of solids (just faces and lines)? You just draw directly on the models without a 2D Sketch first, or dragging in a primitive? And yet... SketchUp is still really popular, within its own niche. It's not something you'd find anywhere on a "best CAD programs" list, but if you are an interior designer, or another field with simple 3D needs, odds are you'll find SketchUp everywhere.
So... it doesn't have to be a powerful CAD program to find an audience. It just has to be a tool that provides CAD to people who are in a very different field than CAD modelers.
Another example that I'm banging my head against: BobCAD-CAM. The 3D capabilities compared to most modelers are... pretty garbage. But if you are just trying to machine simple parts on a router, I will admit that if you don't stretch its capabilities, it is pretty fast and simple, and the integrated CAM is functional. I wouldn't really recommend it to anyone over separate tools (a CAD designer would hate it, a professional CAM user would hate it, but someone who is neither might find it a good tool that at least gets the job done).
Sketchup is certainly used by professionals, it has a number of niches where it's super successful. Particularly architecture and interior design, it's well used for quickly visualising and translating plans. You would never you it for product design, as you said.
I think (maybe wrongly) most people in the thread will be thinking "3D Parametric Solid Modelling CAD for Product Design", such as SolidWorks or freeCad. Even if you build a "simple" app in that product category it will still have to tackle all the same hard problems in its kernel as a pro app. It maybe even needs to be more robust.
For other stuff like designing miniatures and stuff, I dunno, I don't do very much of that
The core problem isn't memory safety, it's due to difficulties with the mathematical foundation of NURBS surfaces. For example, the intersection of two NURBS surfaces can't be exactly represented by a NURBS curve.
The simple explanation is the capability to model 3D shapes in a way that you can output the data to the rest of the manufacturing process. Hence what manifacturing process you target at least partially dictates your constraints.
The output could be - engineering drawings, CNC machines, 3D printers. Or another 3D modeling application down the pipeline.
In a way ”CAD kernel” alone is a worthless as a spec since it’s too general, just like ”a vehicle” is a useless spec for engineering.
CAD kernel- for modeling what, by whom, and where.
Naturally questions of numerical robustness and exactness of presentation soon enter the picture. How large or precise features do you need to model, for example.
And then you export. Rather than exporting the entire procedural tree (which would require shipping the entire kernel), you approximate the curves with NURBS trimming curves. When you import from another CAD tool you need to deal with edges that only intersect within a given tolerance, and sometimes that tolerance is awful (Catia, I'm looking at you). Operations on toleranced edges are a huge source of complications.
And so on and so on. It would all be so much easier if the NURBS math could be exact
Maybe SolidWorks handles it better.
https://github.com/ricosjp/truck/issues/5
The last comment in that thread is me pointing to a related discussion about a bug in solvespace. Someone tried to cut a cone shape out of a flat surface and the boolean failed because of the degenerate normal at the vertex of the cone. It was days of discussion to select which few lines of code would be best to fix it.
BTW the solvespace NURBS kernel is under 10kloc and is fairly simple for what it's capable of. The bugs can be crazy to track down and require a deep understanding of what's going on in the code and geometry, but oh so rewarding to fix if that's your kind of puzzle.
Haven’t read much, but it sounds intriguing…
Some slightly condescending sounding comments here seem to assume that whoever posted this on HN is the author. And/or that there is a single author.
There is a Japanese company behid this[1].
Having worked in Japan my assumption would be there is a team of developers behind this with a single person doing the public facing commits/GH repo stuff.
[1] https://www.ricos.ltd/
I also think you confuse the book/tutorial with the documentation on docs.rs.
My impression is that the former is very much a work in progress. I never looked at it until now.
The latter (and the examples in the resp. crates) is what you want to check out to see the kernel being used. E.g. https://github.com/ricosjp/truck/blob/master/truck-modeling/...
The main README has links to all the documentation of the crates.
Honestly this isn't a great comparison. Plenty of projects decide branding early on. Deciding on a logo or mascot isn't really too different than picking a name. It's probably going to be one of the first three or so things you do when starting a project if someone on the project is at least moderately graphically inclined.
A better comparison to what you described would be someone starting to write an OS from scratch by writing the desktop environment first.
-"Safe implementation using Rust to eliminate core dumped ..."
My take - I do not give a flying hoot what it is written in. When / if I see end result that actually matters to users: say a tool competitive with something like Solidworks wake me up. And just for perspective - I do not remember SW ever core dumping on me even though it is written in "unsafe" C++.
The save-spamming impulse that I've developed from SW or AutoCAD just outright crashing on me (back when I used it regularly) makes me feel like I've had an entirely different experience from you.