Hi all, Many thanks for the years of wonderful use of OpenSCAD. I've been working on the csgrs CAD kernel in Rust, which is now built around a novel infinite precision partially symbolic numeric type. I've recently accepted maintainership of SynapsCAD, an OpenSCAD compatible Rust app with optional AI integration: https://github.com/timschmidt/synaps-cad You can try a web build of it here: https://timschmidt.github.io/synaps-cad/ All the math in this version of SynapsCAD is evaluated using https://github.com/timschmidt/hyperreal at infinite precision. That means you should be able to spin things around 10 billion times and have them land in exactly the same spot, use arbitrarily large numbers out to millions of digits (tested in our regression tests), or extremely tiny numbers for nanomanufacturing. This didn't require changing the OpenSCAD language in any way, I just replaced the scalar underneath it. Of course, output is still triangulated / segmented. As author / maintainer of the full stack under SynapsCAD, it's possible for me to push some changes through the whole stack that wouldn't be easy otherwise. One of csgrs's dependencies: https://github.com/timschmidt/hypercurve supports native exact lines, arcs, conics, cubic and quadratic beziers, b-splines, and NURBs in 2D. It would be nice to find ways to extend the language to support some of these things in ways which can be standardized and supported by multiple implementations. I've been thinking a lot about BOSL2 and NopSCADlib in this regard - all the extensions they provide for the language. Certainly much of what BOSL2 does can be supported at a lower level in the CAD kernel directly, to speed it up, without presenting a materially different API at OpenSCAD's level. I guess I just wanted to open up the conversation and see what others thought. What ideas y'all might have along these lines. with great appreciation, --tim

H Timi, I tried the following on your web version (to test the angle misalign, that I mentioned earlier) module view_rocket() { difference(){     color("silver") cylinder(h = 40, r = 8);     color("red")         rotate([0,0.0001,0])             cylinder(h = 40, r=8);     } } changed $view to "rocket" got this error ⚠: ⚠️ Compilation warnings: • Geometry failed: exact Difference failed: hypermesh boolean operation failed: could not certify scalar sign; finite output retry failed: hypermesh boolean operation failed: input mesh 1 has 8 boundary edges Please report issues with the code that caused them. Best wishes, Ray ps this 'test' script OK in openscad On 22/07/2026 18:52, Tim Schmidt via Discuss wrote: > Hi all, > > Many thanks for the years of wonderful use of OpenSCAD. I've been > working on the csgrs CAD kernel in Rust, which is now built around a > novel infinite precision partially symbolic numeric type. I've > recently accepted maintainership of SynapsCAD, an OpenSCAD compatible > Rust app with optional AI integration: > https://github.com/timschmidt/synaps-cad > > You can try a web build of it here: https://timschmidt.github.io/synaps-cad/ > > All the math in this version of SynapsCAD is evaluated using > https://github.com/timschmidt/hyperreal at infinite precision. That > means you should be able to spin things around 10 billion times and > have them land in exactly the same spot, use arbitrarily large numbers > out to millions of digits (tested in our regression tests), or > extremely tiny numbers for nanomanufacturing. This didn't require > changing the OpenSCAD language in any way, I just replaced the scalar > underneath it. Of course, output is still triangulated / segmented. > > As author / maintainer of the full stack under SynapsCAD, it's > possible for me to push some changes through the whole stack that > wouldn't be easy otherwise. > > One of csgrs's dependencies: https://github.com/timschmidt/hypercurve > supports native exact lines, arcs, conics, cubic and quadratic > beziers, b-splines, and NURBs in 2D. It would be nice to find ways to > extend the language to support some of these things in ways which can > be standardized and supported by multiple implementations. > > I've been thinking a lot about BOSL2 and NopSCADlib in this regard - > all the extensions they provide for the language. Certainly much of > what BOSL2 does can be supported at a lower level in the CAD kernel > directly, to speed it up, without presenting a materially different > API at OpenSCAD's level. > > I guess I just wanted to open up the conversation and see what others > thought. What ideas y'all might have along these lines. > > with great appreciation, > --tim > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org