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)
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.
Cheers
How does Fidget differ from libfive and Ao, functionality wise?
Thanks in advance.
"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.
You've clearly taken things waaay farther. Nicely done.
> Note that the speedup is less dramatic with smarter algorithms; brute force doesn't take advantage of interval arithmetic or tape simplification! The optimized rendering implementation in Fidget draws this image in 6 ms using the bytecode interpreter, or 4.6 ms using the JIT backend, so the improvement is only about 25%.
I love how this is focused on how the JIT backend is less important with the algorithmic optimizations, and not on how the algorithmic optimizations give a 1000x improvement with bytecode and 40x with JIT.
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/
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.
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.
For people who don't like opening videos:
* OpenSCAD
* DSLCAD
* CadQuery
* Build123d
* Cascade Studio
* Declaracad
* Replicad
https://youtu.be/0wn7vUmWQgg?si=9Rc1tvbiQgQDgQzd&t=2766
I'm also developing one in Rust but I wouldn't say it's ready yet.
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.
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.
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?
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
https://cdfam.com/3mf-consortium-volumetric-and-implicit-ext...
Optimizing for enjoyment/time and writing from scratch are useful exercises!
let x = x * scale; let y = y * scale; let z = z * scale;
let sphere = sin(x)cos(y) + sin(y)cos(z) + sin(z)cos(x); let fill = abs(sphere) - 0.2; let gradient = sin(sphere)cos(y) + cos(z)*sqrt(sphere);
let sphere = sqrt(square(x) + square(y) + square(z)) - 23.77; max(sphere, gradient)
No idea what I'm doing but it's fun
Most STEP files represent shapes as a set of surfaces (e.g. trimmed NURBS). These surfaces have to form a watertight manifold, which can be treated as a solid volume.
To make this actually work, you need a kernel for boundary representations (b-reps), rather than Fidget's functional representations (f-reps). Writing such a kernel is a much harder problem – as one example, the intersection of two NURBS surfaces doesn't always have a closed-form representation! In conversations with someone in the industry, they estimated it would take 6 engineers about a year to write a decent b-rep kernel, if they had done it before.
If you'd like to learn more, I've coincidentally also written a STEP file viewer, which includes a far-from-industrial-strength b-rep kernel: https://www.mattkeeter.com/projects/foxtrot/
I do wish Matt would cool it with his constant brilliant endeavors and go back and give Studio some love though. At this point I can't get it to build and can only launch an old version I compiled years ago that breaks if I'm not in some specific working directory in my Downloads folder.
The picture looks like the union of two cylinders?
I was looking for a live-coding editor (or live preview? hot reloading with visualizer?) for doing creative coding with something like Nannou and after a bunch of searching I came up dry.
