stuff and things

[zignig]

I am going to start a repo in...

https://github.com/zignig/cascade_rs_investigations

to make some stuff and things.

[bschwind]

Nice, let me know if you run into any issues!

[zignig]

Warning General Brain DUMP.

This is not criticism of your work (it's awesome); just what I see.

I have been building a gridfinity generator (mostly after the kids are asleep and the housework has been done). I'm liking the interface so far.

• Compile times are slow , however this gives me time to ponder whilst I wait (https://xkcd.com/303/).
• The binaries are massive (rwxr-xr-x 2 zignig zignig 296M Aug 3 21:38 gridfin) , don't know if this is just cxx rust artifact.

Rust types make building stuff quite intuitive because my editor (vscode) gives me hints on types and functions help. I find myself getting a little confused with Shape and Solid but that can be easily fixed.

• It would be nice if all the object types could be cloned as I find myself attempting to reuse geometry when I am building.
• shape and solid don't appear to have transform functions (translate , rotate , scale ) only the set_global_transforms. A consistent set of functions would be nice for all of them

Building is slow , I don't know if I am not holding it correctly, but building 5x5 gridfinity units can take up to 20ish seconds on an OK machine.

Would like

Some of these already have issues but this is what I would like for the kind of mechanical modelling I'm looking to do.

• pipes , plates and evolved shape
• splitting objects with infinite planes and getting both halves back.
• offset interface for wires , faces and surfaces
• thickness functions
• curves in 2 and 3 space
• gltf export
• resolution control on the stl export ( might make a PR as I have hacked some works into a local copy) , currently the STLs are big.

Complicated Questions.

Assemblies should be an integral part of the API (in the fullness of time) and the big question I see on this is use the OCCT interface for compound objects, ( makes export easier ) or do assemblies as rusty object and convert into the OCCT form.

I am a sucker for constraint base parametric constructs ( see my cqparts work ) and I think that this would be a good interface for packaging up hierarchical constructions that attempt to solve themselves in a declarative way.

I have been thinking about a a DSLcad(ish) interface where some input declaration (text , or API ) are compiled through opencascade-rs into usable engineering specs. The interface should be amenable to levels of abstraction upwards.

Other than that, cool project, I will keep noodling with it for now. If you have any comments or observations I am happy to answer.

I have lots of opinions ;P

[bschwind]

Hey @zignig , thanks so much for the thoughtful writeup!

Compile times are slow , however this gives me time to ponder whilst I wait

I agree, it's too slow to be generally usable. This has been improved since we extracted occt-sys to its own crate, but I don't imagine most people using this project in its current form, and it was also never the intention.

The binaries are massive

Hmm, I was expecting a few 10s of megabytes. The keycap example binary is 17M for me:

$ du -h target/release/examples/keycap 
 17M	target/release/examples/keycap

Are you compiling and running in release mode? (cargo run --release)

Rust types make building stuff quite intuitive because my editor (vscode) gives me hints on types and functions help. I find myself getting a little confused with Shape and Solid but that can be easily fixed.

That's great, and certainly one of the benefits I was hoping Rust would bring. Glad to hear it's actually working.
I'm also a bit confused by Shape and Solid and may just drop Solid in favor of shape. I'm not sure if working at the Solid level gives me any advantages, but I wanted to explicitly keep each opencascade type in for now in case there were important things I didn't know where I might want a Solid around instead of the more abstract Shape. If I don't see anything, I might just collapse the methods of Solid into Shape to simplify things.

It would be nice if all the object types could be cloned as I find myself attempting to reuse geometry when I am building.

I'll look into this. The underlying C++ binding library gives me unique pointers for things, which inhibits cloning, but maybe I should be using shared pointers instead. Needs more research.

shape and solid don't appear to have transform functions (translate , rotate , scale ) only the set_global_transforms. A consistent set of functions would be nice for all of them

Yep I've been putting this off a bit. There are different ways to transform things like Euler XYZ rotation, or quaternions for rotation, and I wanted to make sure I get the API right for this part so it's easy and produces expected results in as many cases as possible.

Building is slow , I don't know if I am not holding it correctly

Again I would check you're invoking cargo with the --release flag, otherwise things will move quite slow. If it's still slow in release mode, then we likely have a more fundamental problem we need to fix.

splitting objects with infinite planes and getting both halves back.

I want this too! I also recently saw a video on shadow lines and have wanted to build that into this library since then :)

resolution control on the stl export ( might make a PR as I have hacked some works into a local copy)

Yep this is needed, there's just a default value in there for now. Feel free to submit a PR and I'd be happy to review it.

the big question I see on this is use the OCCT interface for compound objects, ( makes export easier ) or do assemblies as rusty object and convert into the OCCT form.

I'm leaning towards doing this in Rust and converting to OCCT form later, should give me better control and be easier to iterate on the implementation. I haven't really sat down and thought hard about this yet though, so I can't comment much more on that. Rest assured I consider it a crucial feature though!

I am a sucker for constraint base parametric constructs ( see my cqparts work ) and I think that this would be a good interface for packaging up hierarchical constructions that attempt to solve themselves in a declarative way.

I think constraint-based approaches are nice too, and I always enjoy SolveSpace when I use it. Their solver is open source, so there's an opportunity to integrate parts of that into this project.

I have been thinking about a a DSLcad(ish) interface where some input declaration (text , or API ) are compiled through opencascade-rs into usable engineering specs. The interface should be amenable to levels of abstraction upwards.

Could you expand on this a bit more? I'm not quite sure what this would look like in practice.

Cheers!