Truck: CAD Kernel in Rust
github.com
github.com
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
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.
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.
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.
> 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.
> 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...
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".
-"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.
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.
Haven’t read much, but it sounds intriguing…