On 7/24/26 10:12 AM, Tim Schmidt via Discuss wrote: > A gap that is irrelevant in a meter-scale printed bracket might be the > feature of interest in a microfluidic part, PCB, or metrology > workflow. There is no universal epsilon that captures all of those > intents. I've actually encountered this problem with > https://github.com/atomCAD/atomCAD If you consider `1` to be somewhere within 3-to-6-orders-of-magnitude smaller than your largest dimension, then universal epsilon is fine. That was my point in "single model of the solar system and measuring subatomic particle differences". Microfluidics can use `1` to be nanometers instead of millimeters. > That does not mean the end user should be asked to decide every > ambiguous weld. The application should choose an appropriate policy > for its domain. OpenSCAD can have sensible print-oriented defaults. A > PCB DRC tool, a BREP importer, and a machine controller may make > different choices. > > The proof-versus-policy distinction matters because it lets those > systems share one kernel without pretending that one tolerance policy > is a law of geometry. > > Ultimately OpenSCAD is a triangulated mesh approximating CSG. > > That is its current output representation, but it does not require > every internal representation to be triangulated from the beginning. The maintainers wish to avoid any insufficiently-positive change which change existing meshes, for example by making `sphere` something far more sphere-like (see recent discussions). So I will argue that it does, in fact, require that it work essentially how it does right now; that the tessellations as they happen are in fact required. > Keeping curves and analytic surfaces native until the final finite handoff can: > > ... > and allow tessellation to be chosen for the actual display or > machine resolution. Okay, now I see what you're getting at. Problem I'm working on with $fe <https://github.com/openscad/openscad/issues/4246>, but it's inherently limited by the semantics of OpenSCAD: $fe=0.01; scale([2.0,2.0,2.0]) shape(1); shape(2); Even working properly, shape(1) will have twice the error of $fe. You're saying to preserve the original shape and apply the meshing precision at the end. Ultimately I think you're recreating curv (or maybe building a better/faster/more flexible export for it?) or replicating what you can do by putting your CSG into FreeCAD and having it run the OpenCASCADE kernel on it. Or I'm wrong and you're writing novel backend for OpenSCAD users to choose! Cory

Cory, Yes, that is pretty much it. A model-relative epsilon can be a perfectly reasonable policy for a single OpenSCAD job. My objection is only to making it the only semantic available, or pretending that it proves mathematical equality. I also agree that OpenSCAD's existing tessellation behavior is effectively part of its compatibility contract. A new backend should not silently change everyone's meshes. It should be able to preserve the historical "tessellate first, then transform" behavior when compatibility matters. Your $fe example is exactly the distinction. If the original curve survives the scale operation, it can instead be tessellated afterward to 0.01 in final coordinates. Those are two different semantics, and both can be explicit. It would be nice to find ways to extend the language syntax which are backwards compatible yet offer these new features for modelers who want to use them. You are not wrong about the neighborhood. Curv and B-rep systems also preserve richer geometry until later. The difference is that csgrs is intended to be multi-representation: native curves, meshes, B-reps, SDFs, voxels, and conversions between them, all over the same exact-aware numeric and predicate stack. So "a novel backend for OpenSCAD users to choose" is probably the closest description. SynapsCAD and openscad-rs could preserve legacy OpenSCAD tessellation in compatibility mode, while also offering an opt-in native-curve backend where transforms and Booleans happen before final meshing. I do not expect OpenSCAD to redefine sphere underneath existing users. I do think the language can sensibly target more than one geometry backend. --tim

On Fri, Jul 24, 2026 at 12:58 PM Jordan Brown <openscad@jordan.maileater.net> wrote: > > On 7/24/2026 8:30 AM, Tim Schmidt wrote: > > Hypercurve is currently strictly two-dimensional. Spatial curves, > > trimmed surfaces, and three-dimensional curve/surface relationships > > belong in HyperBREP which is less than finished at the moment. > > OK, so headed in the right direction but for 3d modeling not there yet. > Thanks. Facts. And hypercuve isn't complete yet either. Lines and arcs are well supported, but it's still possible to back higher order curves into blocked predicate decisions in booleans. Working on it, and it's going well. Somewhat surprised at the performance achievable against competitive libraries. B-rep currently can lift curves from hypercurve, and has complete: - Retained vertex/edge/coedge/loop/face/shell topology. - Exact planar surfaces, validation, closure, bounds, area, volume, and query reports. - Line, rational Bézier, finite NURBS, pcurve, and planar-region support. - Planar face and prism construction, including holes. - Line/plane and plane/plane intersection evidence. Major deferred capabilities remain nonplanar surfaces, nonlinear curve/surface root isolation, curved trim reconstruction, BREP booleans and sewing, periodic NURBS, and STEP/IGES exchange. They're up after I'm satisfied with 2D curves, meshing, and the extrusions, lofts, revolves, sweeps, cuts, and projections between them, and the performance thereof. --tim