I've been tapering off maintenance since 2016 or so, but it has a more actively-maintained fork over at https://github.com/nsfm/stibium (albeit with heavy LLM assistance, because it's 2026!)
YMMV – I haven't used it or closely inspected the changes, but have corresponded with the author, who seems genuinely dedicated in the success of the project.
libfive [1] was the follow-up kernel, written in C++, with a big emphasis on fast evaluation and robust meshing. It's also in maintenance mode, but was shipped in a handful of commercial CAD tools.
In 2020, I wrote a SIGGRAPH paper [2] about doing implicit surface rendering on the GPU. This was a fun and exciting experience! This used libfive for the frontend, then did all of the compute-heavy rendering work on the GPU.
I then got tired of dealing with C++ and rewrote everything in Rust, which is what I've been using ever since: Fidget [3] is the new kernel and Halfspace [4] is the new IDE. This is what I'm actively working on – the Halfspace blog post just went up a few weeks ago, and I've been implementing / improving a GPU rendering backend in Fidget (with a backlog of several more blog posts).
In between, I nerd-sniped a bunch of people into writing their own f-rep evaluation engines [5] and gave a talk about the whole "independent research" thing [6].
[2] https://www.mattkeeter.com/projects/siggraph/
[3] https://www.mattkeeter.com/projects/fidget/
[4] https://www.mattkeeter.com/projects/halfspace/
The Rust code is being used by a few people other than me, but is not especially stable – one of the goals is to find the "right APIs", so I'm not shy about breaking things as I find better abstractions. Meshing is also not quite as polished as libfive, because I haven't yet found an algorithm that meets all my requirements, and have spent less time papering over issues in the chosen algorithm (manifold dual contouring).
I'm certainly not an expert in these fields, but what's your angle on techniques like raymarching?
Raymarching is great, and I love the work being done by the demoscene / Inigo Quilez / etc! I don't talk about it as much because my libraries usually have slightly different goals.
Most common raymarching strategies put limitations on your function, e.g. you need Lipschitz continuity to guarantee that you don't hit the model when doing ray steps. This property are pretty easy to break by accident (e.g. just scaling the model requires a correction factor), so you have to be careful with how you bend and twist the underlying math expression. If you're doing a single demo (or have a known library of good shapes), you can get away with it, but there's less flexibility.
The goal of my infrastructure is to support basically any math expression, no matter how poorly-behaved (although I really would appreciate C0 continuity), so I like the guarantees [1] of interval arithmetic.
That being said, the boundary is fuzzy. On one side, you can do raytracing with interval math [2], instead of point samples. From the other side, my more recent GPU rendering uses Z-sorting of spatial regions, so still using 3D intervals but walking them from the camera backwards (no blog post yet, sorry).
[1] Fidget doesn't actually change FPU rounding modes, so it's not absolutely guaranteed, but ehhhhhhh