easyw-fc wrote:but atm I cannot test what I would like to create...
I would need to have an App::Part container to contains other objects or even other App::Part containers...
This would be useful to be used in an assembly structure ...
Part-o-magic supports creating nested Parts, or nested Modules, or even Parts within Modules. If it's not working for you, please explain in detail what you do.
easyw-fc wrote:1) make a compound of the App::Part structure
I thought Draft Clone would do that, but it doesn't. That might be a very simple fix to master FreeCAD.
easyw-fc wrote:2) make a union of the App::Part structure
Same as with clone + Part Fuse.
easyw-fc wrote:3) make a simple copy of the App:Part structure (similar to Mux in assembly2)
I don't quite understand... Sounds like an easy deal, please explain in detail.
DeepSOIC wrote:Part-o-magic supports creating nested Parts, or nested Modules, or even Parts within Modules. If it's not working for you, please explain in detail what you do.
Hi, when using PoM I can only create nested Parts, but without the option to have more of one Part at the same level... may be I'm not using PoM in the right way...
I attach the desired and of the PoM tree I get
compare-trees.jpg (37.31 KiB) Viewed 2167 times
DeepSOIC wrote:
easyw-fc wrote:1) make a compound of the App::Part structure
I thought Draft Clone would do that, but it doesn't. That might be a very simple fix to master FreeCAD.
easyw-fc wrote:2) make a union of the App::Part structure
Same as with clone + Part Fuse.
Great! Looking forward for it
DeepSOIC wrote:
easyw-fc wrote:3) make a simple copy of the App:Part structure (similar to Mux in assembly2)
I don't quite understand... Sounds like an easy deal, please explain in detail.
If you use assembly2 to build up a model with parts, then you can create a Mux of your assembled parts...
The Mux is similar to a fusion and a single copy of the objects and it is a really nice option to have a single object of your assembled part without any boolean operation
easyw-fc wrote:Hi, when using PoM I can only create nested Parts, but without the option to have more of one Part at the same level... may be I'm not using PoM in the right way...I attach the desired and of the PoM tree I get
PoM always adds whatever is created to active container. Including new Parts. That is, to have "Part002" to "Part", activate "Part" before creating "Part002" by double-clicking it in tree (you can also get there using Leave, Enter buttons of PoM workbench, which I highly recommend adding to a global toolbar, as they are quite versatile).
To add another Part to the root of document, deactivate whatever is active (either by double-clicking it in tree, or pressing Leave button until it becomes grey)
DeepSOIC wrote:
To add another Part to the root of document, deactivate whatever is active (either by double-clicking it in tree, or pressing Leave button until it becomes grey)
works like a charm! thx
Should I add a FR for the following behavior?
1) make a compound of the App::Part structure
2) make a union of the App::Part structure
3) make a simple copy of the App:Part structure as in Part WB
4) ability to select an App::Part root node and export the assembled/children components as STEP
easyw-fc wrote:Should I add a FR for the following behavior?
1) make a compound of the App::Part structure
2) make a union of the App::Part structure
3) make a simple copy of the App:Part structure as in Part WB
4) ability to select an App::Part root node and export the assembled/children components as STEP
1) yes, but to FreeCAD tracker, as it's rather trivial to extend a Clone to do that.
2) i'll think about it. If 1 is fulfilled, achieving 2 is trivial. But I had an idea of making a variant of Module that will expose a fusion or a compound of its content. It's easy, I'm just not sure if it's useful.
3) definitely
4) I'm afraid I won't be able to do it
DeepSOIC wrote:
2) i'll think about it. If 1 is fulfilled, achieving 2 is trivial. But I had an idea of making a variant of Module that will expose a fusion or a compound of its content. It's easy, I'm just not sure if it's useful.
it will align the App::Part behavior to what is for Compounds
DeepSOIC wrote:
4) I'm afraid I won't be able to do it
May be I was not clear... I'm not asking to save STEP hierarchy as in App:Part (that probably will be take on charge by the work of @vejmarie that is improving STEP inter-operability)
I would like to have the option to select a root note of a Part and export the objects as actually it can be done selecting a compound root node...
for example if I have a compound of a Cube and a Sphere, selecting the compound I will export the Cube and the Sphere as placed in the compound...
I added a few notes to the tracker ticket. For discussion also here:
1. An App::Part container is a universal object which can hold any kind of DocumentObject like meshs or Paths or even pictures. I can't work with Part tools (Booleans, Compound etc.) which work with Part::Features only and hence result in a undefined behavior. The App::Part object should not work with those tools. Current behavior is correct.
2. To point 3: make a simple copy. I agree that the simple copy tool should handle App::Part objects, but this must involve creating a simple copy of all child DocumentObjects, as a DocumentObject is allowed to be only in a single local coordinate system (GeoFeatureGrouip, Which App::Part is).
Note that the story is completely different for Part-o-Magic containers that are a Part::Feature in itself.
ickby wrote:
1. An App::Part container is a universal object which can hold any kind of DocumentObject like meshs or Paths or even pictures. I can't work with Part tools (Booleans, Compound etc.) which work with Part::Features only and hence result in a undefined behavior. The App::Part object should not work with those tools. Current behavior is correct.
it would be possible to allow Boolean ops only if App::Part is containing Part::Features only?
so is App::Part container good for assembly objects?
If the container cannot work with boolean do you still consider this useful for STEP integration?
ickby wrote:Note that the story is completely different for Part-o-Magic containers that are a Part::Feature in itself.
it would be possible to allow Boolean ops only if App::Part is containing Part::Features only?
IMHO a bad idea. Tools don't know anything of local coordinate systems and that shoud stay so.
so is App::Part container good for assembly objects?
Yes, IMHO there is absolutely no reason why you need Booleans of Parts for Assemblies. All you want to do is to place your objects and groups of them, and App::Part is perfect for that.
If the container cannot work with boolean do you still consider this useful for STEP integration?
Same argument, to my knowledge step assembly structures do not need any booleans between local coordinate systems.