robust references workbench

Have some feature requests, feedback, cool stuff to share, or want to know where FreeCAD is going? This is the place.
Forum rules
Be nice to others! Read the FreeCAD code of conduct!
Post Reply
lambda
Posts: 91
Joined: Sat Feb 25, 2017 3:10 pm
Contact:

robust references workbench

Post by lambda »

Hi all,

the latest flurry of threads about topological naming got me thinking: Is there any tool in FreeCAD to explore topology information? I'm thinking about something like "Scene inspector" or "Dependency Graph" but for OCC data structures ...

I guess some information can be queried from the python console, but there everything is wrapped in python objects, which AFAICT can't be used to access (or even modify) OCC data structures. There are methods like isSame, isEqual and isPartner, but they seem a bit difficult to use and in the end two python objects might point to exactly the same OCC data structure:

Code: Select all

>>> o1 = App.ActiveDocument.Box.Shape.Edges[2]
>>> o2 = App.ActiveDocument.Box.Shape.Edges[2]
>>> o1 == o2
False
I'm wondering if there could be a "robust references" module/workbench with tools for low-level access, mapping and visualization of OCC data structes. (Also people proposing alternative implementations of robust references (ie without the OCC TNaming class and history recording) could add objects implementing their proposals. Ie RRef,"Face83" would really be a robust reference to Box,"Face1".)
wmayer
Founder
Posts: 20309
Joined: Thu Feb 19, 2009 10:32 am
Contact:

Re: robust references workbench

Post by wmayer »

Hi,

there is currently no utility in FreeCAD to explore a shape and its sub-elements. I wonder if occ itself offers such a utility. Inside the Tools directory of the occ source tree there are some utilities listed: http://git.dev.opencascade.org/gitweb/? ... 57f4cdf4d3
Maybe one of them offers the needed functionalities.
lambda
Posts: 91
Joined: Sat Feb 25, 2017 3:10 pm
Contact:

Re: robust references workbench

Post by lambda »

Thanks for the information, that's very interessting.

A few preliminary results from looking at the data structures (classes) of OCC and FreeCAD:
There seems to be a big difference in how modelling data is managed. OCC tries pretty hard, to not copy data structures unless absolutely necessary (modification, where the original needs to stay arround). Instead it passes references around (at least internally) whenever possible. FreeCAD OTOH creates new instanced of it's data structures (wrappers around OCC objects) a lot, even for the same object.

An example: In OCC geometry objects (Geom_Geometry) are the base. Everything you create is/has a geometry. You can later create a topology object (TopoDS_Shape) around it, if you want to do topology operations. (You can create a topology object directly, but a default geometry is created in the background.) So a topology object always has a reference to it's geometry. -- In FreeCAD the Geometry class is a wrapper around Geom_Geometry (holds a handle) and augments it with additional properties like a tag. Also I can create a topology object (TopoShape) from it by calling the toShape() method. However since the TopoShape object is only a pure wrapper around a TopoDS_Shape object, it has no reference to the Geometry object it was created from. Instead when accessing the Curve property of an Edge object (only available in python I think), a new Geometry object is instanciated with a handle to the same Geom_Geometry object (coming from TopoDS_Shape) but a new tag.

Since links between objects and selection in the GUI are handled on the topoloy level (which makes sense, as there is (in OCC) a link from topology to geometry, but not the other way) this makes the tag mechanism (and everything else that FreeCAD adds in its geometry data structures) mostly useless, I think.

Generally I think that this habit of copying/instanciating objects in FreeCAD make the concept of identity somewhat blurry. I think many objects in FreeCAD that should share data from OCCs point of view actually contain independent copies in FreeCAD - especially after a save/load cycle unless the document is completely recomputed. Recomputing might allow OCC to fix some things or rather discard some of the extra copies. I guess that any implementation of robust references would be much easier with less copyies of the same data and I particularly suspect that any solution based on OCCs TNaming package will never work (especially across save/restore) with current data structures of FreeCAD.

Disclaimer: ATM I'm far from having studied all of FreeCADs (and OCCs *hust* *hust*) classes and I might be missing something completely. But given that the threads about robust references in this forum are almost as vast as OCCs documentation, I wanted to get input on these thought before digging much further.
Post Reply