Discussion about the Assembly module implementation

Discussion about the development of the Assembly workbench.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
logari81
Posts: 658
Joined: Mon Jun 14, 2010 6:00 pm

Discussion about the Assembly module implementation

Post by logari81 »

Since there is already some significant progress in jriegel's dev-assembly branch, I would like to start this thread for discussing the implementation details of the Assembly module.

I have the following question for beginning:

The following features are used to organize an assembly project in FC:

Assembly::ItemAssembly: can hold several Assembly::ItemPart through its Items property
Assembly::ItemPart: can hold only one PartDesign::Body through its model property
PartDesign::Body: can hold several features representing the creation history of a part through its Model property

So my first question is why do we need Assembly::ItemPart and PartDesign::Body as separate objects? Why isn't it possible to integrate the Assembly::ItemPart functionality (e.g. Annotation) into PartDesign::Body?
User avatar
jriegel
Founder
Posts: 3369
Joined: Sun Feb 15, 2009 5:29 pm
Location: Ulm, Germany
Contact:

Re: Discussion about the Assembly module implementation

Post by jriegel »

logari81 wrote:PartDesign::Body[/b]: can hold several features representing the creation history of a part through its Model property

So my first question is why do we need Assembly::ItemPart and PartDesign::Body as separate objects? Why isn't it possible to integrate the Assembly::ItemPart functionality (e.g. Annotation) into PartDesign::Body?
Good question :)

One Body can be referenced by several ItemParts (multiple usage) with different position (placement) and different meta information. With this I separate the creation of the geometry (PartDesign or others) and the usage of the geometry in a product context. Also we need a way (context) to give the same Body different color and different visibility contexts. Thats all done by the Item hierarchy.

Furthermore I will make the Items able to handle all kind of App::GeometricalObject, e.g. Meshes or PointsClouds. There fore I plan to load the specialized modules only on demand (late loading).

Another point is the multi-model use case. In that the ItemPart will act as a proxy. The Body will be in a seperate document that gets only loaded if the user wants to change the geometry. In case of just using the geomtry the ItemPart loads/has just the result shape and shows them. That will make it possible to handle really huge design projects without blowing memory. The Item hirachy is also responsible for the 3D performance tuning. So it will (later :) ) build up "Level of Detail" nodes to manage bearably triangle count for huge projects.

Hope I answered you question, I'm looking forward to get in a broader discussion with the assembly, since it will be vital part if we want to be a useful CAD system.
Stop whining - start coding!
User avatar
tanderson69
Veteran
Posts: 1626
Joined: Thu Feb 18, 2010 1:07 am

Re: Discussion about the Assembly module implementation

Post by tanderson69 »

thanks for the explanation.

PartDesign::Body:
for me this is describing what UG calls reference sets. Inside the component part you create a reference set with a name and select geometry. Then from the assembly you can make a component use a reference set which would show only the subset of geometry contained in the reference set. Much better than some layer-type mess. A problem with UG is that the reference set references geometry and not features. This wouldn't be a problem with objects out of the PartDesign workbench as your goal is a single solid. The problems came when you created arrays of independent geometry (think Part workbench). You would create the reference set and then later change your array parameter and the reference set wouldn't add any newly created objects. The reference set needed to reference features and be part of the update cycle. Something to avoid?

jriegel wrote:The Item hirachy is also responsible for the 3D performance tuning. So it will (later :) ) build up "Level of Detail" nodes to manage bearably triangle count for huge projects.
I would think level of detail would be beneficial for all view providers not just assembly items. I will agree that it is a "must have" for assemblies, but something like this is would be helpful when working "close up" in a part file. Maybe Level of detail is something in the viewprovider base class and the child classes can enable and control parameters?

I promise I will download and run your assembly branch before I make anymore comments. ;)
logari81
Posts: 658
Joined: Mon Jun 14, 2010 6:00 pm

Re: Discussion about the Assembly module implementation

Post by logari81 »

jriegel wrote: Hope I answered you question, I'm looking forward to get in a broader discussion with the assembly, since it will be vital part if we want to be a useful CAD system.
thanks, actually you've already answered more than my question.

So now that I understand the purpose for ItemPart and Body I can make my original question more specific. Is it possible to move the Annotation property from ItemPart to Body? The reason for this is that during the design of a part the user may need to use standard and custom planes and custom axes e.g. as sketch planes or pattern references if the available part faces/edges do not cover his needs. All these predefined + added by the user reference geometries could go under an Annotation property of the Body feature.

E.g. for modelling a D-key groove, I would use the partdesign groove or pocket feature with its sketch on a custom plane in the middle of the groove length or width respectively.
Image
User avatar
jriegel
Founder
Posts: 3369
Joined: Sun Feb 15, 2009 5:29 pm
Location: Ulm, Germany
Contact:

Re: Discussion about the Assembly module implementation

Post by jriegel »

Ah ok.
this example I would do with a Pocket. If the Cylinder has the Z axes you use e.g. the XZ plane for a sketch and make a Pocket with mirrored extend or two free Limits.
At the moment we can not do it cause we need support for the Pocket. In case of a Body its possible, cause through the frame of the Body we always know the "tip" of the
history and can subtract a "free" Pocket from that tip.

The general question about additional reference elements is a bit more tricky. The modeler I know best (Catia V5) disallow planes in a Body. It will open force a GeometricalSet outside the
Body for additional elements. But Features inside the Body can reference that elements (which makes the idea a Body is consistent in itself hard to force) . I would like to go the way to
make the features that flexible, so we don't need that kind of reference elements (beside the main planes and axis).

The freestyle approach, as lived in the Part module, where every feature can link and reference every other is very powerful but also dangerous! You can end up very fast in a completely linking mess with no way out. I would like to offer that also, but would like to separate it from a more clean PartDesign. Maybe move it all in a ShapeDesign workbench/module....
Stop whining - start coding!
logari81
Posts: 658
Joined: Mon Jun 14, 2010 6:00 pm

Re: Discussion about the Assembly module implementation

Post by logari81 »

logari81 wrote:The freestyle approach, as lived in the Part module, where every feature can link and reference every other is very powerful but also dangerous!
yes I agree 100%. For this reason all partdesign features now accept references only from their Support. With the introduction of Body I wanted to make PartDesign features accept references only from the Body where they belong to plus a set of planes/axes attached to this Body under e.g. an Annotations property. Puting all these geometries under such a property clearly splits the Body actual geometry from any construction planes/axes. It is similar to the implementation in ProE.

In my opinion the annotations should include the standard planes but they should also accept adding custom planes/axes. The example I gave before can be done with the standard axes but I can for sure make up an example where using custom planes is inevitable.

Why do we need the Annotations property in the ItemPart, where did you plan to use this property originally? E.g. for aligning parts with respect to their standard planes?
User avatar
yorik
Founder
Posts: 13640
Joined: Tue Feb 17, 2009 9:16 pm
Location: Brussels
Contact:

Re: Discussion about the Assembly module implementation

Post by yorik »

logari81 wrote:Puting all these geometries under such a property clearly splits the Body actual geometry from any construction planes/axes.
This looks quite good to me... Specially in architecture, this duality (one big compound made only of solids, but including much "helper" geometry) would become very interesting. Think for example of a door, which has a frame and a sheet, that must be solid, so you can calculate their dimensions and volume, but also many small objects (fixtures, henches, knobs, etc) that you don't want as solid shapes, because they are too complex. I like much the idea of having 2 separate properties for solid and non-solid stuff. Very easy to classify your contents...

Then in Jürgen's design the place to separate these 2 concepts would be in ItemParts, and Bodies would always be solid? Why not?
User avatar
jriegel
Founder
Posts: 3369
Joined: Sun Feb 15, 2009 5:29 pm
Location: Ulm, Germany
Contact:

Re: Discussion about the Assembly module implementation

Post by jriegel »

Ok, I will put the Annotation property also in the Body. The filling up of this structures is mostly done in python scripts.
In opposite to the PartDesign where lot of the Command logic is in the C++ commands, I decided for Assembly to split it more up.
So most of the Commands, e.g. creating a new Part in a Product/Assembly, will call a python method in the AssemblyLib.py module, which fill in
the need objects and parameters. Here we can easily experiment later whats the best configuration. Or even make completely different for e.g. Arch needs...
Stop whining - start coding!
User avatar
yorik
Founder
Posts: 13640
Joined: Tue Feb 17, 2009 9:16 pm
Location: Brussels
Contact:

Re: Discussion about the Assembly module implementation

Post by yorik »

jriegel wrote:The filling up of this structures is mostly done in python scripts.
I liked that 8-)
User avatar
jriegel
Founder
Posts: 3369
Joined: Sun Feb 15, 2009 5:29 pm
Location: Ulm, Germany
Contact:

Re: Discussion about the Assembly module implementation

Post by jriegel »

Yes Yorik, this also targeted toward you :)

Assembly will be hopefully the kind of glue to put all the applications together, so you can use in Arch meshes or pointclouds.
And the multi-document will be also important for BIM, where the model (I suppose) can become enormous!
Stop whining - start coding!
Post Reply