[Kliment]

With two arbitrary faces on the same axis (say z), at locations z1 and z2 and the shape of each face being represented by the functions a(x,y) and b(x,y), you can get a loft SDF L(x,y,z) between a and b by the following math (this is not correct syntax for any tool I know but should make it clear what's happening):

if(z<z1) L=a(x,y)

elif(z>z2) L=b(x,y)

else L=((z-z1)/(z2-z1))*a(x,y)+((z2-z)/(z2-z1))*b(x,y)

For way way more info, you might like https://iquilezles.org/www/articles/distfunctions/distfuncti...

[dymk]

Thank you, however, this is but one kind of loft operations done that are common in CAD. Often you want to control the tangency between the connected profiles, or connect profiles that aren’t parallel, or use a center guiderail (arbitrary spline), or use multiple guiderails along specific vertexes on the profiles.

It’s these complex cases that I understand how to approach with a kernel based around face patches, less so how one could achieve it with an SDF

[Kliment]

None of those cases are complicated - your SDF can be defined piecewise so you can have as many control points as you want. There's no fundamental difference between SDF and brep in terms of expressiveness - just breps define undirected surfaces and SDFs define volumes. Whether your tool (based on whichever underlying geometry approach) allows you to do what you want to do with them is another story.

[dymk]

This mostly makes sense to me.

I've been looking at the CAD space for a while, and it seems like tools exist at either extreme of the spectrum from "Point, click, drag" UI and "only code to describe the model" UIs. Rhino might be the exception here, but it's very expensive, and doesn't have the parametric / history preserving properties I'm looking for.

I think both of these extremes have drawbacks, so I've been toying with hybrid solutions that involve both a code editor and a 3D interactive pane. The code is still the source of truth, but the system allows you to interactively draw sketches, apply constraints, select faces etc, and then convert your UI interactions back into their equivalent code.

I've been playing with different ways of representing the models (and how that would inform the "language" the model is described with, and the sorts of operations it would support), but that's a whole different problem that I don't want to get mired in, so I'm looking for the simplest thing that gets the job done.

SDFs are looking like a reasonable solution here, but it's hard to look away when OpenCascade is just sitting there...