[adamchalmers]

Assembly block MVP needs 3 things:

• Moving bodies into the assembly
• Creating mate connectors
• Applying constraints to mate connectors

One nice-to-have that I've called out in a TODO:

• Translate/rotate calls where the engine persists its solutions into the KCL AST, ensuring warm solves.
• I don't know how the engine would send this back to KCL -- presumably a translate + rotate for each body in solved system, but what coordinate system would it be in? Scene global, or relative to something? Currently KCL translate has two coordinate frames available, the global scene, and the body's sketch's local system.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
⚠️ Please upload report for BASE (main@e2b7401). Learn more about missing BASE report.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1362   +/-   ##
=======================================
  Coverage        ?   36.15%           
=======================================
  Files           ?       32           
  Lines           ?     1737           
  Branches        ?        0           
=======================================
  Hits            ?      628           
  Misses          ?     1109           
  Partials        ?        0           

Flag	Coverage Δ
unittests	36.15% <ø> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[adamchalmers]

We could add options here to reorient the mate frame, e.g. translating it, rotating it, flipping the major/minor axes. WDYT David?

[davreev]

Yep, that sounds good.

[davreev]

Yep, that sounds good.

[davreev]

I think we'll need to revise the constraint catalogue if we're using mate-based constraints. Concentric, for example, sounds like it'd be ~equivalent to a cylindrical joint (i.e. two bodies share a common axis that they're free to move along/rotate around). Here's the joint catalogue I have on the solver side so far (comments are common alternative names):

struct Joint
{
    enum struct Type : u8
    {
        Undefined = 0,
        Spherical, // Ball
        Distance,
        Revolute, // Hinge
        Cylindrical,
        Weld, // Fixed, Fastened
        Prismatic, // Slider
        Universal, // Hooke
        Planar,
        PointOnPlane,
        _Count,
    };

    // ...
};

This mostly overlaps with the OnShape catalogue with the exception of their Tangent mate which doesn't make use of mate connectors. Would suggest we ignore that one for now though as it'd involve solving the general contact problem between a pair of solids which is a ways off on the geometry kernel side.

[adamchalmers]

Great, I don't think we have plans for tangent constraints yet, so that's OK. What's the difference between a joint and an assembly-level constraint on two frames? Is "joint" defined as "a constraining relationship between mate frames", like "these two mate frames have a distance of 5m" or "these two mate frames have a cylindrical joint"

[davreev]

Yep that's right, "joint" is just the library-internal name given to constraints that act between a pair of bodies. They'll likely have a 1:1 reln with what we're calling "mates" at the API/engine level so we can treat them as synonymous here. I'll try to stick to "mate" when discussing unless there's a meaningful difference.

[davreev]

presumably a translate + rotate for each body in solved system, but what coordinate system would it be in?

Yep, was thinking the same. Still mulling this over a bit but seems to make sense for each assembly to have its own transform, defining a local space in which the solve happens. In this case, it'd be the transform of each child in the local space of its parent assembly that gets sent back to KCL.

The key benefit here is that it'd let us use nested assemblies to break large problems down into smaller ones that can be solved concurrently e.g. solving for transforms of parent assembly A can be done independently of solving for transforms of child assemblies B and C. This separation relies on expressing the transforms of each child in the space of its parent. What I'm still unsure about though is whether this transform hierarchy is something we want to persist or if it makes more sense as a transient thing that's constructed before the solve and then torn down/flattened out afterwards. Might be good to get @benjamaan476's thoughts on this as he's more familiar with how transform hierarchies currently work in engine.

[davreev]

Looks good on the whole. I'm still a little hazy on how transform hierarchies will shake out on the engine side but no harm getting this in place now (assuming it's not set in stone).