Open bernhard-42 opened 3 years ago
+1 for a PR on this
@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
@jmwright fyi, it is now available on Binder (still as MAssembly
of course) as beta3
@bernhard-42 Great, thanks!
Let me wrap my head around it. I'd prefer to merge it after 2.1 is released.
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 ...
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.
Fair enough. Let's go your way.
@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.
Thanks, looks nice @bernhard-42 ! What about #534, do you intend to work on it?
Absolutely, and that's why it is not published to pypi.
I have added all the feedback we've discussed in https://github.com/CadQuery/cadquery/pull/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 ...
Thanks for all your work on this @bernhard-42
@adam-urbanczyk @jmwright We discussed the topic of nested assemblies in https://github.com/CadQuery/cadquery/issues/522 and I think since you started to merge https://github.com/CadQuery/cadquery/pull/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 https://github.com/CadQuery/cadquery/issues/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:
For better visibility I have spread the objects:
Given these mates, one can now assemble the door like one would do it in reality:
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
andassemble
are the core methods used in the example above. Of course, one could combinemate
andassemble
so thatassemble
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 assemblyNote:
_origin_mate
plus_relocate
andrelocate
are only needed to shift the objects in space to allow the hierarchical threejs system to rotate/translate appropriately.