App::Part question
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
Re: App::Part question
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.
Re: App::Part question
Yep, that's the issue... My idea is to make objects for base planes/axis unique, as described before. The next step is either: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.
- 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...
Re: App::Part question
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
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.
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
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.pcHighlight->objectName = "X-AXIS"
pcHighlight->documentName = pcObject->getDocument()->getName();
pcHighlight->subElementName = "Main";
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.
Re: App::Part question
ickby, yes that's mostly I was thought about...
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...
That's exactly lines I was looking for.. I couldn't find out how SoFCHighlight get knows which object it should return...ickby wrote:pcHighlight->objectName = "X-AXIS"
pcHighlight->documentName = pcObject->getDocument()->getName();
I don't suppose it's a big draw-back... and better than have lots and lots of useless planes/axis objects around...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.
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...
Re: App::Part question
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 love the idea of adding an origin to an arbitrary object more and more...
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.
Re: App::Part question
Just to avoid misunderstanding:
Refered to:Fat-Zer wrote:Although I love the idea of adding an origin to an arbitrary object more and more...
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...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...
It will differ in any case if the placement property is non-zero.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.
Axis/planes still will be in the tree but grouped by the single origin object.ickby wrote:Although I wouldn't easily throw away the representation in the tree view
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: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.
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 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).
Re: App::Part question
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: 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.It will differ in any case if the placement property is non-zero.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.
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.Axis/planes still will be in the tree but grouped by the single origin object.
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: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?
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.
Re: App::Part question
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)
Re: App::Part question
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: For everything else it would be just wrong to draw the placement as CS.
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: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.
thanks for listing those up...ickby wrote:Here is how I see the pro/con lists:
There is a second variant: Each body/part has an origin object but the Planes/Axis are shared...ickby wrote:Reduced:
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
Reduced:ickby wrote:Can you see any other important aspect? As far as this goes I'm still for the current variant.
- 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:
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:- Pro: tremendously less axis/planes/origin objects // - Con: many origins document objects which are often unused
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:- Con: cluttered DAG view // - Pro: localized and uncluttered DAG view
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: 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
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:- Pro: easy to handle visualisation
I suppose mostly it will be done when setting an active part/body... but this one still an issue...ickby wrote:- Con: the need to toggle a property for CS visualisation
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:- Con: Highly unintuitive tree selection behaviour
My vote is still for the reduced, but the current one is not seems so bad for me anymore...ickby wrote:As far as this goes I'm still for the current variant.
IMHO pretty definitely that Mixed is the worst one =))
Re: App::Part question
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?
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?