[Open] Topological Naming code

Post here if you have re-based and finalised code to integrate into master, which was discussed, agreed to and tested in other forums. You can also submit your PR directly on github.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
jrheinlaender
Posts: 554
Joined: Sat Apr 07, 2012 2:42 am

[Open] Topological Naming code

Post by jrheinlaender »

Just thought I would mention it here so it doesn't get forgotten. I updated the naming code to work with the new PartDesign/Body structure.

https://github.com/jrheinlaender/FreeCA ... pe-tnaming

This branch is based on the https://github.com/jrheinlaender/FreeCA ... -toposhape branch.

The code currently does not do anything except build histories inside the TopoShape. To use this information, there are two sample methods at the end of TopoShapeNaming.cpp

findOriginInHistory() takes a shape subelement (e.g. a face) and returns information that can be used as a robust "name" for it
findShapesInHistory() is the inverse and takes the "name" to retrieve the shape subelement

The code is not complete (e.g. filleting, chamfer, drafts are not handled) and not 100% perfect though I have tested it and it does handle almost everything. But since currently it does not seem at all clear in which direction we are taking Topological Naming I am reluctant to invest more time into it.
User avatar
jriegel
Founder
Posts: 3369
Joined: Sun Feb 15, 2009 5:29 pm
Location: Ulm, Germany
Contact:

Re: Topological Naming code

Post by jriegel »

You right to wait a bit, and I'm still struggling to decide about the naming. Most of the papers I read are working with explicit references which keept stable through history. I FreeCAD we use at the moment a loose referencing by string names. So the Topo don't know about which subelements are referenced. That would force us to keep track on the history of all vertexes, faces and edges, which is a huge performace problem and mostly not needed. There for I tend at the moment to a switch to a explicit reference system. But unfortunately, I have no idea how to do that back-ward compatible.... So I'm still stuck in a dilemma..

But I think I will incorporate your code, it at least makes things better....
Stop whining - start coding!
User avatar
tanderson69
Veteran
Posts: 1626
Joined: Thu Feb 18, 2010 1:07 am

Re: Topological Naming code

Post by tanderson69 »

jriegel wrote:There for I tend at the moment to a switch to a explicit reference system. But unfortunately, I have no idea how to do that back-ward compatible....
Forgetting about backward compatibility for a moment, I am curious where are you going to get your explicit references from toposhape? As far as I can see, the only thing available is the hashes and they are way to volatile.
User avatar
jriegel
Founder
Posts: 3369
Joined: Sun Feb 15, 2009 5:29 pm
Location: Ulm, Germany
Contact:

Re: Topological Naming code

Post by jriegel »

Explicit naming comes with an additional data structure in Part::TopoShape. It works basically by exploring the NEW Topo (after one ore more Algorithems e.g. in a Feature) and look if the referenced faces/edges/vertexes are still there. Mostly its done by a combination of hashes and using the topological and geometrical information. Some CasCade algos even deliver a set of shapes changed/removed/created.
Stop whining - start coding!
User avatar
tanderson69
Veteran
Posts: 1626
Joined: Thu Feb 18, 2010 1:07 am

Re: Topological Naming code

Post by tanderson69 »

Hashes are not constant through serialization(I am sure you know that). One idea I had was using hashes at runtime. When saving, add all document shapes to 1 topods_compound and convert hashed links to offsets from this "master" compound. When loading, resolve offsets back to hashes. As a side benefit of this scheme, I think we would get the memory savings from the implicit sharing from OCC between sessions. There are of course other problems with hashes.

Yes some algorithms do deliver a modification list and some don't. For those that do, the info seems pretty general and so additional analysis will still need to be done.

It sounds like you are thinking the current naming scheme will serve as a component of a larger framework?

IMHO. Every avenue sounds like a hack. Long term, I think the only hope for this is to attract enough developers to either fork opencascade or start over. The identification of geometric entities has to be at the core of the modeler and not an afterthought.
jrheinlaender
Posts: 554
Joined: Sat Apr 07, 2012 2:42 am

Re: Topological Naming code

Post by jrheinlaender »

Explicit naming comes with an additional data structure in Part::TopoShape. It works basically by exploring the NEW Topo (after one ore more Algorithems e.g. in a Feature) and look if the referenced faces/edges/vertexes are still there
Which is basically what I started implementing in my branch :-)
User avatar
jriegel
Founder
Posts: 3369
Joined: Sun Feb 15, 2009 5:29 pm
Location: Ulm, Germany
Contact:

Re: Topological Naming code

Post by jriegel »

Yes Jan did already excellent work in that regard. I'm still worried about the integration in our framework.

@TANDERSON
OCC is not the problem. They have already a naming service, but tightly bundled with their document model OCAF. Its the TNaming package. I think there is a lot to learn...
Persistent and transient data structures will mostly be different. In case of topo as you mentioned, hashes a fast but not persistent.

But the real holly grail in that regard is not only naming, its also sharing. Imagine a real complex modeling (e.g. cylinder head). Every feature will dublicate the brep, but will add only little changes.
So the real tough task is to share whats not changed and only add the changes and deletions. So you can keep the memory consumption low.
Stop whining - start coding!
User avatar
tanderson69
Veteran
Posts: 1626
Joined: Thu Feb 18, 2010 1:07 am

Re: Topological Naming code

Post by tanderson69 »

jriegel wrote:OCC is not the problem. They have already a naming service, but tightly bundled with their document model OCAF. Its the TNaming package. I think there is a lot to learn...
No doubt. I have looked at the naming and document overviews. I am sure you can get something working, it just looks like an afterthought and not part of the modeling architecture. OCC is always the problem ;) . OCC is getting used because there is no alternative.
jriegel wrote:But the real holly grail in that regard is not only naming, its also sharing.
I understand what you are getting at. Don't we get sharing implicitly through the use of TopDS_Shape? But then we loose this through serialization as each feature writes out it's own brep structure?

Sorry for doing this in the pull requests forum. Feel free to shoot this thread over to the developers corner.
wmayer
Founder
Posts: 20245
Joined: Thu Feb 19, 2009 10:32 am
Contact:

Re: Topological Naming code

Post by wmayer »

They have already a naming service, but tightly bundled with their document model OCAF. Its the TNaming package.
Are there any experiences available of how good or bad this works? And is it known how they do it, also using the hash values?
User avatar
jriegel
Founder
Posts: 3369
Joined: Sun Feb 15, 2009 5:29 pm
Location: Ulm, Germany
Contact:

Re: Topological Naming code

Post by jriegel »

Yes Tanderson! Actually you quit right. The whole OCAF was done relatively late by a Matra team in Russia. It was the last leap before Matra abandoned the idea of CasCade becoming the next Euclid....
Stop whining - start coding!
Post Reply