I'm working on TempoVis upgrade (visibility automation)
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
- DeepSOIC
- Veteran
- Posts: 7896
- Joined: Fri Aug 29, 2014 12:45 am
- Location: used to be Saint-Petersburg, Russia
I'm working on TempoVis upgrade (visibility automation)
Hi.
Just a quick announcement, that I'm upgrading TempoVis to support stack (nice behavior of concurrent instances), and better project saving behavior.
For those who don't know, TempoVis is a python class to do some changes to the scene (such as hiding some stuff, hiding, clipping, etc) and then undoing them later. Mostly aimed at all sorts of edit modes. Sketcher, Attachment, and some Part and PartDesign workbench dialogs use the class. It is also used in Part-o-magic extensively.
Right now, if one applies changes to the scene via two Show.TempoVis instances in wrong order, the scene can be messed up. This change should fix that.
Also, if one saves a project while in edit mode, all the visibilities and other property changes done through TV are saved to the file like in the edit state; but the project then loads, the editing is not entered, but the scene is still like we are editing. This is also getting fixed, and it was the main reason of the rewrite. This is a particular problem with Part-o-magic/Manipulator x-ray command, which is semi-permanent, but doesn't save nicely to the file.
Also, the new TempoVis now supports plugins, where one can define a special change to the scene as a small class, and use it to save/restore the scene through TempoVis. All standard facilities were reimplemented to work as plugins
Currently, branch is here: https://github.com/DeepSOIC/FreeCAD-ell ... ovis-stack
I don't think anyone will be particularly excited about it, but I decided post just in case.
Just a quick announcement, that I'm upgrading TempoVis to support stack (nice behavior of concurrent instances), and better project saving behavior.
For those who don't know, TempoVis is a python class to do some changes to the scene (such as hiding some stuff, hiding, clipping, etc) and then undoing them later. Mostly aimed at all sorts of edit modes. Sketcher, Attachment, and some Part and PartDesign workbench dialogs use the class. It is also used in Part-o-magic extensively.
Right now, if one applies changes to the scene via two Show.TempoVis instances in wrong order, the scene can be messed up. This change should fix that.
Also, if one saves a project while in edit mode, all the visibilities and other property changes done through TV are saved to the file like in the edit state; but the project then loads, the editing is not entered, but the scene is still like we are editing. This is also getting fixed, and it was the main reason of the rewrite. This is a particular problem with Part-o-magic/Manipulator x-ray command, which is semi-permanent, but doesn't save nicely to the file.
Also, the new TempoVis now supports plugins, where one can define a special change to the scene as a small class, and use it to save/restore the scene through TempoVis. All standard facilities were reimplemented to work as plugins
Currently, branch is here: https://github.com/DeepSOIC/FreeCAD-ell ... ovis-stack
I don't think anyone will be particularly excited about it, but I decided post just in case.
Re: I'm working on TempoVis upgrade (visibility automation)
Coolness!
How does it integrate with the App::Link code?
Can it benefit the Glass addon at all?
Alone you go faster. Together we go farther
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
- DeepSOIC
- Veteran
- Posts: 7896
- Joined: Fri Aug 29, 2014 12:45 am
- Location: used to be Saint-Petersburg, Russia
Re: I'm working on TempoVis upgrade (visibility automation)
Currently, in conflict.
I have just looked at realthunder's changes to TempoVis.py, there is quite a bit, I will have to incorporate that. Hopefully, AFTER the merge of App::Link.
I didn't expect substantial changes there, but... there are changes. Thanks for asking. That might even require a redesign
Re: I'm working on TempoVis upgrade (visibility automation)
bummer. please stay motivated!
Alone you go faster. Together we go farther
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
-
- Veteran
- Posts: 2190
- Joined: Tue Jan 03, 2017 10:55 am
Re: I'm working on TempoVis upgrade (visibility automation)
Here is a summary of my modification:
* Link introduces some new types of group. The major difference comparing to existing group is that the children visibility information is stored inside the group. I added a few APIs to DocumentObject to expose this information, hasChildElement, is/setElementVisible(). A simple way to judge if any given object is a new type of group is to call hasChildElement(). For example, a Link to a group (including plain and geo group) will return True when calling hasChildElement(). I have modified TempoVis Container.py to detect this new type of container.
* Because of Link, it is now tricky to find out the placement of any given object. Function like getGlobalPlacement() is not viable anymore, because an object can appear in multiple places, under various containers, or linked from various external documents. I have modified the Gui.Selection extensively to help disambiguate the selection. Functions like Gui.Selection.getSelectionEx() now accepts an extra integer argument. At the current stage, the only meaningful values are 0 and 1. 0 means auto resolve the selected object for backward compatibility, and 1 to get the full object path in SubElementNames, which can be used to call Object.getSubObject() to obtain the placement. The getSubObject() API is a bit complex. Please consult the Python docstring, and let know if you have any problem.
* The object editing is also modified due to the above placement complication, especially Sketch. Several APIs are modified/added to Gui.Document to support in-place-editing. You can find more details here
* I have added toggleClippingPlane() function to all View3DInventor. The clipping plane can either to added to the view root node, or the editing root node, which is described in the above link.
* I added a patch to allow TempoVis to restore body visible feature after editing, because body enforces one and only one visible solid feature, and the visibility won't be properly restored if the user edits a sketch of a middle invisible feature.
* Link introduces some new types of group. The major difference comparing to existing group is that the children visibility information is stored inside the group. I added a few APIs to DocumentObject to expose this information, hasChildElement, is/setElementVisible(). A simple way to judge if any given object is a new type of group is to call hasChildElement(). For example, a Link to a group (including plain and geo group) will return True when calling hasChildElement(). I have modified TempoVis Container.py to detect this new type of container.
* Because of Link, it is now tricky to find out the placement of any given object. Function like getGlobalPlacement() is not viable anymore, because an object can appear in multiple places, under various containers, or linked from various external documents. I have modified the Gui.Selection extensively to help disambiguate the selection. Functions like Gui.Selection.getSelectionEx() now accepts an extra integer argument. At the current stage, the only meaningful values are 0 and 1. 0 means auto resolve the selected object for backward compatibility, and 1 to get the full object path in SubElementNames, which can be used to call Object.getSubObject() to obtain the placement. The getSubObject() API is a bit complex. Please consult the Python docstring, and let know if you have any problem.
* The object editing is also modified due to the above placement complication, especially Sketch. Several APIs are modified/added to Gui.Document to support in-place-editing. You can find more details here
* I have added toggleClippingPlane() function to all View3DInventor. The clipping plane can either to added to the view root node, or the editing root node, which is described in the above link.
* I added a patch to allow TempoVis to restore body visible feature after editing, because body enforces one and only one visible solid feature, and the visibility won't be properly restored if the user edits a sketch of a middle invisible feature.
- DeepSOIC
- Veteran
- Posts: 7896
- Joined: Fri Aug 29, 2014 12:45 am
- Location: used to be Saint-Petersburg, Russia
Re: I'm working on TempoVis upgrade (visibility automation)
Thanks, that is very helpful. The vastness of your pull request makes it difficult for me to quickly look at all the changes you made in that territory.
I would have probably patched PartDesign instead, but I'll take a look.realthunder wrote: ↑Fri Aug 16, 2019 1:11 pm I added a patch to allow TempoVis to restore body visible feature after editing, because body enforces one and only one visible solid feature, and the visibility won't be properly restored if the user edits a sketch of a middle invisible feature.
-
- Veteran
- Posts: 2190
- Joined: Tue Jan 03, 2017 10:55 am
Re: I'm working on TempoVis upgrade (visibility automation)
I just realized that I missed a patch of BodyPy for this to work. There is new attribute 'VisibleFeature' in body to return that single visible solid feature in the body. I modified TempoVis to save the visibility of this feature before editing. I have added missed patch in my LinkMerge branch here and another small fix of TempoVis here
- DeepSOIC
- Veteran
- Posts: 7896
- Joined: Fri Aug 29, 2014 12:45 am
- Location: used to be Saint-Petersburg, Russia
Re: I'm working on TempoVis upgrade (visibility automation)
I have a small question. Why is it useful for Links to be recognized as containers in Containers.py? I fail to see a reason for that. Containers.py was built with strict tree in mind, where there is only one path to an object. And Link breaks that, and so recognizing it as a container makes the concept inconsistent.realthunder wrote:Ding!
-
- Veteran
- Posts: 2190
- Joined: Tue Jan 03, 2017 10:55 am
Re: I'm working on TempoVis upgrade (visibility automation)
Judging from your usage of Container.isContainer() in TempoVis.get_all_dependent(), you are obtaining dependents excluding the containers, because you want to hide the depending object, but not the ones that contain the editing object. So if a Link links to a group that contains the editing object, and the user edits the object under the Link instead of the original group, we should hide the original group, but not the Link, hence the Link must be recognizable by isContainer().DeepSOIC wrote: ↑Fri Aug 23, 2019 1:06 amI have a small question. Why is it useful for Links to be recognized as containers in Containers.py? I fail to see a reason for that. Containers.py was built with strict tree in mind, where there is only one path to an object. And Link breaks that, and so recognizing it as a container makes the concept inconsistent.realthunder wrote:Ding!
To counter the difficulty of object path uncertainty caused by Link, Gui.Document.setEdit() will deduce the object path based on the current selection (e.g. selected due to the double click action). That is why I added a 'subname' parameter to get_all_dependent(). This 'subname' gives an unambiguous path leading to the editing object, any container (including Link) along this path should not be hidden. That's basically what my modified code does.
- DeepSOIC
- Veteran
- Posts: 7896
- Joined: Fri Aug 29, 2014 12:45 am
- Location: used to be Saint-Petersburg, Russia
Re: I'm working on TempoVis upgrade (visibility automation)
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. Found: ContainerOf and ContainerChain look for containers in object's InList. However, a Link only has children if it's a Link to a container object. Thus, the children of the container don't have the Link listed in InList. If a Link points to the object directly, the object is not in getAllChildren of Container(Link). This leads to the code not breaking down, however, it will break down in the first case, if I for example bind an expression to the Link that refers to the object.
So I will rework that part a little bit. or maybe quite a bit... not decided yet, I'm still investigating.