Introduction
Halfspace is an experimental IDE for solid modeling alongside extend fields.
(The demo is finest informed on a computer; mobile Safari has several WebGPU issues, and pan / tilt / zoom interactions are not yet designed for multitouch)
Halfspace is a showcase app for the Fidget kernel, which is used for rasterization and meshing. Within the GUI, images are rasterized in real(ish)-time; models can be exported as either images or triangle meshes:
Since it's 2026, let me note at the outset that this is not vibe-coded. I've been operating on it since April 2025 and am penning the code using my individual brain, for various reasons (and Fidget dates rear to 2022).
Now, the remainder of this writeup assumes some cognition of implied surfaces; please see many previous writeups for details for more background info (or fair keep reading, you'll be fine).
Why?
I've spent a bunch of period penning implied kernels, slightly small period writing GUIs on those kernels, and equal small period really modeling alongside those tools.
In practice, I don't really need to do much firm modeling in my regular life, so most of the material that I create is a demo or an example of how to use a particular kernel.
Still, I've noticed a particular strain whenever operating alongside implied surfaces. Working alongside low-level implied surfaces is a bit akin penning assembly: it's low-level, powerful, and annoying. If all you're stated is x, y, z variables – and it's your duty to merge them into all the shapes of your dreams – that can be a achy experience.
When faced alongside the ache of penning assembly, most group build abstractions on top of it: high-level languages and libraries that compile downward to a low-level representation. The equal current is a norm archive of shapes and transformations: sphere, box, translate, scale, etc.
There's additionally a small average method to the ache of assembly: making assembly itself small achy to write.
My favorite project alongside those lines is Kartik Agaram's Mu, which wraps emulation, tracing, and time-travel debugging about a subset of x86 assembly language.
Halfspace takes the two paths. It includes a (small but growing) norm library, but additionally makes it uncomplicated to build up models incrementally: a complex example can be divided into smaller pieces, which can be parameterized and visualized individually.
Given that justification, let's unpack the clarification a bit farther.
Solid modeling
First off, "solid modeling" method that we're focusing on objects alongside a definitive inner and outside; you have to be capable to choice any item in area and say whether it's inner or exterior the model.
This seems obvious, but there's plentifulness of modeling that doesn't attention concerning that property: drag up any video equivalent example viewer and you'll see plentifulness of infinitely-thin textured walls, built from a single fan of triangles. Since my backdrop is in CAD/CAM software (with an accent on 3D printing), I desire models that can be physically realized.
There are a bunch of ways to do firm modeling. In most CAD software, a boundary-representation geometry kernel is liable for stitching a bunch of idiosyncratic surfaces together into a solid body. This is a tremendously difficult issue – for example, the intersection of two NURBS surfaces may not have a closed-form solution!
Dating rear to my Master's thesis, I've been operating on geometry kernels based on implied surfaces. These have the advantage that they can conceivably be written and completely understood by a sole individual or small team, so they're a good fit for personal-scale fabrication software.
This continues in Halfspace: it's a GUI wrapped about the Fidget geometry kernel. Models can be designed using some combination of pre-defined primitives and hand-written scripts, and exported as either images or triangle meshes.
An IDE for extend fields
We could use the Fidget kernel purely at the constructive firm geometry (CSG) layer, construction shapes (spheres, cubes, cylinders, etc) and combining them with logical operations (union, intersection, difference). Halfspace alternatively make the decision to put the underlying extend sectors in the foreground.
Let me provision you an example of why this matters. Here are two extend fields for a sawtooth wave, which have the identical signs at all item in space, but different values:
In this visualization, the sign (which defines inside versus outside) is shown by color (blue versus orange), alongside the border of the form shown in white (corresponding to a value of 0). The site values are shown by the fainter lines, which are spaced at regular intervals (like a topographic map).
Despite having identical signs everywhere, the archetypal site is extremely poorly behaved. Look at the vertical border of the sawtooth: there's a passage from inside (blue) to exterior (orange) without a crossing through zero.
This is a C0 or "jump" discontinuity, and it's bad news! Fidget uses automatic differentiation to compute normals, so the normals throughout this border don't item in the accurate direction (compare the site lines between top and base images). In 3D, anywhere we use normals for shading, this produces incorrect shading in the cabin's shingles:
(If this looks familiar, it's since it's extracted from an before blog post)
Putting extend sectors front-and-center makes it uncomplicated to diagnose these benevolent of issues. In fact, it suggests a additional betterment on the sawtooth field: we can tweak the gradient so that it's 1 everywhere, alternatively of being bunched up on the diagonals. Here's a before / following comparison:
Having uniform gradients makes assorted algorithms better-behaved; Fidget doesn't require it for correctness, but it may (for example) enhance mesh quality.
Halfspace is experimental and cross-platform
Right now, it would be a very bold decision to use Halfspace in any load-bearing capacity. In the Fidget writeup, here's one of the project goals:
Finding the "right" APIs for implied kernels, alongside the possible of making substantial compatibility breaks
Halfspace is similar; it doesn't current APIs to end-users, but I'm flexing my software architecture skills by construction a significant cross-platform application, and I'm consenting to aggresively iterate and interrupt things as we go.
Speaking of cross-platform, I'm making my existence harder by targeting the two the web and native platforms. In the era of supply-chain attacks, being capable to portion a web nexus – alternatively of asking person to compile and run your code – is awesome for onboarding and informal usage.
To that end, I've been collecting the "Halfspace stack": a set of libraries and patterns which let me container a blended native + web use alongside a minimum of pain. Right now, current are the center pieces:
- Rust for the use (and all dependencies)
- egui for the GUI
- egui_dock for the core window-and-tab abstraction
- wgpu for the two rendering the UI and GPU compute (!)
- Rhai for scripting
- Rayon and wasm-bindgen-rayon, used for two purposes:
- Speeding up parallel algorithms by distributing activity complete many workers; this is a "typical" use of the library
- A thread pond for short-lived backdrop tasks; this is a additional unusual usage, but we can't spawn threads on the web.
- ...and a lengthy rear of another libraries and shenanigans
- web-time for cross-platform time support
- A homebrew employee pool for off-thread (async) GPU rendering
This all deserves a dedicated writeup, and I have complaints concerning all single layer of the stack, but overall, it's amazing that everything Just Works™.
Driving Fidget improvements
Another goal of Halfspace is to run improvements in the Fidget kernel, by using it in a non-trivial application.
The biggest triumph on this forefront has been ongoing activity on fidget-wgpu. This was motivated by achievement on the web: the native build was pleasantly fast, but doing rasterization on the CPU was awfully dilatory ("non-interactive speeds") when running through a tier of WebAssembly.
After a lot of activity on the Fidget side, the two rasterization and post-processing (e.g. shading) can be run purely on the GPU, without any roundtrips to the CPU.
This was the two a achievement and architectural win:
- We now have native rendering speed on the two native and web targets
- Rendering logic is no longer dispersed between Fidget (on the CPU) and Halfspace (with a mix of CPU and GPU code):
- Fidget implements the canonical rendering logic
- Halfspace has lean shaders which diagram an RGBA texture
(The 2D rendering pipeline is additionally now completely GPU-accelerated, although it has slightly fancier shaders in Halfspace, for reasons)
Wrapping up
Halfspace is a item that exists!
You should try it out, and should likely not use it for crucial applications! If you encounter problems, delight document an matter or open a conversation on Github.
Like most of my work, I scheme to keep operating on it until I have run out of things to study from the project. Also akin most of my work, it's open-source under the MPLv2 license.
