Halfspace: A Browser IDE for Signed Distance Field Modeling

Signed distance fields (SDFs) are a compact way to describe solid geometry: for any point in space, an SDF returns the distance to the nearest surface, with the sign telling you whether that point is inside or outside the model. They are elegant on paper, but historically awkward to work with in practice, because a raw SDF program is essentially assembly for geometry. Halfspace, an experimental browser IDE from Matt Keeter, is an attempt to make that low-level representation pleasant to write, visualize, and debug.

Halfspace is a GUI wrapped around the Fidget geometry kernel. Fidget handles rasterization and meshing; Halfspace provides the editing environment, the standard library of shapes and transforms, and the export pipeline. Models can be exported as images or as triangle meshes.

The project is explicitly experimental. Keeter notes that it would be a bold decision to use Halfspace in any load-bearing capacity, and that he is willing to aggressively iterate and break things. It is open source under the MPLv2 license, and it is not vibe-coded: work began in April 2025, with Fidget dating back to 2022.

A conventional constructive solid geometry (CSG) layer lets you build spheres, cubes, and cylinders and combine them with union, intersection, and difference. Halfspace instead exposes the underlying distance fields directly. That choice is not cosmetic.

Consider two distance fields for a sawtooth wave that have identical signs everywhere but different values. In one of them, the vertical edge transitions from inside to outside without crossing through zero. That is a C0 discontinuity, and it is a problem: Fidget uses automatic differentiation to compute normals, so normals across that boundary do not point in the correct direction. In 3D, where normals drive shading, this produces visibly incorrect shading on surfaces such as cabin shingles.

Putting distance fields in the foreground makes these issues diagnosable. It also suggests a refinement: tweaking the gradient so that it is 1 everywhere rather than bunched up on the diagonals. Fidget does not require uniform gradients for correctness, but they may improve mesh quality.

Halfspace targets both the web and native platforms. The web target matters for onboarding: sharing a link is easier than asking someone to compile and run code, which is especially relevant in an era of supply-chain attacks.

The stack Keeter describes includes:

• Rust for the application and all dependencies
• Manual use of wasm-bindgen and related tooling for the web build
• egui for the GUI, with egui_dock for window-and-tab abstraction
• wgpu for both UI rendering and GPU compute
• Rhai for scripting
• Rayon and wasm-bindgen-rayon for parallelism and for a thread pool used for short-lived background tasks
• web-time for cross-platform time support
• A homebrew worker pool for off-thread, async GPU rendering

Keeter notes that this deserves a dedicated writeup and that he has complaints about every layer, but that it is remarkable that it all works together.

The most consequential architectural shift came from performance on the web. The native build was fast, but CPU rasterization through WebAssembly was non-interactive. The response was ongoing work on fidget-wgpu, which moved both rasterization and post-processing such as shading onto the GPU, eliminating roundtrips to the CPU.

This was both a performance and an architectural win. Rendering now runs at native speed on both native and web targets. Rendering logic is no longer split between Fidget on the CPU and Halfspace on a mix of CPU and GPU code. Fidget implements the canonical rendering logic, and Halfspace has thin shaders that draw an RGBA texture. The 2D rendering pipeline is also fully GPU-accelerated, though it uses slightly fancier shaders in Halfspace.

The Halfspace architecture is a useful case study because it shows where the interesting boundaries are in an interactive geometry tool.

First, the kernel is the product. Halfspace exists partly to drive improvements in Fidget by using it in a non-trivial application. The fidget-wgpu work is the clearest example: a real application surfaced a real performance problem, and the fix landed in the kernel rather than as a workaround in the GUI.

Second, the CPU/GPU split is a design decision, not an implementation detail. Moving rasterization and shading to the GPU did not just make things faster; it clarified ownership. Once Fidget owns the canonical rendering logic, Halfspace can stay thin.

Third, cross-platform support has a cost that is paid in architecture. Targeting both web and native means dealing with WebAssembly, thread pools that cannot spawn threads on the web, and a long tail of compatibility shims. The payoff is distribution: a link is a lower-friction onboarding path than a build step.

Fourth, exposing the low-level representation is a deliberate tradeoff. A CSG-only interface would be friendlier, but it would hide the discontinuities and gradient problems that matter for downstream algorithms. Halfspace takes both paths: it includes a small but growing standard library, and it makes it easy to build models incrementally, splitting complex models into smaller pieces that can be parameterized and visualized individually.

If you are building an interactive geometry tool, Halfspace suggests a few patterns worth considering:

• Keep the kernel authoritative. Put canonical rendering logic in the kernel and let the application layer stay thin.
• Treat the GPU boundary as an architectural boundary. Moving work to the GPU can simplify ownership as much as it improves speed.
• Expose the representation when it aids debugging. Distance fields are harder to read than CSG, but they make failure modes visible.
• Expect cross-platform to shape the stack. WebAssembly, threading, and time handling all impose constraints that leak into design.

Halfspace is available as a demo, though the demo is best experienced on a computer; mobile Safari has some WebGPU issues, and pan, tilt, and zoom interactions are not yet designed for multitouch. Problems can be filed as issues or discussions on GitHub.