I'm working on TempoVis upgrade (visibility automation)

Here's the place for discussion related to coding in FreeCAD, C++ or Python. Design, interfaces and structures.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
User avatar
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)

Post by DeepSOIC »

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.
User avatar
Kunda1
Veteran
Posts: 13434
Joined: Thu Jan 05, 2017 9:03 pm

Re: I'm working on TempoVis upgrade (visibility automation)

Post by Kunda1 »

DeepSOIC wrote: Thu Aug 15, 2019 3:48 pm Just a quick announcement, that I'm upgrading TempoVis to support stack (nice behavior of concurrent instances), and better project saving behavior.
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
User avatar
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)

Post by DeepSOIC »

Kunda1 wrote: Thu Aug 15, 2019 8:41 pm How does it integrate with the App::Link code?
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 :?
User avatar
Kunda1
Veteran
Posts: 13434
Joined: Thu Jan 05, 2017 9:03 pm

Re: I'm working on TempoVis upgrade (visibility automation)

Post by Kunda1 »

bummer. please stay motivated! :D
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
realthunder
Veteran
Posts: 2190
Joined: Tue Jan 03, 2017 10:55 am

Re: I'm working on TempoVis upgrade (visibility automation)

Post by realthunder »

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.
Try Assembly3 with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
User avatar
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)

Post by DeepSOIC »

realthunder wrote: Fri Aug 16, 2019 1:11 pm Here is a summary of my modification:
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.

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.
I would have probably patched PartDesign instead, but I'll take a look.
realthunder
Veteran
Posts: 2190
Joined: Tue Jan 03, 2017 10:55 am

Re: I'm working on TempoVis upgrade (visibility automation)

Post by realthunder »

DeepSOIC wrote: Fri Aug 16, 2019 1:55 pm I would have probably patched PartDesign instead, but I'll take a look.
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
Try Assembly3 with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
User avatar
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)

Post by DeepSOIC »

realthunder wrote:Ding!
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
Veteran
Posts: 2190
Joined: Tue Jan 03, 2017 10:55 am

Re: I'm working on TempoVis upgrade (visibility automation)

Post by realthunder »

DeepSOIC wrote: Fri Aug 23, 2019 1:06 am
realthunder wrote:Ding!
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.
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().

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.
Try Assembly3 with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
User avatar
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)

Post by DeepSOIC »

realthunder wrote: Fri Aug 23, 2019 1:49 am ...
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.
Post Reply