App::Part question

Discussion about the development of the Assembly workbench.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
ickby
Veteran
Posts: 3116
Joined: Wed Oct 05, 2011 7:36 am

Re: App::Part question

Post by ickby »

ah ok. "ViewProviderBody::claimChildren3d()" ensures that all children nodes are grouped beneath the body node in the scene graph. So the visualisation moves, but the features shape itself stays. The body features stay fixed in the part coordinate system and hence do not change when moving the body. So the only issue, when making the body movable in the part, is the missallignemt of the origin visualisation with the feature visualisation. When for example selecting a axis for rotational pattern a pad/pocket may not rotate around the choosen axis. Could that be solved somhow without a own body origin object? Because I think it is highly confusing.
Fat-Zer
Posts: 176
Joined: Thu Oct 30, 2014 10:38 pm

Re: App::Part question

Post by Fat-Zer »

ickby wrote:So the only issue, when making the body movable in the part, is the missallignemt of the origin visualisation with the feature visualisation. When for example selecting a axis for rotational pattern a pad/pocket may not rotate around the choosen axis. Could that be solved somhow without a own body origin object? Because I think it is highly confusing.
Yep, that's the issue... My idea is to make objects for base planes/axis unique, as described before. The next step is either:
  • Just add an origin to the body I don't see a big deal hear...
  • The other idea is to remove origin at all (or keep no more than one for global CS grouping). And add yet another property to the base ViewProvider class, so every object have an option to display it's origin...
In both cases base plane will draw nothing and everything will be done inside origin, so there shouldn't be problems with positions/sizes... But the problem I see is how to pass events like selection to the real plane/axis objects.
ickby
Veteran
Posts: 3116
Joined: Wed Oct 05, 2011 7:36 am

Re: App::Part question

Post by ickby »

I think I found a much simpler solution for achiving what you want. The selection in freecad works like this: the preselection/selection is detected in the scenegraph and then processed to the SoFCHighlight node. This node then adds a stored document object name to the freecad selection system. The object name for the node is simply set in the viewprovider and can easily be overridden, especially as we now have a custom SoFCHighlight node in the axis / planes viewprovider. So it could work like this:

1. Keep everything as it is now, with a origin and base planes/axis objects for every local coordinate system (Part and then aditinonal body)
2. Add a global origin to the document space. Those are the planes / axis document objects you use everywhere as reference and which you are linking too.
3. In the viewprovider of the base planes / axis you change the highlight node to not get the name of the attached object itself but for the global axis. So basically if the global x-axis document object would be called "X-AXIS", every other origin "X-Axis001" would be set to
pcHighlight->objectName = "X-AXIS"
pcHighlight->documentName = pcObject->getDocument()->getName();
pcHighlight->subElementName = "Main";
This ensures that you have full visualisation, size adjustment, show/hide and everything that works now but with the additional improvement of always linking to a single set of axis/planes, which makes your code easier. The only disadvantag I can see is for the DAG-View, as there many origin elements are visible and unused.

In theory you can do this also with your "origin only" plan, the origin just needs to add multiple SoFCSelection ndoes for the individual axis/planes it draws. However, this than has the disadvantage that the user can not select the planes and axis directly in the tree and also can not easily hide/show them individual.

Note that I did not test this, no time for coding right now, but it should work like this theoretically.
Fat-Zer
Posts: 176
Joined: Thu Oct 30, 2014 10:38 pm

Re: App::Part question

Post by Fat-Zer »

ickby, yes that's mostly I was thought about...
ickby wrote:pcHighlight->objectName = "X-AXIS"
pcHighlight->documentName = pcObject->getDocument()->getName();
That's exactly lines I was looking for.. I couldn't find out how SoFCHighlight get knows which object it should return...
ickby wrote:In theory you can do this also with your "origin only" plan, the origin just needs to add multiple SoFCSelection ndoes for the individual axis/planes it draws. However, this than has the disadvantage that the user can not select the planes and axis directly in the tree and also can not easily hide/show them individual.
I don't suppose it's a big draw-back... and better than have lots and lots of useless planes/axis objects around...
To display only axis/planes origin's viewProvider may have two properties like: displayAxis and displayPlanes, or even a separate property for each axis/plane, or just store that in Display Mode property...

Although I love the idea of adding an origin to an arbitrary object more and more...
ickby
Veteran
Posts: 3116
Joined: Wed Oct 05, 2011 7:36 am

Re: App::Part question

Post by ickby »

Although I love the idea of adding an origin to an arbitrary object more and more...
What would be the purpose of that? I don't realy see a use case for anything that does not represent a local coordinate system which is a relative reference for others.

Although I wouldn't easily throw away the representation in the tree view, IMHO it is not intuitive to have th axis/planes not in the tree for selection and orientation. It may also not be very intuitive if all objects point to the same axis/plane elements in the DAG view, as they are clearly different axis/planes which are not coincident. (e.g. a Part x-axis is not coincident with origin x-axis for a moved part, and then in the dag view the feature points to the origin axis even if it uses the parts x-axis). It will mess up the dag view in general when all parts/bodies point to the same origin objects, as for many bodies the connection lines get very long. Then even collapsing groups can not help anymore.

I know that it makes many thing easier from programming side, but this must stay intuitive for the user. we have to be carefule here when deciding which route we go.
Fat-Zer
Posts: 176
Joined: Thu Oct 30, 2014 10:38 pm

Re: App::Part question

Post by Fat-Zer »

Just to avoid misunderstanding:
Fat-Zer wrote:Although I love the idea of adding an origin to an arbitrary object more and more...
Refered to:
Fat-Zer wrote:The other idea is to remove origin at all (or keep no more than one for global CS grouping). And add yet another property to the base ViewProvider class, so every object have an option to display it's origin...
So the Idea is to get rid off the quite useless (they do nothing but displaying the origin, so why they are needed on App level?) Origin objects and replace them with a property of view providers... I suppose that was quite unclear...
ickby wrote:I don't really see a use case for anything that does not represent a local coordinate system which is a relative reference for others.
It will differ in any case if the placement property is non-zero.
ickby wrote:Although I wouldn't easily throw away the representation in the tree view
Axis/planes still will be in the tree but grouped by the single origin object.
ickby wrote:It may also not be very intuitive if all objects point to the same axis/plane elements in the DAG view, as they are clearly different axis/planes which are not coincident.
I see your concerns here... may be the statement that axis/plane object are always represents a local coordinate system, no matter they looks to be drawn is too unclear... But I don't see any good way to represent it anyway...
ickby wrote: (e.g. a Part x-axis is not coincident with origin x-axis for a moved part, and then in the dag view the feature points to the origin axis even if it uses the parts x-axis).
just to ensure we are talking about the same, there won't be any other axis/planes DocumentObjects but the global ones in any of the currently discussed variants, right?
ickby
Veteran
Posts: 3116
Joined: Wed Oct 05, 2011 7:36 am

Re: App::Part question

Post by ickby »

ickby wrote:
I don't really see a use case for anything that does not represent a local coordinate system which is a relative reference for others.
It will differ in any case if the placement property is non-zero.
Here you are wrong. If you move/rotate geometry it does not change the coordinate system. The axis and planes are still where they have been before. The simplest example is a vector in 2d coordinates, see the difference for geometry transformation and local coordinate system transformation:
ca.png
ca.png (12.22 KiB) Viewed 2330 times
So if you draw axis and planes of a geometry object they always need to stay at the coordinate system the geometry lives in, the global one or the one of the part or the one of the body the geometry is located in. This is why a CS visualisation makes only sense for real local coordinate systems. So only for App::Part, the body if not fixed and the global document CS. For everything else it would be just wrong to draw the placement as CS.
Axis/planes still will be in the tree but grouped by the single origin object.
Please consider my picture above. Why should I select the global x axis in the tree if I want to rotate the vector around the local x-axis? This would not make sense. This is why I prefere the axis/planes for every local coordinate system in the tree.
just to ensure we are talking about the same, there won't be any other axis/planes DocumentObjects but the global ones in any of the currently discussed variants, right?
No, I challenge this :) I see three options: your reduced variant with only one origin object, the current full one with a origin for every local CS. Then there is the alternativ mixed one: using the tree structure as it currently is plus the global document CS origin and ensure that every origin selection in the tree internally selects the global CS origin. Here is how I see the pro/con lists:

Reduced:
- Pro: tremendously less axis/planes/origin objects
- Pro: easier movement of document objects between Parts/bodies as they use all the same origin objects for reference
- Con: Highly unintuitive tree selection behaviour
- Con: the need to toggle a property for CS visualisation
- Con: cluttered DAG view

Full:
- Pro: correct and intuitive tree selection
- Pro: localized and uncluttered DAG view
- Pro: easy to handle visualisation
- Con: many origins document objects which are often unused
- Con: Hard to move objects due to the need of changing the origin references

Mixed:
- Pro: correct and intuitive tree selection
- Pro: easy to handle visualisation
- Pro: easier movement of document objects between Parts/bodies as they use all the same origin objects for reference
- Con: cluttered DAG view
- Con: many origins document objects which are often unused

Can you see any other important aspect? As far as this goes I'm still for the current variant.
ickby
Veteran
Posts: 3116
Joined: Wed Oct 05, 2011 7:36 am

Re: App::Part question

Post by ickby »

By the way, the body implementation is a mixture of geometry and CS transformation. If you change the placement of the body the bodies shape property sees a geometric transformation, as it lifes in the Part local CS, but the bodies features see a CS transformation (their shape values do not change)
Fat-Zer
Posts: 176
Joined: Thu Oct 30, 2014 10:38 pm

Re: App::Part question

Post by Fat-Zer »

ickby wrote: For everything else it would be just wrong to draw the placement as CS.
That's I've ment, and I don't think it's really wrong... IMO it still have some sense... But I won't insist on that...
ickby wrote:Please consider my picture above. Why should I select the global x axis in the tree if I want to rotate the vector around the local x-axis? This would not make sense. This is why I prefere the axis/planes for every local coordinate system in the tree.
But whichever axis you choose the vector will be rotated around the local axis, there is no way to link to the global CS from the local and I don't see any way to overcome it... why should we make several entries in tree if their selection will lead to the same resulet? Also I believe that presence both global and local objects is confusing in the way that user may think that he actually can link to it from local CS...
ickby wrote:Here is how I see the pro/con lists:
thanks for listing those up...
ickby wrote:Reduced:
There is a second variant: Each body/part has an origin object but the Planes/Axis are shared...
Reduced with origins:
- Pro: tremendously less axis/planes objects
- Pro: easier movement of document objects between Parts/bodies as they use all the same origin objects for reference
- Con: Still unintuitive tree selection behavior (may be even more)
- Con: Not possible to toggle axis/planes one-by one
- Con: cluttered DAG view with additional objects
ickby wrote:Can you see any other important aspect? As far as this goes I'm still for the current variant.
Reduced:
- Pro: Shows the user things as they are
Full/Mixed:
- Cons: Gives a wrong filling that there is a possibility to link between different planes/axis

So let's decide which are more and which are less important... Here is the order of importance for me:
ickby wrote:- Pro: tremendously less axis/planes/origin objects // - Con: many origins document objects which are often unused
For a small body consisting from only one sketch and one feature this one will result in 14(13) trash objects for 4(5) useful... My DAG view can handle only 45 features at once, so for two parts' I'll likely have to scroll it... May be ovecome by e.g. implementing some collapse functionality in DUG view...
ickby wrote:- Con: cluttered DAG view // - Pro: localized and uncluttered DAG view
I don't know which one will worse: the cluttered one with lots of connections or the one with damn lots of useless objects... both may problems may be particularly overcome with collapse functionality...
ickby wrote:- Pro: easier movement of document objects between Parts/bodies as they use all the same origin objects for reference // - Con: Hard to move objects due to the need of changing the origin references
Implementation part is not the hardest one here, but the bad thing here is that's impossible to handle all the cases and we will have to add fix up tool I suppose...
ickby wrote:- Pro: easy to handle visualisation
IMHO less important then previous one due to may be implemented in the mixed and couldn't be broken by any tricky operations...
ickby wrote:- Con: the need to toggle a property for CS visualisation
I suppose mostly it will be done when setting an active part/body... but this one still an issue...
ickby wrote:- Con: Highly unintuitive tree selection behaviour
I don't think it's _highly_ unintuitive... as far as there is only one object they represent the local system of the current operation... On the other side the current variant as well as mixed gives wrong presumption to the user...
ickby wrote:As far as this goes I'm still for the current variant.
My vote is still for the reduced, but the current one is not seems so bad for me anymore...
IMHO pretty definitely that Mixed is the worst one =))
Fat-Zer
Posts: 176
Joined: Thu Oct 30, 2014 10:38 pm

Re: App::Part question

Post by Fat-Zer »

Ok, another smaller change about Parts to discuss (assuming the current state) :
Make Origin a separate Link property inside the App::Part.
Reasons:
- Origin is a special object and should be treated differently comparing to others Part's items.
- Will ease it's finding.

Also if not only Parts will have Origins, may be it will make sense to create a yet another intermediate class between Parts and GeoFeatureGroup...

So the question here is there will be any other assembly objects with Origins?
Post Reply