Implicit Surface Rendering for CAD

ibobev1 pts0 comments

Implicit Surface rendering for CAD

farfa.dev

| Implicit Surface rendering for CAD

created_at<br>2026-05-07

updated_at<br>2026-05-28

reading_time<br>33 minutes

lang<br>en

tags

rust

dev

CAD

implicit surface

wgpu

computer graphics

Preamble

At the end of the spring of 2025, I started using some CAD software, preferably FOSS, because I wanted to design some furniture for myself.

I didn’t find anything that really clicked for me at the time.

While wondering if I could make my own (as one does, you know), I made some intriguing discoveries1 2.

From this initial frustration and piqued curiosity, emerged a drive to write a simple CAD software:<br>fsolid.

It’s merely a prototype at this point, it never was simple, and served more as a learning experience than a CAD software.

Screenshot of fsolid (v0.6.0).

This was my first real experience with CAD, both as a user and as a developer.

I wouldn’t consider myself a domain expert just yet; take what I wrote in this article with a grain of salt.

This blog entry is about the tribulations of a feverish desire to render arbitrary implicit surfaces on screen at interactive speed<br>in the context of a mechanical CAD software.

It’s meant as a showcase of this part of my project, documenting why I made certain decisions, and maybe sprouting new ideas in someone else’s mind.

Introduction

Before starting our descent into this rabbit-hole, one should empower oneself with the basic understanding of what<br>an I mplicit S urface (IS) is and (S igned) D istance F ields (SDF).

Great explanations exist elsewhere1 2 3; it is encouraged that the uninitiated reader consult them before<br>diving any further.

In the CAD software I’ve used, that had graphical interfaces, features are added or modified by the user and the viewport reflects those changes.

In some instances, the viewport allows the user to directly drag or sculpt features using a pointing device.

Screenshot of FreeCAD (v1.1.0), with a list of features on the left.

After the modification has been made, the resulting 3D object can be rendered and the user can move the camera around in the scene.<br>This includes panning, rotating, zooming, or a combination of those.

Most CAD software use E xplicit S urfaces (ES) (e.g., NURBS, Mesh, etc…).

Most processes downstream of authoring (e.g., visualization, CAM, FEM, etc…) require some form of ES.

Rendering is usually done by converting the ES to a triangle mesh, as GPUs are very much optimized for this.

On the other hand, IS describes a volume , discretizing the isosurface is expensive.

While algorithms exists to convert IS to a triangle mesh4 5, they can be slow, produce very large meshes, miss thin features, and may require a complete recomputation on partial changes.

They are necessary to export to a triangle mesh for some downstream usage, but other strategies may be used for visualization6.

Distortion sphere using a sphere-tracing shader (fsolid (commit 96ad96646e)).

For this project, I wanted to try and make an IS visualization that would scale with shape complexity, screen resolution and which would happen in two phases:

A loading phase, happening on the CPU, then a rendering phase, which would happen on the GPU.

The priority is smooth movement over up-to-date rendering.<br>This means that while an IS is still loading, a previous version may be shown on screen.

Optionally, I wanted that the rendering be some kind of anytime algorithm.

Loading of an IS using various degrees of precision, behaving like a Montecarlo process

The technique described today will focus on a two-phase rendering: discretizing and tracing .

It discretizes the IS in a data structure which will be traceable by the GPU.

This project uses fidget, an excellent closed-form IS library.

The rendering is done via wgpu and bevy.

Sampling the void

Bounding volume

An IS only describes a volume.

We don’t yet know where that volume is in space.<br>For that, we’ll use a bounding volume,<br>an A xis-A ligned B ounding B ox (AABB).

The AABB does multiple things for us.

It limits the space we need to consider.

It gives us a simple and efficient way to do ray-slab intersection test, which will come in handy.

It will allows for fast z-ordering of non-overlapping regions.

AABB can be computed from common IS7 and boolean operations can combine multiple AABB into the resulting<br>IS’s AABB.

For unbounded IS, one should be able to provide an AABB to limit the IS to a certain domain.

Using and representing voxels

The IS’s AABB is rectangular cuboid. We can trivially divide it into a subset of cubic voxel.

Because the isosurface is just a small portion of the AABB’s space, we’ll use a data structure which encodes sparse data efficiently:<br>a variant of S parse V oxel O ctree (SVO).

This variant is a sparse voxel tree, which is sometimes named contree.

Each level of the contree divides its space by 4 on each axis, dividing its space into 64 voxels.

Cubic space divided in cubic voxels ().<br>Loading a contree

The...

rendering aabb software space implicit using

Related Articles