Wed, 05/18/2022 - 11:57
Forums:
Hello Team,
There is some function of TopoDS_Shape - HashCode(...).
It returns various values for the same gemetry from run to run.
Is there any function to get some hash id which depends on geometry and location only? To get the same id from run to run.
Thanks.
With respects, Eugene.
Wed, 05/18/2022 - 12:39
TopoDS_Shape::HashCode() computes a hash code for a shape pointer in memory, and is designed to be used in acceleration structures - hash maps (NCollection_Map, NCollection_DataMap, NCollection_IndexedMap, etc.), for fast lookup.
What you are looking for is probably a checksum hash like MD5 or similar, usually computed for files. I don't think that OCCT provides anything like this right now. There are some functions that try to find identical, but duplicated geometry (e.g. performing a deep comparison of geometry / topology, without tolerance), but I don't recall how this function is called.
Wed, 05/18/2022 - 13:11
If you just need to uniquely identify subshapes in a shape you can use the function TopExp::MapShapes that creates indexed map of shapes, where along with hash of shapes the second has is used on integer shape IDs, and they are stable from run to run.
Another point. If your algorithm behaviour depends on iteration on some map of shapes you can replace usage of MapOfShape (or DataMapOfShapeSomething) with IndexedMapOfShape (or IndexedDataMapOfShapeSomething). In this case, iterations will perform depending again on shape ID (order in which a shape is hit into the map rather than order of shape in memory).
Thu, 05/19/2022 - 08:19
Thank you, Mikhail and Kirill!
With respects, Eugene.
Thu, 05/19/2022 - 12:24
And in case serialization by BinTools_ShapeSet input/output the IndexedMapOfShape will keep the same order?
Thu, 05/19/2022 - 14:14
Indexed maps (NCollection_IndexedMap, NCollection_IndexedDataMap) preserve order in which elements have been added (unlike unordered maps like NCollection_Map and NCollection_DataMap, which order would depend on memory layout). TopoDS_Shape stores sub-shapes in a list TopoDS_ListOfShape (NCollection_List) and BinTools_ShapeSet is expected to store and restore shapes with the same order of children.
Particular algorithms, however, might construct shapes in different order, when the order has no strict meaning (e.g. shapes remain valid and define exactly the same geometry, but topological order of subshapes might be different). This is something, that should be avoided (e.g., like using ordered maps instead of unordered, when applicable), but not all algorithms are deterministic in this way.
Sun, 05/22/2022 - 09:46
Thank you!
With respects, Eugene.