opencascade-rs

opencascade-rs copied to clipboard

I'm finding some strangeness with my first solid definition and I'm not sure where the problem is :sweat_smile: @bschwind here's the snippet:

fn gizmo() -> Shape {
    let arrow_length = 10.0;
    let cone_height = 2.0;

    let arrow = |workplane: Workplane| {
        let arrow_vec = workplane.normal() * arrow_length;
        let shaft_vec = workplane.normal() * (arrow_length - cone_height);
        let shaft = workplane.circle(0.0, 0.0, 0.1).to_face().extrude(shaft_vec);
        let cone_base = workplane.translated(shaft_vec).circle(0.0, 0.0, 1.0);
        let cone_top = workplane.translated(arrow_vec).circle(0.0, 0.0, 0.05);
        let cone = Solid::loft([&cone_base, &cone_top].into_iter());
        shaft.union(&cone)
    };
    // arrow(Workplane::yz()).union_shape(&arrow(Workplane::xz())).union_shape(&arrow(Workplane::xy()))
    arrow(Workplane::xy())
}

I commented out the last line to create a single arrow instead. This works fine:

However, if I use a different workplane (arrow(Workplane::yz) for example) I get garbage:

Am I doing anything silly here? I think everything I'm doing is relative to the workplane (sure, the circle methods take x and y but these are plane-local and the math checks out on paper). I'm looking at all the functions I'm calling and I'm struggling to find where the asymmetry is coming from.

Jul 12 '23 10:07 PabloMansanet

Ah, the issue is a bit tricky and maybe touches on something we should figure out for this library.

The translated() call on the workplane treats the offset argument passed to it in terms of its own coordinate system. So if you're working in the YZ plane and pass it the vec (8, 0, 0), the workplane's new global location will be (0, 8, 0).

We can probably at least at documentation or naming to make this more obvious, but maybe this is an opportunity where we can get the type system involved so it's harder to make this mistake.

The differences between global and local coordinate systems can be confusing.

Jul 12 '23 11:07 bschwind

Ohhh I see. I'd be partial to hard-limit this with separate coordinate types, yes. Taking GlobalCoords or LocalCoords would have made this a bit clearer probably :)

Jul 12 '23 11:07 PabloMansanet

I also left a nice little landmine of not defining all the affine transforms for the various planes (you'll see TODOs in the code).

For people coming from CadQuery, these would be the expected coordinate systems:

https://cadquery.readthedocs.io/en/latest/classreference.html?highlight=named#cadquery.Plane.named

Jul 12 '23 12:07 bschwind

Ohhh I see. I'd be partial to hard-limit this with separate coordinate types, yes. Taking GlobalCoords or LocalCoords would have made this a bit clearer probably :)

Agreed, something like that would be nice, and quite similar to the Angle stuff I suggested in @tuna-f1sh 's PR.

Jul 12 '23 12:07 bschwind

Success!

Thanks for the pointers :). I'll make an intermediate PR with the missing affine transforms for the planes, and the geometry for the gizmo (though it can't yet do gizmo things like be on a corner and have colors).

Jul 12 '23 12:07 PabloMansanet