I'm working on TempoVis upgrade (visibility automation)

[DeepSOIC]

* I have added toggleClippingPlane() function to all View3DInventor.

Can I query the current state of the clipping plane? I kinda need it for new tempovis implementation... but assuming it always off should be a good enough hack for now.

[realthunder]

OK, got it. I struggled for quite some time to figure out, how on earth does getContainerChain still work and doesn't follow Links, while all the functions recognize Link as a container.

So, is this a desirable behavior? I don't quite get what you want yet. Do you want to find the chain excluding any Links?

Anyway, you might also what to check out the 'Parents' attribute that is available in all document objects. It lists all possible path from top level objects in all documents that can lead to the given object, directly or indirectly through Link. Not only does it include Link to parent groups, but Link to that object as well. So if there is a Link001 to a Sketch001 that is included in some Group001, then you will find (Group001, 'Link001.') listed in Sketch001.Parents. I added this attribute because it is kind of tricky to exhaust this list. You can find the implementation here.

however, it will break down in the first case, if I for example bind an expression to the Link that refers to the object.

Why is that so? PropertyExpressionEngine (and PropertySheet) now behavior similar to various link properties. Referring to an object in an expression is equivalent to add a link to that object, which will make property owner appear in the linked object's InList.

Can I query the current state of the clipping plane? I kinda need it for new tempovis implementation... but assuming it always off should be a good enough hack for now.

I can add hasClipplingPlane() if you want. But the first argument in toggleClippingPlane() can already let you control whether to toggle (-1), off(0), or on(1). You can find more details in the python docstring.

[DeepSOIC]

Do you want to find the chain excluding any Links?

Well, maybe... maybe not. It looks like Containers.py is essentially not used by tempovis anymore, and I may remove it altogether. The API provided by you (in freecad) is now much better, and the way Containers.py was designed doesn't fit well into the new model.

you might also what to check out the 'Parents' attribute that is available in all document objects.

Oh yes I do!, thanks.

But the first argument in toggleClippingPlane() can already let you control whether to toggle (-1), off(0), or on(1). You can find more details in the python docstring.

Yes, I understood how it works. The thing is, I abstracted out all the specific changes doable via TV into plug-in classes called "SceneDetail".
Here's one implementation: https://github.com/DeepSOIC/FreeCAD-ell ... roperty.py
One of the methods required for the system to work is scene_value(). It should return the state of thing on the screen. It is used by tempovis as a way to remember the current state of things, to save it for restoring later. As I have said, it's going to be enough for now to just always return "no clipping plane". But for a proper implementation, I need both the current state and the placement of the plane. Eventually, it might be not that useful in the end, as I can't yet imagine a practical situation where the proper return value is really crucial.

[DeepSOIC]

Why is that so?

Try running this:

Code: Select all

from Show import Containers
Containers.ContainerChain(App.ActiveDocument.Sketch)

on these two files:

link-part-multinesting.FCStd

(14.74 KiB) Downloaded 15 times

link-part-multinesting-expression.FCStd

(14.56 KiB) Downloaded 11 times

The files differ only in that in the second one, there is an expression bound to Link object that uses Sketch:

Code: Select all

App.ActiveDocument.Link.setExpression("Placement.Rotation.Angle", "Sketch.Placement.Rotation.Angle + 90 deg")

In the first one, ContainerChain returns <Document>, <Part>. In the second one, ContainerChain fails with an error "Container tree is not a tree".

[DeepSOIC]

@realthunder. There are two implementations of isContainer function: one in DepGraphTools.py, and one in Containers.py, and they have a slightly different implementation. I'd like to merge them. Which one to favor?

Code: Select all

def _isContainer(obj):
    '''isContainer(obj): returns True if obj is an object container, such as 
    Group, Part, Body. The important characterisic of an object being a 
    container is visibility nesting.'''
    
    if obj.hasChildElement():
        return True
    if obj.hasExtension('App::OriginGroupExtension'):
        return True
    if obj.hasExtension('App::GroupExtension'):
        return True
    if obj.isDerivedFrom('App::Origin'):
        return True
    return False

def isContainer(obj):
    if _isContainer(obj):
        return True
    linked = obj.getLinkedObject()
    return linked and linked!=obj and _isContainer(linked)

...vs...

Code: Select all

def isAContainer(obj):
    '''isAContainer(obj): returns True if obj is an object container, such as 
    Group, Part, Body. The important characterisic of an object being a 
    container is that it can be activated to receive new objects. Documents 
    are considered containers, too.'''
    
    if obj.isDerivedFrom('App::Document'):
        return True
    if obj.hasExtension('App::GroupExtension'):
        return True
    if obj.isDerivedFrom('App::Origin'):
        return True
    if obj.hasChildElement():
        return True
    return False

[realthunder]

The files differ only in that in the second one, there is an expression bound to Link object that uses Sketch:

Thanks to your test case, I just discovered another missing patch. I've pushed it to my LinkMerge branch. When linked to an App::Part, Link.getSubObjects() is supposed to exclude those non-direct children like Sketch in this case.

Regarding your other question, the second version (isAContainer) is better, as Link can internally handle linking.

[DeepSOIC]

The code is mostly finished. https://github.com/DeepSOIC/FreeCAD-ell ... vis-stack2
It's based on realthunder's fix branch, so I'll wait for it to be merged before making a PR. I'll also do a bit more testing, and possibly add workbench switching to the capabilities.