Project goals

[winksaville]

Your README is quite detailed about what the crate does, but what are medium and long term goals for the project?

[timschmidt]

Awesome suggestion, thanks for starting off discussion.

This is what I wrote in the readme: "This library aims to integrate cleanly with the Dimforge ecosystem (e.g., nalgebra, Parry, and Rapier), leverage earclip and cavalier_contours for robust mesh and line processing, be reasonably performant on a wide variety of targets, and provide an extensible, type-safe API"

It's helpful to look at the pages for each of the Dimforge libraries:
https://docs.rs/nalgebra/latest/nalgebra/
https://docs.rs/parry3d/latest/parry3d/
https://docs.rs/rapier3d/latest/rapier3d/
https://docs.rs/salva3d/latest/salva3d/

There are a lot of useful looking functions in there, and for 2D as well, which I'd like to make easily accessible against the CSG and Polygon types.

Other items on my mind in no particular order:

• I've started porting https://github.com/nophead/NopSCADlib and https://github.com/BelfrySCAD/BOSL2 functions into https://github.com/timschmidt/partsrs and csgrs directly. Mostly more convenience functions and a small part library.
• I'm prototyping a toolpather for additive and subtractive manufacturing built around csgrs here: https://github.com/timschmidt/ironpath
• There's been some activity in the Bevy discord around csgrs, which I'd love to support with a bare bones Bevy example.
• I've been toying around with renderers toward a lightweight GUI for previewing designs
• Extending the GUI with https://github.com/trevyn/egui_node_graph2 - there's a nice example in the egui_node_graph2 repo.
• WASM builds
• Joints between CSGs using rapier
• further integration of arcs of constant radius (circle segments) and cavalier contours into toolpathing operations
• no-std
• integration with non-linear solver for constraint solving / sketches
• more complete documentation with individual renders, perhaps prototyped with the new GUI

I'd like to keep the API and the function implementations within the library as readable as possible, especially in the single-threaded case, for clarity of the algorithms. I'm open to your ideas, patches, bugs, anything! What would you like to see in csgrs' future?

[winksaville]

I'm a retired programmer and I'm not a expert in CAD in anyway shape or form. But I do have expertise in programming and I've played around with cadquery, https://github.com/CadQuery/cadquery, and I like the concept, but do not happen to like Python. So my question about "goals" is somewhat higher level than what you've provided, as I'm unfamiliar with Dimforge, earclip and cavalier_contours.

So how would you compare CadQuery and csgrs?

[timschmidt]

CadQuery has more moving parts than csgrs at the moment. Open CASCADE is in C++, and implements support for NURBS, splines, STEP i/o, and part of CadQuery is Python, with it's runtime and libraries and whatnot. CadQuery has to call out from Python to Open CASCADE, when you build geometry with csgrs, the CAD kernel is csgrs, and the CAD functions just become part of your code and work wherever Rust does. No problems with embedded or web, just works. < 500kb with all the features on.

csgrs, at it's core, only understands lines in simple polygons. No curves. Though several functions accept or return curves which get interpolated or recovered from interpolated lines respectively. csgrs is capable of static modeling like CadQuery or OpenSCAD, but it's also fast and low-latency enough to perform CSG in real time in a video game or simulation. It's optionally multi-threaded, and most transformations are SIMD accelerated thanks to the Dimforge libraries. The CAD Kernel and the Physics Engine have been built using the same data types such that using them together is seamless.

I'm curious to see how close in quality to the machine output of systems which support curves that I can get by recovering curves from the polygons just prior to common toolpathing operations like offsetting.

I don't know if this will make sense to you or not, but I've been thinking of csgrs as sort of the SQLite of CAD libraries. Proving you can do a lot with a little.