Fidget | Hacker News Reader

Fidget

mattkeeter.com

556 pointstodsacerdoti55 comments

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)

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.

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.

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.

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

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.

>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.

Im not sure about CLI tools but I'd say that most parametric design (ie fusion, solidworks) software have robust DFM features as it is. Many softwares have a timeline that represents a series of steps taken to create your intended part. In fusion you can set up your project for Milling, sheet metal, or 3d printing and modify the tool paths and bends in suite.

Not sure what software you are using but I would step away from CLI of free tools if you are serious about parametric modeling

I'm not complaining so much about the lack of features. What I don't like as a cad user is that the modeling interface is basically an evolution of the drafting table. I have to think like a draftsperson rather than simply describing how I'll make the part.

Coincidentally I was just reading this other wonderful post from the author https://www.mattkeeter.com/projects/constraints/

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/

You might be interested in http://omrelli.ug/g9/gallery/ too

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.

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.

Phenomenal to have a new open source CAD kernel out there! I couldn’t tell from the article if this supports export to common formats like STEP. But if so (or once that’s possible) it should be a great foundation for some of the open source CAD libraries out there.

It does not support STEP export, unfortunately, because STEP files use a completely different underlying representation.

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/

Could this or the other "Studio" be used to avoid using OpenSCAD when creating models for 3D printing?

I've been using Studio as my primary way of generating models for 3D printing for years now, no OpenSCAD involved. Write some scheme, get an STL.

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.

Thanks!

Does anyone know if Zoo/KittyCad uses the similar principles under the hood?

https://zoo.dev/geometry-engine

uses brep

Thanks

https://en.wikipedia.org/wiki/Boundary_representation

> Doing brute force evaluation on 1024² pixels, the bytecode interpreter takes 5.8 seconds, while the JIT backend takes 182 milliseconds – a 31× speedup!

> 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.

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.

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.

There is build123d too

https://github.com/gumyr/build123d

replicad

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.

From the other comment/video:

For people who don't like opening videos:

* OpenSCAD

* DSLCAD

* CadQuery

* Build123d

* Cascade Studio

* Declaracad

* Replicad

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.

Reminds me a lot of Ian Henry's https://bauble.studio/

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.

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.

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.

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

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.

You might be interested in this recent work in the 3mf format

https://cdfam.com/3mf-consortium-volumetric-and-implicit-ext...

Relatedly, here’s a slicer built around Fidget https://github.com/Wulfsta/WeekendSlicer/tree/main

Still very early work, mind you! This is mostly a proof of concept in its current state, but I will add more features if Fidget gets a 2D equivalent to Mesh, so I don’t have to worry about path extraction from meshes. Thanks for the mention! :)

Matt is a constant source of inspiration. Congrats on the new project Matt!

Thanks Reza!

> 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?

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.

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:

https://nixos.org/ https://wiki.nixos.org/wiki/Flakes

> build issues are entirely solvable

Until they're not, at which point if you're not a nix+flake wizard you're completely at sea :)

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.

Oh neat. I’ve been meaning to explore SDF/implicit surfaces.

Optimizing for enjoyment/time and writing from scratch are useful exercises!

Related: Fornjot - b-rep CAD kernel in Rust https://github.com/hannobraun/fornjot

let scale = 27.9;

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

> Here's the intersection of two exactly-coincident cylinders

The picture looks like the union of two cylinders?

You're correct, fixed!

i've always wondered about closed form brep approaches, and i'm glad to see that someone much smarter than I has made it their passion and made it a reality

I've been yearning for updated winamp/eggdrop style music visualizations... this is very far outside my domain knowledge but feels like it could be used somehow..

Sorry, tangential but is that rust in the web editor? Do you have a wasm compiler or something? It seems super fast!

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.

> is that rust in the web editor?

From the post:

> Fidget includes bindings for Rhai, an embedded scripting language for Rust

https://rhai.rs/

Ah, since it said it was a library I thought the bindings were something extra. That makes sense though.

Reply on news.ycombinator.com