Non-PartDesign Body container proposal

Here's the place for discussion related to coding in FreeCAD, C++ or Python. Design, interfaces and structures.
DeepSOIC
Posts: 5413
Joined: Fri Aug 29, 2014 12:45 am
Location: Saint-Petersburg, Russia

Non-PartDesign Body container proposal

Postby DeepSOIC » Mon May 23, 2016 12:06 pm

Hi!
When playing with my Part-o-magic experiment, I felt the power of all the body and part containers. And when I was making the rotor iron core, I had a strong need for doing a Part Common operation inside the body. Well, I worked around that, but that created a strong desire co create a body-like container for all kinds of OCC shape geometry.

The container is to:
* parent a set of shape features, and allow them to be moved all at once
* expose the final result as its Shape property, by copying the shape from Tip object
* provide two viewing modes: "Tip" and "Through". Tip mode shows only the final result (Tip shape). "Through" mode shows the objects that belong to the body, and is activated when editing the body (by making it active).

Compared to PartDesign body, the general-purpose body:
* doesn't care of the type of objects added to it. Can take any Part::Feature-derived objects, as well as any other kinds of objects hat may be handy in making the result
* doesn't do any fusing sequence management. Fusing, cutting, compounding is to be done manually.
* can expose any kind of shape as the final result - not limited to a single solid. An example of a result: arrangement of circular faces.
* has no "BaseFeature" (doesn't make sense in non-PartDesign workflow, IMO)

Inheritance plan:
GeneralPurposeBody: inherits BodyBase. Lives in Part module.
PartDesign Body: inherits BodyBase. Lives in PartDesign module.
BodyBase: implements most of the functionality of GeneralPurposeBody, as it is a subset of functionality of PartDesign Body. GeneralPurposeBody is almost a trivial subclass, as for now.

Tip management and automatic object addition: I delegate this to Part-o-magic as for now. But eventually I hope some alternative semi-automated mechanism will be created for that, as it is needed for Part containers, PartDesign Body containers, and this container, and basically for any other kind of container.
ickby
Posts: 2767
Joined: Wed Oct 05, 2011 7:36 am

Re: Non-PartDesign Body container proposal

Postby ickby » Mon May 23, 2016 12:23 pm

I can follow the idea behind the view modes, but for what would you need the tip in normal part operations? With this you can expose the shape of a single Document object only, hence you would need to combine everything that should be in the result anyway with a fusion or compound. This than results in the fact that you always have a single child in your container which automaticall is the tip. Or multiple childs which can only be some kind of construction geometry. There seems to be not much additional benefit. Could you give a example? Tha twould make it easier to grasp th usefullness.
DeepSOIC
Posts: 5413
Joined: Fri Aug 29, 2014 12:45 am
Location: Saint-Petersburg, Russia

Re: Non-PartDesign Body container proposal

Postby DeepSOIC » Mon May 23, 2016 12:26 pm

Name selection.
Since the GeneralPurposeBody can result in a shape that is not a solid, the name "Body" doesn't really fit. So I tried inventing a new name for it. So far, I have considered:

module
model
element
component
piece
brick
block
shape
tracktor
complex
masterpiece :mrgreen:
bone
fruit

The ones I lean to are: module, model, component, complex
DeepSOIC
Posts: 5413
Joined: Fri Aug 29, 2014 12:45 am
Location: Saint-Petersburg, Russia

Re: Non-PartDesign Body container proposal

Postby DeepSOIC » Mon May 23, 2016 12:33 pm

ickby wrote:Could you give a example? Tha twould make it easier to grasp th usefullness.
I have already given it. I'll elaborate.

I am making the model of my motor.
Image
I want to make the iron core. That three-winged thingy, a part of the rotor. Since I'm linking everything to master sketch of the rotor, I have to start off this:
rotor-core-1.png
rotor-core-1.png (29.15 KiB) Viewed 1492 times
Then I add a Lattice array, that defines the number of wings, and is convenient for linking from sketches.
Then I add two sketches. One defines the shape of the wing, the other defines the volume occupied by the rotor.
rotor-core-2.png
rotor-core-2.png (41.09 KiB) Viewed 1488 times
Now, I Part Extrude one sketch, Part Revolve the other, and Part Common them together.
rotor-core-3.png
rotor-core-3.png (48.39 KiB) Viewed 1485 times
And populate the array, and fuse it together in Lattice
rotor-core-4.png
rotor-core-4.png (42.2 KiB) Viewed 1485 times
Done! Now I leave the body, and Part-o-magic automatically switches the body to Tip mode. The final result looks like this:
rotor-core-5.png
rotor-core-5.png (180.24 KiB) Viewed 1485 times
Here, I hacked into a PartDesign body, to show what I want.
DeepSOIC
Posts: 5413
Joined: Fri Aug 29, 2014 12:45 am
Location: Saint-Petersburg, Russia

Re: Non-PartDesign Body container proposal

Postby DeepSOIC » Mon May 23, 2016 12:58 pm

Project, if interested:
Attachments
motor test project v3-bodyhack.FCStd
(162.47 KiB) Downloaded 49 times
ickby
Posts: 2767
Joined: Wed Oct 05, 2011 7:36 am

Re: Non-PartDesign Body container proposal

Postby ickby » Mon May 23, 2016 1:15 pm

Ah ok, thanks for the detailled example. So you want to use it actually for visual grouping, to have the details only show up when editing the container, when it is active. This seems indeed very usefull for certain modling workflows.
DeepSOIC
Posts: 5413
Joined: Fri Aug 29, 2014 12:45 am
Location: Saint-Petersburg, Russia

Re: Non-PartDesign Body container proposal

Postby DeepSOIC » Mon May 23, 2016 1:25 pm

ickby wrote:So you want to use it actually for visual grouping, to have the details only show up when editing the container, when it is active.
Mostly yes, but not just that. It may be very handy to hold some sort of an intermediate result, that might be participating in further modeling steps, and might need to be modified often. Like an arrangement of holes for bolting together two plates: make the arrangement. Pack it into body. Then use the body to cut holes in one plate, and other plate. Then you realize another hole is needed. You just edit the body, and the rest recalculates automatically.
ickby
Posts: 2767
Joined: Wed Oct 05, 2011 7:36 am

Re: Non-PartDesign Body container proposal

Postby ickby » Mon May 23, 2016 1:37 pm

I think this will be a nice feature. Now how to achieve that. I still think that if you add more work into it it will be a duplication of effort, as I try to change the whole code to unify it with the Part code, where already much code duplication is available. As I like to minimize redoing stuff I propose the following:

1. I will try to come up with a way to extend arbitrary objects with grouping functionality in the next days (they include a holiday)
2. When availabl we both start a branch where we work on the exact splitting lines of functionality to minimize code duplication and maximise code reusability also in light of the things discussed here.

Would this be ok?
DeepSOIC
Posts: 5413
Joined: Fri Aug 29, 2014 12:45 am
Location: Saint-Petersburg, Russia

Re: Non-PartDesign Body container proposal

Postby DeepSOIC » Mon May 23, 2016 2:10 pm

OK. I can jump in when you get some coordinate system stuff working.
Since I've explained what I want (hopefully), I think my coding is no longer needed. You can also use that pull request as a guide to what I wanted to achieve. Just let me know, and hopefully my motivation will not evaporate to that moment.

Closing the pull request.
User avatar
yorik
Site Admin
Posts: 9597
Joined: Tue Feb 17, 2009 9:16 pm
Location: São Paulo, Brazil
Contact:

Re: Non-PartDesign Body container proposal

Postby yorik » Mon May 23, 2016 3:05 pm

This is exactly the kind of workflow I'd like to use in Arch too.

At the moment things are too basic and too restrictive: Some objects can be nested into others (a window into a wall for example), and you have a "general" group feature, the Floor, that is used to group several objects (walls, columns, etc) into a single structure.

But:

- This is too restrictive. If we want to "liberate" architectural/BIM design, we should permit other, unexpected ways of joining several components into one single structure/group/component/module/whatever the name
- Sometimes you will want several components to be fused, sometimes only compounded
- You want to be able to handle and move them as one object (think for ex. to a metallic container which would be made of several metal beams)
- It might be very intersting to indeed have different things appear in edit mode that are not visible outside edit mode.

So I think this idea would fit magnificently.

In arch/BIM workflow, it would also make little sense to have a "tip".