Fidget
mattkeeter.com

・

544 points

・

todsacerdoti

・

3 days ago

53 comments

mkeeter ・ 3 days ago

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)

  • jcgrillo ・ 2 days ago

    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 ・ 2 days ago

    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 ・ 2 days ago

    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 ・ 2 days ago

      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 ・ 2 days ago

    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 ・ 3 days ago

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

miniBill ・ 3 days ago

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 ・ 3 days ago

    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.

ssfrr ・ a day ago

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

turnsout ・ 3 days ago

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.

  • mkeeter ・ 3 days ago

    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/

    • actionfromafar ・ 3 days ago

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

      • bhaney ・ 3 days ago
        ・ 5 more

        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.

retzkek ・ 3 days ago

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 ・ 2 days ago

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.

marcosscriven ・ 2 days ago

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.

matthewfcarlson ・ 2 days ago

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 ・ 2 days ago

    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.

peppertree ・ 3 days ago

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 ・ 3 days ago

    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

  • UniverseHacker ・ 2 days ago

    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.

  • pidge ・ a day ago

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

    • Wulfsta ・ a day ago

      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! :)

rtpg ・ 2 days ago

> 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 ・ 2 days ago

    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.

syedrezaali ・ 3 days ago

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

  • mkeeter ・ 3 days ago

    Thanks Reza!

lilyball ・ 2 days ago

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.

agentultra ・ 3 days ago

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

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

sans_souse ・ 2 days ago

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

red_trumpet ・ 3 days ago

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

The picture looks like the union of two cylinders?

  • mkeeter ・ 3 days ago

    You're correct, fixed!

wmacaluso ・ 2 days ago

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

dleink ・ 3 days ago

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

rendaw ・ 3 days ago

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.

  • bhaney ・ 3 days ago

    > is that rust in the web editor?

    From the post:

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

    https://rhai.rs/

    • rendaw ・ 2 days ago

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