mkeeter
jcgrillo
This is really great, thank you for doing this.
Tangentially, while browsing through your blog I found this: https://www.mattkeeter.com/projects/machined-pen/the_plan.jp...
This illustrates beautifully an idea that's been rattling around in my head for a while: what if the process you went through to design this manufacturing plan was the user facing cad api? When I approach a "making" problem--whether it's carpentry, plumbing, metal fabrication, machining--I naturally think about it in much the same way you did here. What raw materials am I starting with? What tools do I have? What sequence of operations do I need to perform to achieve the desired end result? The "cad api" (literally an api in the case of code cad tools or the visual representation thereof in traditional mouse driven interfaces) does not work this way, and forces me to think about how to represent the finished shape not about how I'll actually make it. All I care about in the end is making a thing, the modeling is just a tool to assist in that process but it makes itself way too visible.
Naively it seems like there would be so many benefits to having a more "reality based" modeling workflow. As someone who clearly has a lot more experience in the cad space than I do, do you think this concept could go anywhere or is it a dead end?
EDIT: also, a bit of feedback on the pen: you can maintain concentricity if you do something like this:
1. grab the bar stock in a 3 jaw chuck and turn it to a dimension suitable for a collet
2. cut off three blanks from the dimensioned rod, one for your cap and two for the body
3. do the rest of the work using a collet for work holding
The tradeoff is you'll waste a bit this way if you want a different final dimension than you have for your collet.
ynrfin
Hi Matt, Thank you for publishing this. I have a fear creating article on my blog because I thought that what I know is not interesting enough. Your last section is a moodboster and reminder for me, that I should not take myself too seriously and enjoy programming as fun activities
Cheers
jerome-jh
Hi Matt, Since you're here I have a quick question. I did not do my homework so please excuse if that's too general or stupid.
How does Fidget differ from libfive and Ao, functionality wise?
Thanks in advance.
mkeeter
Here's a quick list, off the top of my head:
"Ao" was an early codename for libfive, so those are the same thing (at different stages of development).
Fidget is written in Rust, versus C/C++ for libfive. This makes it easier to use as a dependency (in Rust projects) and cross-compile to WebAssembly. Also, I don't have to debug segfaults anymore, except when touching the raw assembly in the JIT.
They both implement a similar set of algorithms (meshing, 2D and 3D rasterization).
Fidget has the potential to be faster due to its JIT, and is faster for 2D / 3D rasterization. (I suspect that the non-JIT interpreter is also faster at rasterization, for architectural reasons)
libfive has more effort put into its meshing algorithms, so it does a better job of handling edge cases (heh). I've heard reports that libfive is faster than Fidget at meshing, but haven't done much investigation.
Fidget is not limited to 2D and 3D functions: it can be used wherever you want to quickly evaluation graphs of math, with arbitrary numbers of inputs and outputs. libfive, on the other hand, is specialized to functions of the form f(x, y, z, *vars) -> v.
Extremely in the weeds: if you know what libfive's "feature"-flavored evaluator is, Fidget doesn't have it.
a_e_k
Neat! I remember contributing the expression parser code for the Knoll et. al 2009 work that you cited in your SIGGRAPH paper. That just rewrote a single user-friendly expression into nested function calls to our IA library in GLSL, without any sort of optimization.
You've clearly taken things waaay farther. Nicely done.
jacobparker
Coincidentally I was just reading this other wonderful post from the author https://www.mattkeeter.com/projects/constraints/
mkeeter
Hah, I actually wrote a similar constrain solver that uses Fidget's evaluation + differentiation! This blog post was getting too long, so I'm going to write it up separately, but in the meantime:
demo: https://mattkeeter.com/projects/fidget/constraints
source: https://github.com/mkeeter/fidget/blob/main/demos/constraint...
docs on the solver: https://docs.rs/fidget/latest/fidget/solver/
jy14898
You might be interested in http://omrelli.ug/g9/gallery/ too
miniBill
Oh wow. This would have been incredibly useful to have found when I was writing my own implicit-surface drawer. My approach is similar in some ways (interval arithmetic), and different in others (not as optimized, I directly produce GLSL for a fragment shader).
Honestly I'm tempted to just toss everything away and replace it with (a reimplementation of) this. Dunno if I should be happy or sad about that.
dleink
Happy! You work in a field where you can both make your own tools and use tools others have created. Maybe you can steal some of his ideas and use them, or use his stuff and contribute to the project. either way, rad.
retzkek
Years ago in college I did a bit of work on a nuclear physics simulator (think: reactor modeling) that based its geometrical model on implicit surfaces, specifically R-functions (of which min(x,y) is an example), which have some neat properties such as being differentiable everywhere. This is a good introduction (and probably the only one in English): https://ecommons.cornell.edu/items/35ae0f68-1af5-4f28-8b8b-7...
I've been away from the nuclear field for a while, but I imagine it's still using a lot of legacy Fortran codes to do modeling. Fidget has some interesting possibilities as a kernel for a new simulation package.
i_am_a_squirrel
A bit of a tangent, but I've been shopping around for the best code based CAD software. I gave cad query a shot and had a few issues. Any recommendations? My use case is 3D printing.
bschwindHN
I gave a talk on code-based CAD and covered quite a few options:
https://youtu.be/0wn7vUmWQgg?si=9Rc1tvbiQgQDgQzd&t=2766
I'm also developing one in Rust but I wouldn't say it's ready yet.
zokier
There is build123d too
fallat
replicad
marcosscriven
This is fascinating. I've seen papers and demos on such implicit surfaces before (quite possibly yours), and while it's impressive what models one can build up with some imagination, I'd love to see something more than toy examples.
Would it be possible, for instance, to do the things possible in b-rep kernels like extruding a surface, or importing an SVG/typeface and creating a solid out of it?
I'd really love to see a fast, open source, kernel that can support such things and also parallelise well.
emmelaich
Reminds me a lot of Ian Henry's https://bauble.studio/
matthewfcarlson
I've been meaning to do something like this (work on an abstract tree for surface generation) but using SDFs. The idea being that you have a target mesh/point cloud and then use hill climbing/annealing to reach a good tree that fits the desired shape.
mkeeter
You would probably find "A Unified Differentiable Boolean Operator with Fuzzy Logic" interesting!
https://arxiv.org/abs/2407.10954
They build up CSG trees with differentiable leafs (quadrics) combined with differentiable boolean-ish operations, so you can hill-climb over the entire shape.
rtpg
> libfive is 40K lines of mostly C++, and is extremely challenging to hack on, even as the original author. It's also frustrating to touch: if it's been a few months since I last compiled it, it's inevitable that the build will have broken, and I'll have to mess with CMake for 10 minutes to unbreak it.
I'm a bit shocked at this. Is build breakage that much of an issue? Is this "we are merging in patches and then fixing them up later"? Why would something not being touched break?
mkeeter
This wouldn't be an issue if I locked my computer in a safe, but the rest of the system is changing underneath me: I may have a new laptop, a new CMake version, a new Qt install location, etc. Having everything managed through Cargo does a great job of isolating me from those kind of changes.
mehackernewsacc
Just in case you are unaware, these build issues are entirely solvable by defining a Nix flake for your project, resulting in a repeatable, reproducible build every time:
peppertree
Here is a thought experiment. What if 3D printers support implicit representation natively. Resin printers are basically physical marching cube machines. FSM would need an algorithm for following contours but should be doable.
daeken
I kinda tried doing this with a custom FDM slicer for SDFs a long while back. I hit some roadblocks, but the concept was pretty simple: slicers by definition need to know what exists in a 2d slice of a 3d object. So why not render an SDF directly as slices and then act on that? You're basically then just trying to turn a raster into a vector (a toolpath).
The code is simple and hacky as hell -- very much an experiment -- but I still think that it is a plausible route forward. https://github.com/daeken/AjaPrint
Jarmsy
You might be interested in this recent work in the 3mf format
https://cdfam.com/3mf-consortium-volumetric-and-implicit-ext...
UniverseHacker
Ultimately you'll still need to further process it into a set of physical step by step instructions for the instrument. I'd still rather have the slicer be separate software step so you can tweak the physical properties of the process -wall thickness, infill, temperature and speed, etc. But yeah, it should be possible to input an implicit representation into a slicer.
syedrezaali
Matt is a constant source of inspiration. Congrats on the new project Matt!
mkeeter
Thanks Reza!
lilyball
Speaking as someone who's never done any sort of graphics work, this is really cool! I wish there were more demos though. The web editor has a single program, the repo itself only appears to have one Rhai program too (the one used for the web editor) so I can't just copy from that. It would be great if the web editor had a dropdown of programs to try, such as the one I see in the first image of the post.
Hi, this is my project :)
I particularly love this corner of CS because there's something for everyone – data structures and algorithms, low-level performance work, compilers, rendering / computer graphics, UI/UX for design tools, GPGPU programming, and more!
I'll be answering questions in the threads as I see them, but feel free to connect on social media (https://mattkeeter.com/links/) or follow my blog's RSS feed for further updates (https://mattkeeter.com/atom.xml)