Position and orientation in the reference frame of a LCS

[carlopav]

+1 to me, @rt, is there a reason why App::Link do not have this method?

Ping

[realthunder]

I actually think 'GlobalPlacement' should be deprecated because 'Link' is introduced. Just imaging Link A that links to a Group that contains another Link B, when you ask for the global placement of Link B, which one should it return, because Link B will appear in two placements in the 3D view. This problem extends to all objects, because the same object can appear in multiple places through Link.

The solution is to always use the full object path to query for the placement. You can obtain the object path by passing an extra argument to Gui.Selection.getSelectionEx(), the path is available through attribute SubElementNames. You can then pass the path to DocumentObject.getSubObject() to obtain the accumulated global placement.

Code: Select all

for sel in Gui.Selection.getSelectionEx('',0):
  for path in sel.SubElementNames if sel.SubElementNames else ['']:
    placement = sel.Object.getSubObject(path, retType=3) # retType 3 returns the placement. Check the doc string for more info
    print('%s.%s -- %s' % (sel.Object.Name, path, placement))
    

[openBrain]

I actually think 'GlobalPlacement' should be deprecated because 'Link' is introduced. Just imaging Link A that links to a Group that contains another Link B, when you ask for the global placement of Link B, which one should it return, because Link B will appear in two placements in the 3D view. This problem extends to all objects, because the same object can appear in multiple places through Link.

Makes no real sense to me.
You should consider "object" in the meaning of "document object", not "solid shape".

An object can appear several time in a document, but not at different placements (or there is a flaw somewhere).

[realthunder]

Makes no real sense to me.
You should consider "object" in the meaning of "document object", not "solid shape".

An object can appear several time in a document, but not at different placements (or there is a flaw somewhere).

Just create a Part container, and add a cube inside, and then create a link to the Part container, and finally move the link to somewhere else. Now you have the same cube object at two placements. That's how complex hierarchical models can be handled efficiently. The STEP standard uses similar 'object path' concenpt to uniquely identify instance in an assembly.

[edwilliams16]

Just create a Part container, and add a cube inside, and then create a link to the Part container, and finally move the link to somewhere else. Now you have the same cube object at two placements. That's how complex hierarchical models can be handled efficiently. The STEP standard uses similar 'object path' concenpt to uniquely identify instance in an assembly.

I think we are all talking past each other. Above we end up with two instances of the same object at different locations in 3D. If you interrogate the two instances, they have different global placements. Why not provide the link instances with a getGlobalPlacement() method - even if all it does is repeat what is found in Object.getSubObject(path, retType=3)?
If you deprecate getGlobalPlacement(), a lot of code will break - but as it stands, it only works some of the time. Or am I still missing some situation where this won't work?

[realthunder]

I think we are all talking past each other. Above we end up with two instances of the same object at different locations in 3D. If you interrogate the two instances, they have different global placements. Why not provide the link instances with a getGlobalPlacement() method - even if all it does is repeat what is found in Object.getSubObject(path, retType=3)?
If you deprecate getGlobalPlacement(), a lot of code will break - but as it stands, it only works some of the time. Or am I still missing some situation where this won't work?

The point I am trying to make is that the current 'bottom up' use case of 'getGlobalPlacement()' is ill defined, where the user code expects to obtain the global placement from a bottom leaf object. What I am saying is that you should do this from the top. Even if you are just suggesting a better name of an API for getting global placement, using the old name (that applies in a different use case) would just confuse user.

[carlopav]

Imho getGlobalPlacement still make Sense when you have to deal with the DocumentObjects, but looks broken when you use It in Gui environment.

I can speak about Draft cause it's the only part of the codebase that i know pretty well. All the commands like move, rotate, etc compute the global placement in the "App" module of the function. This Is still valid when scripting, but result in broken behavior when in Gui and links are involved.

So why not make It clearer and have a:
- getGlobalPlacement of the documentObject
- getVisualPlacement method of the selectionobject?

[openBrain]

Just create a Part container, and add a cube inside, and then create a link to the Part container, and finally move the link to somewhere else. Now you have the same cube object at two placements. That's how complex hierarchical models can be handled efficiently. The STEP standard uses similar 'object path' concenpt to uniquely identify instance in an assembly.

Thanks for this. See what you need now. Need to rethink about it.

[galou_breizh]

I actually think 'GlobalPlacement' should be deprecated because 'Link' is introduced. Just imaging Link A that links to a Group that contains another Link B, when you ask for the global placement of Link B, which one should it return, because Link B will appear in two placements in the 3D view. This problem extends to all objects, because the same object can appear in multiple places through Link.

The solution is to always use the full object path to query for the placement. You can obtain the object path by passing an extra argument to Gui.Selection.getSelectionEx(), the path is available through attribute SubElementNames. You can then pass the path to DocumentObject.getSubObject() to obtain the accumulated global placement.

Code: Select all

for sel in Gui.Selection.getSelectionEx('',0):
  for path in sel.SubElementNames if sel.SubElementNames else ['']:
    placement = sel.Object.getSubObject(path, retType=3) # retType 3 returns the placement. Check the doc string for more info
    print('%s.%s -- %s' % (sel.Object.Name, path, placement))
    

I wish I had read this piece of code before writing the GetGlobalPlacement macro!

I agree with realthunder in the sense that it's better to not have a feature that doesn't work as expected.

Gaël

[carlopav]

Need to rethink about it.

Se more thoughts? To me this is quite a crucial topic and would be nice if we could have a consistent api exposed to the developers...