"Robust references"

[jrheinlaender]

so what do I mean with a "robust reference"?

A reference is a vertex, edge or face of a shape used by another feature (e.g. the edge of a prism used by a chamfer)

By robust I mean that the reference survives modifications of the shape it belongs too.

Currently as far as I can see references in FC are handled only by the index in the list of shapes. This works almost always, but sometimes rebuilding a shape changes the order of the list, and then the reference fails.

Why does it bother me? Because I used to work with ProE, and we often nicknamed it Pro/Alzheimer because it loved to "forget" references. That's really annoying, especially if you have a part that forgets a reference every time it regenerates!

So I have been studying what OCC has to offer, and it seems that "topological naming" (TNaming_* classes) can do this. It is possible to name all sub-shapes of a shape in such a way that you can follow the evolution of a shape from the time it is generated (e.g. a face generated by creating a prism) right through all operations (cuts, fuses, etc.) done on it.

But before I spend more time trying to understand the somewhat elusive documentation of OCC, I thought I would ask if anyone else already has experience with topological naming. Or maybe someone knows of a better alternative? Or maybe you think I am being to fussy about the "robustness" of references?

Jan

[wmayer]

So I have been studying what OCC has to offer, and it seems that "topological naming" (TNaming_* classes) can do this. It is possible to name all sub-shapes of a shape in such a way that you can follow the evolution of a shape from the time it is generated (e.g. a face generated by creating a prism) right through all operations (cuts, fuses, etc.) done on it.

I don't think that the TNaming classes contain any logic to get the modifications on a shape because this must happen on the low-level algorithms where the shapes are changed. The TNaming presumably only stores these information in a certain way.

Recently, I have worked exactly on that where Petar Perisin wanted to keep the colors he assigned to the faces of a part shape after applying boolean operations. The trick is actually only to query from the used algorithm which output sub-shape is associated to a given input sub-shape. I implemented this for the faces for the boolean operation algorithms and the refinement algorithm.

Just have a look to the method Feature::buildHistory() and how it is used e.g. in Boolean::execute().

And today I talked with Jürgen exactly on this too where we came to the conclusion to make a proper interface in our TopShape class for this.

[logari81]

it will be really great if this weak point of FreeCAD is fixed.

[jrheinlaender]

I don't think that the TNaming classes contain any logic to get the modifications on a shape because this must happen on the low-level algorithms where the shapes are changed. The TNaming presumably only stores these information in a certain way.

yes, I was a bit short in my explanation. You still have to make sure to update the naming every time you modify a shape, which seems to be quite a hassle. So if you have already created code for this then I guess it doesn't really matter whether we use TNaming or FC-specific data structures. (In which branch is buildHistory()? Or do I need to update my branch?)

My idea was that for example a Pad feature referencing a face should be linked to the vertex or edge in the Sketch which ultimately created this face. So that if the user deletes this edge in the sketch, he will get a warning that the Pad will lose its reference.

[wmayer]

yes, I was a bit short in my explanation. You still have to make sure to update the naming every time you modify a shape, which seems to be quite a hassle. So if you have already created code for this then I guess it doesn't really matter whether we use TNaming or FC-specific data structures. (In which branch is buildHistory()? Or do I need to update my branch?)

It's in the master branch. For testing I had my own branch and merged it later into master.

[jriegel]

Yes, the naming is a weak point at the moment. But have no fear!

The interface is already there, its in Part::Toposhape class. This class has the naming interface which translate a sub Shape (e.g. Face or Edge) to its name (e.g. "Face1").
the Link property uses the string name of the sub-element.
At the moment its the trivial implementation about the ordering, which breaks if you change the number of faces or edges...

Werne is on the right path. To allow better naming of sub elements we need the examine in the features or the in the Part::TopoShape which face stays the same and which ones
are added. Then the naming has to be adjusted to break as less links as possible.

So if its become a problem there is a place and a way to do it.

[ivanzero]

Hi all,
A few months ago I posed a question about names of the edges and faces.

viewtopic.php?f=10&t=2267

Based on what wrote jriegel this problem will be solved?

I am interested in whether there will be one or more solid object as it is now (hidden parent solid object - a child solid object is shown)?

Will the edges, faces and sketch objects have a ID / hash, with whom I will be able to ordain these objects unambiguouslу?

Regards
Ivan

[jrheinlaender]

Concerning Feature::buildHistory()

Code: Select all

It's in the master branch. 

I completely lost my way with git. What I tried was this (from another thread):

git checkout master
git pull --> the changed Feature.* came in
git checkout jrheinlaender/PartDesign
git rebase master --> At this point I hit some conflcts, which I resolved as suggested by git. That is, I edited the files, chose the code to keep and deleted the rest, including the markers git puts in the text between the blocks. Then I did git add <filename> and git rebase --continue

When the rebase finished, git status told me that I was both ahead and behind my remote! So I did git push and pull to resolve that. This is where I got confused and can't remember properly what I did, but you can look at the commit history on github and see the result. All my earlier commits appeared again (twice because I repeated the rebase procedure because in my branch I still had the old Feature.*)

And now I don't have the new Feature.* in my master branch, either!!! How can that be? git pull claims everything is up-to-date.

Any help will be appreciated...
Jan

[shoogen]

at first id advide you to branch, do save the current state. To me it seems that going back with "git reset --hard c303b2a71282d8" might solve this.
I don't now what you mean be 'my remote'. you should probalbly allways branch before you rebase. Otherweise you need use '--force' to push the results of rebasing.

Code: Select all

git fetch
git checkout master
git merge origin/master
git checkout yourbranch
git branch newbranch
git checkout newbranch
git rebase master

There are probably some shortcuts to this notation, but it should work this way

[jrheinlaender]

Since wmayer has had the same problems rebasing my branch, I decided to delete everything and start over. Here is what I did, please tell me if there is something wrong with my setup!!!

Starting point is a clone of the SF freecad repository in the local directory freecad, and a github repository forked from yorikvanhavre/FreeCAD called jrheinlaender/FreeCAD.

I changed into the freecad directory and did:

git pull
git branch jrheinlaender/PartDesign
git remote add github git@github.com:jrheinlaender/FreeCAD.git
git push github -> says everything is up-to-date
git checkout jrheinlaender/PartDesign
git push -u github jrheinlaender/PartDesign

Now I will re-created all my changes in the branch, committed them and pushed them to github.