Question about coordinate system handling in GeoFeatureGroup

[realthunder]

I've just noticed that @ickby has recently pushed quite a few patches for GeoFeatureGroup(Extension), which changed the behavior of App::Part quite a bit. The one that I'm having problem with is how geo group handles the PropertyLink(ed) objects of its containing object. The current behavior is to force move all PropertyLink(ed) objects into the same geo group of the hosting object. The code comment mention that the reason is to forbid cross-coordinate linking.

A concrete example. Say, we have BoxA, BoxB, and a Fusion object of BoxA and B. BoxA and BoxB are in PartA. Now if we add the Fusion to another PartB, then BoxA and BoxB will be automatically moved from PartA to PartB. So, this means that BoxA and BoxB cannot be in any other Part altogheter. More generally speaking, any objects that are linked by a containing object cannot be in any other Part. I've found that to be very unreasonable.

Before geo group, FreeCAD already has the concept of local coordinate system from the very beginning. Every document object having a Placement property can be considered as having its own local coordinate system. This is more apparent in Part Workbench objects. In fact, geo group can be considered as a generalized Part::Compound object. So why is it necessary for geo group to have this "non-conforming" behavior, so to speak. Are there any real benefits?

[ickby]

The introduced changes further detailed the design as intended. I currently prepare more changes which even drive this further, than normal link properties crossing GeoFeatureGroup boundaries will fail recomputing. There will be special property settings for the ones who know what they are doing and are aware of the issues.

Before geo group, FreeCAD already has the concept of local coordinate system from the very beginning. Every document object having a Placement property can be considered as having its own local coordinate system.

This is not really true. Every object has a Placement, but changing that changes the geometry, e.g. the shape in a Part::Feature. Hence all geoemtry has been described in the global CS up to now. This allowed each tool to use each object, as they also have been described in the same CS. This is different now.

When having a object in a Part and the part is moved the objects placement is not changed, hence the properties do not changed. Staying at the Part example, the Shape proeprty now is not described in the global CS anymore but in its local one. So to get the global shape values one needs to make calculations with all stacked parent GeoFeatureGroups. And this is not known by the tools. So using objects of different GeoFeatureeGroups would always lead to wrong results.

Say, we have BoxA, BoxB, and a Fusion object of BoxA and B. BoxA and BoxB are in PartA. Now if we add the Fusion to another PartB, then BoxA and BoxB will be automatically moved from PartA to PartB. So, this means that BoxA and BoxB cannot be in any other Part altogheter. More generally speaking, any objects that are linked by a containing object cannot be in any other Part. I've found that to be very unreasonable.

That is very reasonable. Otherwise what you see is that you move Parts, see the fusion base objects move and expect the fusion to change, but it does not. And this is a mess.

Note that one could also not calculate the correct position of each object when needed. It is only possible for objects in the same Part or child Parts of the object in question. So changing all tools just to do the calculation does also not work-

[realthunder]

Before geo group, FreeCAD already has the concept of local coordinate system from the very beginning. Every document object having a Placement property can be considered as having its own local coordinate system.

This is not really true. Every object has a Placement, but changing that changes the geometry, e.g. the shape in a Part::Feature. Hence all geoemtry has been described in the global CS up to now. This allowed each tool to use each object, as they also have been described in the same CS. This is different now.

This is actually the crucial difference in our understanding of the subject, that is, the coordinate system handling. Let's still compare Part::Compound with geo group, and pretend that App::Part only accepts Part::Feature. Now what's the actual difference between these two? IMO, it is the different semantics they used when returning their claimed children. What Part::Compound returns are simply the contained child objects before adding to Part::Compound's own local coordinate system, and since every Part::Feature is doing the same, all their claimed child objects are in the global CS. What geo group returns, however, are the child objects under its local CS. If we change Part::Compound's sementics, it can behavior exactly the same as geo group.

Building on this analogy, we'll come to the next crucial difference between geo group and Part::Compound, which I think will seriously limit the usability of geo group. For Part::Compound, when an object is added into it, it exists both in Part::Compound's local CS and the global CS. The shortcoming of Part::Compound is that there is no easy way to directly refer and use the child object inside its local CS. But then, like you said, that's how FC used to work, and every other feature is kind of happy with it, because of the assumption of a common global CS.

When an object is added to a geo group, however, it is removed from the global CS, and thus only exists in geo group's local CS now. Every other features in FC is thus forced to deal with a much more complicated and dynamic local CS. What if the user actually wants to operate on the object in the global CS, or at least, will it be safer to say that the user will certainly want that in some case? There is no way of doing it now once the object is inside a geo group.

My proposal is simple, make geo group NOT removing the object from the global CS. Every other feature stays the same and will by default operate on the object inside global CS. If the user want the tool feature output to be in some local CS, he can manually move the feature to the corresponding geo group. FC can have the option to automatically move the newly added feature to the same geo group of its children objects, effectively having the same end result of what geo group is trying to achieve now, without the need to mess around with all the link properties.

Say, we have BoxA, BoxB, and a Fusion object of BoxA and B. BoxA and BoxB are in PartA. Now if we add the Fusion to another PartB, then BoxA and BoxB will be automatically moved from PartA to PartB. So, this means that BoxA and BoxB cannot be in any other Part altogheter. More generally speaking, any objects that are linked by a containing object cannot be in any other Part. I've found that to be very unreasonable.

That is very reasonable. Otherwise what you see is that you move Parts, see the fusion base objects move and expect the fusion to change, but it does not. And this is a mess.

It is not a mess if you keep the analogy of Part::Compound and geo group. BoxA and B are inside one compound, and when you move the compound, you don't expect the fusion object to change at all. And, that's entirely my point. Sometimes, user actually want that behavior. If he actually wants to put BoxA, BoxB and the fusion inside one compound (geo group), he can by all means do it. FC can automates it, and it make sense most of the time. But making it mandatory is unreasonable.

Let's make another example. Say we have BoxA, BoxB and Cylinder. We make a Cut of BoxA and Cylinder, and a Fusion of BoxB and the same Cylinder. Think the Cut being part of a socket assembly, and the Fusion being part of the plug assembly. Can I put the Cut and Fusion in different geo group? Which group will the Cylinder belong to? Why must we put the Cylinder into any group, since it is clearly not part of any assembly?