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)

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

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

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.

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.

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.

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

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.

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

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

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.

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

The picture looks like the union of two cylinders?

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.