mkeeter/fidget

blazing fast implicit surface evaluation

Rust

494

1,355 commits

updated Sep 12, 2026

See the code

README

Fidget

» Crate » Docs » CI » MPL-2.0

Project writeup | Demo

Fidget is experimental infrastructure for complex closed-form implicit surfaces.

screenshot of web editor

The library contains a variety of data structures and algorithms, e.g.

  • Manipulation and deduplication of math expressions
  • Conversion from graphs into straight-line code ("tapes") for evaluation
  • Tape simplification, based on interval evaluation results
  • A very fast JIT compiler, with hand-written aarch64 and x86_64 routines for
    • Point-wise evaluation (f32)
    • Interval evaluation ([lower, upper])
    • SIMD evaluation (f32 x 4 on ARM, f32 x 8 on x86)
    • Gradient evaluation (partial derivatives with respect to x, y, and z)
  • Bitmap rendering of implicit surfaces in 2D (with a variety of rendering modes) and 3D (producing heightmaps and normals)
  • Meshing (using our own implementation of the Manifold Dual Contouring algorithm)
  • A canonical bytecode format for tapes, for use in other interpreters

If this all sounds oddly familiar, it's because you've read Massively Parallel Rendering of Complex Closed-Form Implicit Surfaces. Fidget includes all of the building blocks from that paper, but with an emphasis on (native) evaluation on the CPU, rather than (interpreted) evaluation on the GPU.

The library has extensive documentation, including a high-level overview of the APIs in the crate-level docs; this is a great place to get started!

At the moment, it has strong Lego-kit-without-a-manual energy: there are lots of functions that are individually documented, but putting them together into something useful is left as an exercise to the reader. There may also be some missing pieces, and the API seams may not be in the right places; if you're doing serious work with the library, expect to fork it and make local modifications.

Issues and PRs are welcome, although I'm unlikely to merge anything which adds substantial maintenance burden. This is a personal-scale experimental project, so adjust your expectations accordingly.

Crate organization and versioning

The Fidget project is broken into separate crates for improved modularity and compile times. Everything is re-exported by the fidget root crate, so you shouldn't need to think about it. The version of the root crate is the maximum version of any child crate; they're not necessarily bumped in lockstep, only when things change.

Demos

The demos folder contains several demo tools and applications built using the Fidget crate, ranging from CLI to GUI to web app.

Projects using Fidget

Support matrix

At the moment, Fidget supports a limited number of platforms:

PlatformJIT supportCISupport
aarch64-apple-darwinYes✅ Tested⭐️ Tier 0
x86_64-unknown-linux-gnuYes✅ Tested🥇 Tier 1
x86_64-pc-windows-msvcYes✅ Tested🥈 Tier 2
aarch64-unknown-linux-gnuYes⚠️ Checked🥇 Tier 1
aarch64-pc-windows-msvcYes⚠️ Checked🥉 Tier 3
wasm32-unknown-unknownNo⚠️ Checked🥇 Tier 1

Explanation of keys

CIDescription
✅ Testedcargo test is run for the given target
⚠️ Checkedcargo check is run for the given target
TierDescription
⭐️ Tier 0A maintainer uses this platform as their daily driver
🥇 Tier 1A maintainer has access to this platform
🥈 Tier 2A maintainer does not have access to this platform, but it is tested in CI
🥉 Tier 3A maintainer does not have access to this platform, and it is not tested in CI

Support tiers represent whether maintainers will be able to help with platform-specific bugs; for example, if you discover an aarch64-pc-windows-msvc-specific issue, expect to do most of the heavy lifting yourself.

CPU requirements

aarch64 platforms require NEON instructions and x86_64 platforms require AVX2 and BMI2 support; all of these extensions are nearly a decade old and should be widespread.

Disabling the jit feature allows for cross-platform rendering, using an interpreter rather than JIT compilation. This is mandatory for the wasm32-unknown-unknown target, which cannot generate "native" code.

Similar projects

Fidget overlaps with various projects in the implicit modeling space:

*written by the same author

(the MPR paper also cites many references to related academic work)

Compared to these projects, Fidget is unique in having a native JIT and using that JIT while performing tape simplification. Situating it among projects by the same author – which all use roughly the same rendering strategies – it looks something like this:

CPUGPU
Interpreterlibfive, FidgetMPR
JITFidget(please give me APIs to do this)

Fidget's native JIT makes it blazing fast. For example, here are rough benchmarks rasterizing this model across three different implementations:

SizelibfiveMPRFidget (VM)Fidget (JIT)
1024³66.8 ms22.6 ms61.7 ms23.6 ms
1536³127 ms39.3 ms112 ms45.4 ms
2048³211 ms60.6 ms184 ms77.4 ms

libfive and Fidget are running on an M1 Max CPU; MPR is running on a GTX 1080 Ti GPU. We see that Fidget's interpreter is slightly better than libfive, and Fidget's JIT is nearly competitive with the GPU-based MPR.

Fidget is missing a bunch of features that are found in more mature projects. For example, it only includes a debug GUI, and its meshing is much less battle-tested than libfive.

LLM usage and contributions

I don't use LLMs to write non-trivial code (or documentation) in Fidget or Halfspace. In particular, I eschew agentic systems like Claude Code. One goal of these projects is to find the "right" APIs and software architecture for working with implicit surfaces, and I have to be using the APIs myself to discover rough edges and seams. Agentic loops are incredibly good at bandaging over paper cuts, which would defeat the purpose.

However, I do use LLMs for code review (typically using GitHub Copilot) and brainstorming (occasional chats with frontier models). Along with correct API design, an overarching goal of the project is to be as good as possible on various axes: correctness, performance, usability, documentation, etc. Since I'm the sole author, adding an additional layer of review helps me deliver better software.

User contributions are expected to abide by the same policy. Small contributions are typically welcome; if you are considering a large change, please open an issue or discussion first.

If you would like to avoid all possible LLM taint, I recommend pinning (or forking) Fidget 0.4.1.

License

© 2022-2026 Matthew Keeter
Released under the Mozilla Public License 2.0

computer-graphics
frep
implicit-surfaces
jit
rendering

Contributors

mkeeter

1,324 commits

waywardmonkeys

22 commits

alexneufeld

2 commits

virtualritz

2 commits

mkeeter/fidget

blazing fast implicit surface evaluation

Rust

494

1,355 commits

updated Sep 12, 2026

See the code

README

Fidget

» Crate » Docs » CI » MPL-2.0

Project writeup | Demo

Fidget is experimental infrastructure for complex closed-form implicit surfaces.

screenshot of web editor

The library contains a variety of data structures and algorithms, e.g.

  • Manipulation and deduplication of math expressions
  • Conversion from graphs into straight-line code ("tapes") for evaluation
  • Tape simplification, based on interval evaluation results
  • A very fast JIT compiler, with hand-written aarch64 and x86_64 routines for
    • Point-wise evaluation (f32)
    • Interval evaluation ([lower, upper])
    • SIMD evaluation (f32 x 4 on ARM, f32 x 8 on x86)
    • Gradient evaluation (partial derivatives with respect to x, y, and z)
  • Bitmap rendering of implicit surfaces in 2D (with a variety of rendering modes) and 3D (producing heightmaps and normals)
  • Meshing (using our own implementation of the Manifold Dual Contouring algorithm)
  • A canonical bytecode format for tapes, for use in other interpreters

If this all sounds oddly familiar, it's because you've read Massively Parallel Rendering of Complex Closed-Form Implicit Surfaces. Fidget includes all of the building blocks from that paper, but with an emphasis on (native) evaluation on the CPU, rather than (interpreted) evaluation on the GPU.

The library has extensive documentation, including a high-level overview of the APIs in the crate-level docs; this is a great place to get started!

At the moment, it has strong Lego-kit-without-a-manual energy: there are lots of functions that are individually documented, but putting them together into something useful is left as an exercise to the reader. There may also be some missing pieces, and the API seams may not be in the right places; if you're doing serious work with the library, expect to fork it and make local modifications.

Issues and PRs are welcome, although I'm unlikely to merge anything which adds substantial maintenance burden. This is a personal-scale experimental project, so adjust your expectations accordingly.

Crate organization and versioning

The Fidget project is broken into separate crates for improved modularity and compile times. Everything is re-exported by the fidget root crate, so you shouldn't need to think about it. The version of the root crate is the maximum version of any child crate; they're not necessarily bumped in lockstep, only when things change.

Demos

The demos folder contains several demo tools and applications built using the Fidget crate, ranging from CLI to GUI to web app.

Projects using Fidget

Support matrix

At the moment, Fidget supports a limited number of platforms:

PlatformJIT supportCISupport
aarch64-apple-darwinYes✅ Tested⭐️ Tier 0
x86_64-unknown-linux-gnuYes✅ Tested🥇 Tier 1
x86_64-pc-windows-msvcYes✅ Tested🥈 Tier 2
aarch64-unknown-linux-gnuYes⚠️ Checked🥇 Tier 1
aarch64-pc-windows-msvcYes⚠️ Checked🥉 Tier 3
wasm32-unknown-unknownNo⚠️ Checked🥇 Tier 1

Explanation of keys

CIDescription
✅ Testedcargo test is run for the given target
⚠️ Checkedcargo check is run for the given target
TierDescription
⭐️ Tier 0A maintainer uses this platform as their daily driver
🥇 Tier 1A maintainer has access to this platform
🥈 Tier 2A maintainer does not have access to this platform, but it is tested in CI
🥉 Tier 3A maintainer does not have access to this platform, and it is not tested in CI

Support tiers represent whether maintainers will be able to help with platform-specific bugs; for example, if you discover an aarch64-pc-windows-msvc-specific issue, expect to do most of the heavy lifting yourself.

CPU requirements

aarch64 platforms require NEON instructions and x86_64 platforms require AVX2 and BMI2 support; all of these extensions are nearly a decade old and should be widespread.

Disabling the jit feature allows for cross-platform rendering, using an interpreter rather than JIT compilation. This is mandatory for the wasm32-unknown-unknown target, which cannot generate "native" code.

Similar projects

Fidget overlaps with various projects in the implicit modeling space:

*written by the same author

(the MPR paper also cites many references to related academic work)

Compared to these projects, Fidget is unique in having a native JIT and using that JIT while performing tape simplification. Situating it among projects by the same author – which all use roughly the same rendering strategies – it looks something like this:

CPUGPU
Interpreterlibfive, FidgetMPR
JITFidget(please give me APIs to do this)

Fidget's native JIT makes it blazing fast. For example, here are rough benchmarks rasterizing this model across three different implementations:

SizelibfiveMPRFidget (VM)Fidget (JIT)
1024³66.8 ms22.6 ms61.7 ms23.6 ms
1536³127 ms39.3 ms112 ms45.4 ms
2048³211 ms60.6 ms184 ms77.4 ms

libfive and Fidget are running on an M1 Max CPU; MPR is running on a GTX 1080 Ti GPU. We see that Fidget's interpreter is slightly better than libfive, and Fidget's JIT is nearly competitive with the GPU-based MPR.

Fidget is missing a bunch of features that are found in more mature projects. For example, it only includes a debug GUI, and its meshing is much less battle-tested than libfive.

LLM usage and contributions

I don't use LLMs to write non-trivial code (or documentation) in Fidget or Halfspace. In particular, I eschew agentic systems like Claude Code. One goal of these projects is to find the "right" APIs and software architecture for working with implicit surfaces, and I have to be using the APIs myself to discover rough edges and seams. Agentic loops are incredibly good at bandaging over paper cuts, which would defeat the purpose.

However, I do use LLMs for code review (typically using GitHub Copilot) and brainstorming (occasional chats with frontier models). Along with correct API design, an overarching goal of the project is to be as good as possible on various axes: correctness, performance, usability, documentation, etc. Since I'm the sole author, adding an additional layer of review helps me deliver better software.

User contributions are expected to abide by the same policy. Small contributions are typically welcome; if you are considering a large change, please open an issue or discussion first.

If you would like to avoid all possible LLM taint, I recommend pinning (or forking) Fidget 0.4.1.

License

© 2022-2026 Matthew Keeter
Released under the Mozilla Public License 2.0

computer-graphics
frep
implicit-surfaces
jit
rendering

Contributors

mkeeter

1,324 commits

waywardmonkeys

22 commits

alexneufeld

2 commits

virtualritz

2 commits

Languages

Rust

93.7%

WGSL

6.1%