Interestingly, ttouch created browser-based CAD tool CADmium a few years ago based on Truck. Then, a few months ago, they created another one (CADara) based on OpenCASCADE: https://news.ycombinator.com/item?id=48070083.
Truck seems cool, but creating a b-rep kernel is a phenomenal amount of work. Given that, I'm curious how quickly SolidCraft will mature.
YuechenLi 15 hours ago [-]
> Creating a b-rep kernel is a phenomenal amount of work
Well, I did it, took 6 months, and I think I'm ahead of Truck on that front since as far as I can tell Truck can still only do single edge fillets with Newton's method as their new fillet algorithm, whereas my kernel can do planar fillet chains fairly reliably.
I wish someone would wrap a frontend around it too considering I'm bad at designing UIs, and the architecture is too weird to put a conventional 3D CAD UI on it that I'm honestly hoping someone would throw their LLM at that task.
Also, sorry about the excessive self-promotion, but I think most people would be shouting from the mountaintop if they built a BREP geometry kernel from scratch solo too.
phil-martin 14 hours ago [-]
Fascinating repo, thank you for making it!
I’m curious, what does this part mean?
“ Dangerous operations which may generate degenerate/sliver/zero-dimension geometries are instead blocked from materializing to 3D at a compiler level.”
How is that achieved, or rather what does that mean? What defines a sliver?
YuechenLi 14 hours ago [-]
A sliver is basically a tiny degenerate geometry in the micro/nanometer scale that's basically the result of ambiguous surface intersections. Basically, if you put two say, cylindrical surfaces against each other in NURBS form, floating point noise would generate these microscopic geometric noises, and a lot of what commercial kernel does is they use what they call "healing" operations to clean up those bad microscopic geometries from the models they generate.
Aetheris took a very obvious approach that not many have seemed to tried before: It throws an error when an operation that may create ambiguous intersections and refuses to materialize bad geometry in the first place, which is not really possible to do with traditional NURBS based kernels, whereas Aetheris can because it is analytical first.
SOLAR_FIELDS 12 hours ago [-]
You see slivers in 2D spatial operations as well. Imagine that you have two parcels represented as polygons that don’t perfectly spatially intersect. If you perform a boolean operation to, say, compute the union of these two polygons into a single one, any microscopic difference between the two boundaries below a certain tolerance (like 0.001 square meters) will manifest itself as tiny gaps and slivers. Most GIS engines will merge the two polygons appropriately beyond that tolerance (this is a way simpler problem in 2D space!) but if the data is bad enough you’ll definitely see it.
phil-martin 3 hours ago [-]
Thanks for the explanation, appreciate it!
Sorry for asking for definitions - since Aethris is such a different architecture, I want to make sure we’re using the same language.
When you say “models they generate” do you mean the the nurbs representation, or the tessellated geometry for rendering?
On a related topic how does Aetheris perform when defining a screw thread? Or a nut thread?
YuechenLi 1 hours ago [-]
Aetheris generates STEP AP242 BREP directly, the tessellated mesh generated is only used for display (although currently, I've switched to a WebGPU based SDF representation so the surfaces can be smooth). One of the key differences in the architecture Aetheris doesn't export rational b-splines outside of debug or STEP passthrough and instead tries to recover and export analytical and non-rational splines instead.
On screw thread, if you mean by "how do you make a screw thread in Aetheris", you can check out the actual code for a threaded bolt I built for a showcase here with the JSON like DSL called Firmament:
Which is why I said that it's really hard to think of an editor UI for Aetheris that's not just a text editor or a ComfyUI like graph visual programming or something.
If you mean compile speed wise, not great right now, it wasn't that much of an issue when running on RyuJIT natively since it's still acceptable, but currently WASM cold compile speed for a moderately sized assembly is around 4-5 minutes so there is a lot more work to be done before I'm ready to put it on a cloud server.
zamalek 8 hours ago [-]
While this is technically correct behavior, users will interpret that as your software not being able to do something - or as a bug (because it works on one drawing but not another).
YuechenLi 7 hours ago [-]
Well, this is more similar to a linter/borrow checker than anything else, because if you catch errors at compile time, the bad geometry doesn't persist in the STEP artifact that's being generated, so analogous to the philosophy of Rust vs C++ really.
The current design is meant to be import tolerant but export strict, it imported most STEP file I throw at it fine after a bunch of fixes, but I don't really have a big enough sample corpus know for sure how much real world STEP file it can handle.
well_ackshually 8 hours ago [-]
> if they built a BREP geometry kernel from scratch solo too.
But you didn't, Claude did. Your commits display it.
16bytes 5 hours ago [-]
A lay person doesn't have the skill-set to tell Claude how to do something like this. Experts extract much more value out of a domain than amateurs.
Yes? It's a back and forth discussion, where the model's output (that is much more pluridisciplinary than Terrance will ever be and therefore benefits from the common knowledge of not just an entire field, but thousands of fields over thousands of cultures) actively drives his responses and verifications. Literally, the entire set of messages is "you said X. Does that therefore entail Y in what you said ?". Terrance being an expert knows how to drive the conversation in angles which he explored, but it remains that the bulk of the work is done by Claude.
If I keep asking clarifying questions to Albert Einstein, that doesn't make me the inventor of relativistic physics, no matter how much I know about the subject.
I'm not contradicting OP's expertise on the subject: they seem to at the very least know what they're talking about. But saying "I" did this when all you did is prompt the funny slot machine and approximately none of the code is reviewed (6 commits per day, each being 50+ files on average is not something you have reviewed or understood.) is lying to others and to yourself.
atonse 2 hours ago [-]
I couldn't build this even with Claude Mythos, I have no freaking clue what this stuff is, and I'm a full time software developer that understands performance optimization and even has used SketchUp a lot.
I'm telling you, I simply couldn't do it. Unless the prompt is "copy every single feature in AutoDesk Fusion 360" and sit back, and even then, I wouldn't even know where to start with testing it, knowing whether it works properly, and whether the various tools are useful, performant, etc.
Let's not assume that the code is the most important part, it's important, but domain knowledge is still very important.
dofm 16 hours ago [-]
FWIW I don't think it makes sense to copy anyone's CAD program, and I am negatively disposed to the ArtCraft thing as a general position. I think it's fully the wrong approach.
But I am here for LLMs, if they really can be used to solve maths, to solve CAD maths, which is, as you say, the really difficult stuff.
I am still not going to use an early-stage CAD package, but this actually would be a meaningful contribution to society. The rest is a bit AI NIH.
GhostXFace 14 hours ago [-]
They are working on a Rust port for the SMLib geometric kernel subset that NVIDIA open-sourced yesterday as part of their new USD BRep library:
If the experiment does work out and the library NVIDIA open-sourced proves to be mathematically robust enough for standalone CAD use, it would leapfrog OpenCASCADE kernel for open-source CAD (solved math that was previously propriety, graceful failures without crashes, multiple CPU threads, running smoothly on web browsers).
bherbruck 8 hours ago [-]
If anyone wants to help out, feel free to point an agent at it. The tests are supposedly deterministic
darksaints 5 hours ago [-]
Are you running with this port because of the slowness that Truck has had in merging new code from outside contributors? It seems like that was the reason for the MonsterTruck fork of Truck, which also has some promising features that aren't present in Truck.
Personally, I've been planning out work to create a build123d-like python scripting environment which wraps the Truck kernel, in the hopes that one day Truck will be mature enough (so many problems with fillets!) to surpass OpenCASCADE.
As much as I hate Design By Committee, a CAD kernel is a massive undertaking and it would be nice to not have 20 different projects all working on cool features that are not compatible with others because every project took its own path. It might be worth finding others actively working in this space and see if there could be a shared vision that we could all work towards together. Things like fillets, solutions to the topological naming problem, etc., are gonna take a lot of smart minds working together to really solve.
I'd gladly shell out a bunch of tokens to help create that vision, but I'd have to say I'm not exactly the person to architect that vision myself.
So far it is a straight port of the recently open-sourced smlib, it covers A LOT of what we need. Feel free to point an agent at it, there's like a "take a ticket" triage-like system for who's working on what functions
larodi 17 hours ago [-]
People don’t get the super high value proposition in having these all *Craft packages controlled (automated) by AI. Most of the companies who are the kingmakers in the given area, do not allow it easily or are hard to integrate (costly) with, or did allow back in time and don’t now.
Given much can be automated in 2026, these (promoted goodies) may come as the missing link in innumerable automation chains, and particularly where commercial agents aim for when they sell costly licensing.
It also indirectly fights piracy and the risks which come with pirated copies (sidelined with funny stuff).
dingring4 3 hours ago [-]
This is indeed the most exciting thing. It feels a bit scary how good the frontier models are at creating stuff with these apps (that are like a few days old and very incomplete pre alpha stage yet already somewhat functional). The future is happening and I just spent a day rethinking my whole life.
jerkstate 11 hours ago [-]
this stuff is a game changer for implementing workflows with some user-facing interaction. I was working on a desktop publishing webapp with a specific slant, the previous iteration of the graphical editor UI was not very good, in order to build anything you have to specifically instruct the agent how every little interaction works, and my recollection and description was often different from how the "standard" desktop publishing flow works (i.e.: this is the sequence of actions to expand a selected entity preserving the aspect ratio, here's how to preserve the center-point, here's how to multi-select, etc). I told the agent "take the frontend from vectorcraft, adopt this specific subset of tools, build it for wasm, and plug in my agent tools and storage backend" - and within a day of deciding to adopt it, I had a much higher quality editor interface that anyone with desktop publishing experience will immediately know how to use, plugged into my storage format.
unixhero 15 hours ago [-]
Oh my God you are right.
BizarroLand 7 hours ago [-]
There's also the side effect that, just like with Libreoffice, they will be integrated into future harnesses for AI by anthropic and openai and others so that their platforms will be able to run these programs locally and spit out the results.
phkahler 9 hours ago [-]
I don't see this moving very fast. On Solvespace we recently had a bunch of commits by Claude to fix NURBS boolean issues. The analysis was actually very impressive and most of the fixes were accepted after a lot of review by multiple experts on the code. I don't see this project getting far on the hard problems they still have open.
IMHO they should have had AI convert OCCT kernel to rust, or just wrap it and use as-is.
BTW we are on the verge of solvespace 3.3 with those AI fixes. After that I'm adding the named parameters that have been prototypes 12 times already. There are also a couple forks out there with MCP server added, but I want to focus on missing features.
rspeele 6 hours ago [-]
Thanks for your work on Solvespace. I have been using it for years. When I no longer had access to commercial CAD programs I tried all the open source stuff. My conclusions were:
* OpenSCAD -- cool idea, good for a few types of highly procedural parts, but most of the time I'd rather a parametric sketch-based interface over pure code.
* FreeCAD -- the most features of any open source CAD, but poor UI, tendency to crash, and the advanced features like loft kind of fall flat compared to commercial equivalents. You think you'll be able to model a part, but it becomes extremely frustrating if you actually need the advanced tools.
* SolveSpace -- pretty stable and reliable. Fast, compact, great sketching interface, good discoverable UI. You can predict what types of parts you can model with it and what types you can't. Doesn't try to do everything but is good at what it does.
You can tell which one is my favorite! N features done to a good level of polish and with somebody making sure it all "makes sense together" beats 10xN features all 80% done and haphazardly mashed together in different menus/workbenches, for any tools I want to rely on.
I am noodling around with a slopcoded CAD tool of my own these days, just out of curiosity to see how far Opus5.5/GPT6 can get doing it in F# and to experiment with some workflow concepts that match the way I like to design parts. But like you said, progress is slow. For stuff I actually want to get done, SolveSpace remains my go-to, and I greatly admire its coherent design.
YuechenLi 6 hours ago [-]
I think I've seen ports of OCCT to Rust as well as Rust wrappers for OCCT floating around Github once or twice already.
However, OpenCascade being C++ instead of Rust is the least of its problems, the main issue is OCCT's boolean/blend engines aren't really as robust as the commercial kernels, and handling arbitrary 3D boolean edge cases one by one correctly is one of the main difficulties of a geometry kernel.
Very interested in SolveSpace's progress on this really.
phkahler 4 hours ago [-]
>> Very interested in SolveSpace's progress on this really
Its good progress but still too easy to have a failed boolean. Previously you had to know how to work around bugs to cut a fillet off an edge. Now thats pretty easy and robust, but as soon as you do two of them that intersect there may be a problem. Like you said, the list of corner cases never end. I suspect a bit more Claude use might fix that one too.
jpettersson 10 hours ago [-]
Thanks for making this! I tried some hobby level modelling and it seems very capable. I've been a heavy user of fusion360 in the past but I've been longing for an open alternative.
phkahler 8 hours ago [-]
About a year ago I challenged folks to move solvespace from GTK3 to GTK4. People here were highly skeptical as I was. A couple people tried and the PRs I got were terrible. A few months ago someone did it with Claude and we now have a very nice GTK4 branch which I hope to merge soon. AI has come a long way.
Fabricio20 11 hours ago [-]
Interesting, I thought this was part of the *Craft family but that one is called CadCraft. I do prefer the take on using Fusion as the UI base.
mijoharas 15 hours ago [-]
Interested to try this out.
I played around with Freecad mcp, and then also with having an agent generate some openscad before.
For the Freecad mcp I didn't like it at all. The agent didn't work in a way that would let me easily modify things. I hadn't given it instructions, but it didn't really create sketches and then extrude them (after checking they're all fully parameterized.)
For openscad the problem was just that while the model could do it, the lack of "visual reasoning" (for want of a better word) really held it back. There was a nice workflow there though by giving it a little "generate_image" of part tool and it could make a nice iterative loop.
Overall for both approaches it was slower than if I'd done it myself (and I'm not particularly good at 3d modelling). Now, that's not that surprising given that I was trying something new, but without being able to edit things generated by the AI myself I wouldn't want to try it again.
Now, maybe this solution can work in the way I'd want to. I may give this a go next time I have something I want to make.
InsidiousWombat 12 hours ago [-]
I've had a lot of success with FreeCAD, no need for MCP when the LLM can just write Python code to generate the file.
Interestingly enough I was trying to make a simple(ish) workbench project using that and LLM made both the "generate the project" program and "run thru the checks" program, where it encoded stuff I asked it to fix (like making sure the bench feet are sitting under the posts, or that there is no holes in the floor).
Ended up building it and on one side I was impressed that it mostly was fine, on other there were clear issues that wouldn't happen if someone actually experienced with it designed it, it just wasn't designed to be put together easily
wccrawford 13 hours ago [-]
FreeCad had problems for years with certain functions when changing parameters. Does this avoid those problems from the start?
IIRC, FreeCad has at least partially addressed the remaining problems with that recently.
u8080 11 hours ago [-]
Looks awesome, for some reason I liked that much more then FreeCAD. Fingers crossed that will actually be supported and survive DMCA
zamalek 8 hours ago [-]
What concerns me about moving to AI-generated software is that CAD files have extreme longevity. Will the project be active in 5 years?
brunoborges 8 hours ago [-]
Would this post get as much attention as it is getting if it wasn't for the "in Rust" in the title?
maidaman 7 hours ago [-]
Running in the browser is the best part. Can actually use it at work without asking IT.
rts-gordon 14 hours ago [-]
Interesting product and will try this.
Could you please confirm if 3D printing functionality is supported? This feature would be very useful for professionals. Thank you.
WillAdams 12 hours ago [-]
There are two, maybe three levels of support for 3D printing:
- exporting an STL so that a Slicer may be used to prepare the file for 3D printing --- https://github.com/bherbruck/solidcraft notes "Export to STEP...3MF...STL and OBJ
so that basic support is there, but the further levels of:
- slicing a 3D model
- sending a model/managing a 3D printer/farm
do not seem to be --- given that there are quite robust solutions for those, I feel that the Unix philosophy of chaining small tools makes sense here.
GhostXFace 13 hours ago [-]
[dead]
carra 17 hours ago [-]
Very interesting. Looking at the images I'm not sure if this is based on Autodesk Inventor (plausible since they already imitated AutoCAD), or in Solid Edge (given the name).
dingring4 2 hours ago [-]
Fusion is the main idea behind solidcraft as far as I know. But it is NOT aiming to be a copy of anything featurewise unlike most stuff associated with artcraft (and solidcraft is not an official artcraft app despite the name, at least not yet).
LiamPowell 17 hours ago [-]
It looks a lot like Fusion, where Autodesk took all the passable UI and UX from Inventor and replaced it with absolute garbage.
pinkpall 15 hours ago [-]
I think having these abundance of alternatives is positive, overall. We need a way to find good ones.
Interestingly, ttouch created browser-based CAD tool CADmium a few years ago based on Truck. Then, a few months ago, they created another one (CADara) based on OpenCASCADE: https://news.ycombinator.com/item?id=48070083.
Truck seems cool, but creating a b-rep kernel is a phenomenal amount of work. Given that, I'm curious how quickly SolidCraft will mature.
Well, I did it, took 6 months, and I think I'm ahead of Truck on that front since as far as I can tell Truck can still only do single edge fillets with Newton's method as their new fillet algorithm, whereas my kernel can do planar fillet chains fairly reliably.
I wish someone would wrap a frontend around it too considering I'm bad at designing UIs, and the architecture is too weird to put a conventional 3D CAD UI on it that I'm honestly hoping someone would throw their LLM at that task.
https://github.com/yuechen-li-dev/Aetheris/
Also, sorry about the excessive self-promotion, but I think most people would be shouting from the mountaintop if they built a BREP geometry kernel from scratch solo too.
I’m curious, what does this part mean?
“ Dangerous operations which may generate degenerate/sliver/zero-dimension geometries are instead blocked from materializing to 3D at a compiler level.”
How is that achieved, or rather what does that mean? What defines a sliver?
Aetheris took a very obvious approach that not many have seemed to tried before: It throws an error when an operation that may create ambiguous intersections and refuses to materialize bad geometry in the first place, which is not really possible to do with traditional NURBS based kernels, whereas Aetheris can because it is analytical first.
Sorry for asking for definitions - since Aethris is such a different architecture, I want to make sure we’re using the same language.
When you say “models they generate” do you mean the the nurbs representation, or the tessellated geometry for rendering?
On a related topic how does Aetheris perform when defining a screw thread? Or a nut thread?
On screw thread, if you mean by "how do you make a screw thread in Aetheris", you can check out the actual code for a threaded bolt I built for a showcase here with the JSON like DSL called Firmament:
https://github.com/yuechen-li-dev/Aetheris/blob/master/fixtu...
So, the high-level surface language of defining a screw thread is basically a struct/record that looks like:
Which is why I said that it's really hard to think of an editor UI for Aetheris that's not just a text editor or a ComfyUI like graph visual programming or something.If you mean compile speed wise, not great right now, it wasn't that much of an issue when running on RyuJIT natively since it's still acceptable, but currently WASM cold compile speed for a moderately sized assembly is around 4-5 minutes so there is a lot more work to be done before I'm ready to put it on a cloud server.
The current design is meant to be import tolerant but export strict, it imported most STEP file I throw at it fine after a bunch of fixes, but I don't really have a big enough sample corpus know for sure how much real world STEP file it can handle.
But you didn't, Claude did. Your commits display it.
Would you tell Terrance Tao that they didn't produce [this conversation](https://chatgpt.com/share/6a5fdc7a-d6f8-83e8-bbea-8deb42cfed...), the model did?
If I keep asking clarifying questions to Albert Einstein, that doesn't make me the inventor of relativistic physics, no matter how much I know about the subject.
I'm not contradicting OP's expertise on the subject: they seem to at the very least know what they're talking about. But saying "I" did this when all you did is prompt the funny slot machine and approximately none of the code is reviewed (6 commits per day, each being 50+ files on average is not something you have reviewed or understood.) is lying to others and to yourself.
I'm telling you, I simply couldn't do it. Unless the prompt is "copy every single feature in AutoDesk Fusion 360" and sit back, and even then, I wouldn't even know where to start with testing it, knowing whether it works properly, and whether the various tools are useful, performant, etc.
Let's not assume that the code is the most important part, it's important, but domain knowledge is still very important.
But I am here for LLMs, if they really can be used to solve maths, to solve CAD maths, which is, as you say, the really difficult stuff.
I am still not going to use an early-stage CAD package, but this actually would be a meaningful contribution to society. The rest is a bit AI NIH.
https://github.com/bherbruck/solidcore
If the experiment does work out and the library NVIDIA open-sourced proves to be mathematically robust enough for standalone CAD use, it would leapfrog OpenCASCADE kernel for open-source CAD (solved math that was previously propriety, graceful failures without crashes, multiple CPU threads, running smoothly on web browsers).
Personally, I've been planning out work to create a build123d-like python scripting environment which wraps the Truck kernel, in the hopes that one day Truck will be mature enough (so many problems with fillets!) to surpass OpenCASCADE.
As much as I hate Design By Committee, a CAD kernel is a massive undertaking and it would be nice to not have 20 different projects all working on cool features that are not compatible with others because every project took its own path. It might be worth finding others actively working in this space and see if there could be a shared vision that we could all work towards together. Things like fillets, solutions to the topological naming problem, etc., are gonna take a lot of smart minds working together to really solve.
I'd gladly shell out a bunch of tokens to help create that vision, but I'd have to say I'm not exactly the person to architect that vision myself.
https://crates.io/crates/monstertruck
Given much can be automated in 2026, these (promoted goodies) may come as the missing link in innumerable automation chains, and particularly where commercial agents aim for when they sell costly licensing.
It also indirectly fights piracy and the risks which come with pirated copies (sidelined with funny stuff).
IMHO they should have had AI convert OCCT kernel to rust, or just wrap it and use as-is.
BTW we are on the verge of solvespace 3.3 with those AI fixes. After that I'm adding the named parameters that have been prototypes 12 times already. There are also a couple forks out there with MCP server added, but I want to focus on missing features.
* OpenSCAD -- cool idea, good for a few types of highly procedural parts, but most of the time I'd rather a parametric sketch-based interface over pure code.
* FreeCAD -- the most features of any open source CAD, but poor UI, tendency to crash, and the advanced features like loft kind of fall flat compared to commercial equivalents. You think you'll be able to model a part, but it becomes extremely frustrating if you actually need the advanced tools.
* SolveSpace -- pretty stable and reliable. Fast, compact, great sketching interface, good discoverable UI. You can predict what types of parts you can model with it and what types you can't. Doesn't try to do everything but is good at what it does.
You can tell which one is my favorite! N features done to a good level of polish and with somebody making sure it all "makes sense together" beats 10xN features all 80% done and haphazardly mashed together in different menus/workbenches, for any tools I want to rely on.
I am noodling around with a slopcoded CAD tool of my own these days, just out of curiosity to see how far Opus5.5/GPT6 can get doing it in F# and to experiment with some workflow concepts that match the way I like to design parts. But like you said, progress is slow. For stuff I actually want to get done, SolveSpace remains my go-to, and I greatly admire its coherent design.
However, OpenCascade being C++ instead of Rust is the least of its problems, the main issue is OCCT's boolean/blend engines aren't really as robust as the commercial kernels, and handling arbitrary 3D boolean edge cases one by one correctly is one of the main difficulties of a geometry kernel.
Very interested in SolveSpace's progress on this really.
Its good progress but still too easy to have a failed boolean. Previously you had to know how to work around bugs to cut a fillet off an edge. Now thats pretty easy and robust, but as soon as you do two of them that intersect there may be a problem. Like you said, the list of corner cases never end. I suspect a bit more Claude use might fix that one too.
I played around with Freecad mcp, and then also with having an agent generate some openscad before.
For the Freecad mcp I didn't like it at all. The agent didn't work in a way that would let me easily modify things. I hadn't given it instructions, but it didn't really create sketches and then extrude them (after checking they're all fully parameterized.)
For openscad the problem was just that while the model could do it, the lack of "visual reasoning" (for want of a better word) really held it back. There was a nice workflow there though by giving it a little "generate_image" of part tool and it could make a nice iterative loop.
Overall for both approaches it was slower than if I'd done it myself (and I'm not particularly good at 3d modelling). Now, that's not that surprising given that I was trying something new, but without being able to edit things generated by the AI myself I wouldn't want to try it again.
Now, maybe this solution can work in the way I'd want to. I may give this a go next time I have something I want to make.
Interestingly enough I was trying to make a simple(ish) workbench project using that and LLM made both the "generate the project" program and "run thru the checks" program, where it encoded stuff I asked it to fix (like making sure the bench feet are sitting under the posts, or that there is no holes in the floor).
Ended up building it and on one side I was impressed that it mostly was fine, on other there were clear issues that wouldn't happen if someone actually experienced with it designed it, it just wasn't designed to be put together easily
IIRC, FreeCad has at least partially addressed the remaining problems with that recently.
Could you please confirm if 3D printing functionality is supported? This feature would be very useful for professionals. Thank you.
- exporting an STL so that a Slicer may be used to prepare the file for 3D printing --- https://github.com/bherbruck/solidcraft notes "Export to STEP...3MF...STL and OBJ
so that basic support is there, but the further levels of:
- slicing a 3D model
- sending a model/managing a 3D printer/farm
do not seem to be --- given that there are quite robust solutions for those, I feel that the Unix philosophy of chaining small tools makes sense here.