Manual assembly system enhancement

[bernhard-42]

@adam-urbanczyk @jmwright
We discussed the topic of nested assemblies in #522 and I think since you started to merge #538 this will be part of the next release.

I thought it might be easier no to open a new issue to discuss the manual assemblies I introduced in #522

I took your door tutorial (added "door" as the name to the top level hierarchy to not have to deal with uuids) and used my manual approach to assemble it:

from collections import OrderedDict as odict

# add mates to the ends of the vslots
for v in ["bottom", "left", "top", "right"]:
    door.mate(f"door/{v}@faces@>Z", name=f"{v}_0", transforms=odict(rx=180))
    door.mate(f"door/{v}@faces@<Z", name=f"{v}_1", transforms=odict(rx=180))

# add mates to the connectors
for c in ["con_tl", "con_tr", "con_br", "con_bl"]:
    door.mate(f"door/{c}?X", name=f"{c}_0", transforms=odict(rz=90))
    door.mate(f"door/{c}?Z", name=f"{c}_1") 

# add mates to bottom vslot and panel
door.mate("door/panel@faces@<Z", name="panel_0", transforms=odict(rx=180, rz=90))
door.mate("door/bottom@faces@>X[-4]", name="panel_1")

# add mates to handle and one hole
door.mate("door/handle?mate1", name="handle_0")
door.mate("door/panel?hole1", name="handle_1", transforms=odict(rz=-90))

For better visibility I have spread the objects:

Given these mates, one can now assemble the door like one would do it in reality:

door.assemble("bottom_0", "con_bl_0")    # add bottom vslot to bottom-left connector
door.assemble("con_br_1", "bottom_1")    # add bottom-right connector to bottom vslot
door.assemble("left_1",   "con_bl_1")    # add left vslot to bottom-left connector
door.assemble("right_0",  "con_br_0")    # add right vslot to bottom-right connector
door.assemble("panel_0",  "panel_1")     # add panel
door.assemble("con_tl_0", "left_0")      # add top-left connector to left vslot
door.assemble("con_tr_1", "right_1")     # add top-right connector to right vslot
door.assemble("top_1",    "con_tl_1")    # add top vslot to top-left connector
door.assemble("handle_0", "handle_1")    # add handle

By the way, since I don't want to use Threejs animation system, there is no need to relocate the objects.

Full code can be found here

Would you be interested in a pull request? It would be the file mate.py and the methods

• mate
• _relocate
• relocate
• assemble

from massembly.py plus two properties: mates and _origin_mate

The methods mate and assemble are the core methods used in the example above. Of course, one could combine mate and assemble so that assemble gets both mate definitions, however, for me it has proven helpful to split these steps to visually analyse the mates (location and orientation) before doing the final assembly

Note: _origin_mate plus _relocate and relocate are only needed to shift the objects in space to allow the hierarchical threejs system to rotate/translate appropriately.

[jmwright]

+1 for a PR on this

[bernhard-42]

@jmwright Happy to create a PR.
@adam-urbanczyk Should I wait until assembly-hierarchy is merged to master or should I create a PR against assembly-hierarchy

[bernhard-42]

@jmwright fyi, it is now available on Binder (still as MAssembly of course) as beta3

[jmwright]

@bernhard-42 Great, thanks!

[adam-urbanczyk]

Let me wrap my head around it. I'd prefer to merge it after 2.1 is released.

[bernhard-42]

From my perspective it would be great to already have it in 2.1:
I wanted to release my 2.0 after your 2.1 as the stable jupyter-cadquery release for the latest OCP based CadQuery. Since a lot of work went into the manual assembly approach and many examples exist for it in my code, I obviously want to make it part of my release.
If the manual assembly is not in cadquery, I need to consider either to keep the MAssembly subclass (and all will change again if mate/assemble get merged some day) or monkey patch cadquery when importing jupyter-cadquery. Both ways are not optimal in my eyes.

Just my 2 cent given my priorities, but, of course, I also understand your thinking ...

[adam-urbanczyk]

This is coming really late and would delay 2.1. We can always make a 2.1.1 or even 2.2 specifically for this. Time-wise it won't make any difference.

[bernhard-42]

Fair enough. Let's go your way.

[bernhard-42]

@adam-urbanczyk @jmwright Just for information:
I've carved out MAssembly from Jupyter Cadquery and added a show_mates function for CQ-Editor, see https://github.com/bernhard-42/cadquery-massembly
All my examples from Jupyter Cadquery are ported to CQ-Editor and can be found in the example folder.

[adam-urbanczyk]

Thanks, looks nice @bernhard-42 ! What about #534, do you intend to work on it?

[bernhard-42]

Absolutely, and that's why it is not published to pypi.

I have added all the feedback we've discussed in #534 and came up with a solution for placing mates that avoids the pitfalls you've mentioned but is still meaningful for the user in my eyes.

I now wanted to give you a chance to look at the approach without digging through jupyter_cadquery stuff (that's why I ported my examples to CQ-Editor) .

Additionally I wanted to ensure that whatever I have built works in CQ-Editor and that the step I find important to debug an assembly, displaying the mates, also works there.

So, if you find it useful, I would be more than happy to contribute it to CadQuery. Just let me know what your preferred next steps would be ...

[jmwright]

Thanks for all your work on this @bernhard-42