Thank you that you examined my idea.lambda wrote: ↑Mon Oct 30, 2017 9:11 pmThis is a nice heuristic, which might give good results if combined with other heuristics. There are two downsides though:
1) I think many parts have to many symmetries, where vertices just don't get a unique value. Maybe you can provide a macro that does the calculation, so we can run it on our modells and see how far we get?
When you extend the model by the middle of the faces (center of mass) then the holes are different, here the script to extent the model:2) Often not all vertices of a part are connected with edges: Think of a wall with three holes (windows) - the vertices of each window are isolated from the rest. If each hole has the same geometry, then all three holes will end up with vertices with the same value (although the middle window is different from the outer window), as you can not relate the vertices to others with your method.
Code: Select all
import random ff=0.001 def rf(v): return v+ FreeCAD.Vector(ff*random.random(),ff*random.random(),ff*random.random()) # the box with some holes a=App.ActiveDocument.Pocket fs=a.Shape.Faces pts= col= for f in fs: c=f.CenterOfMass pts.append(c) for v in f.Vertexes: p=v.Point pts.append(p) col.append(Part.makeLine(rf(c),rf(p))) import Points Points.show(Points.Points(pts)) Part.show(Part.Compound(col)) # dieses shape fuer die analyse nutzen Gui.Selection.clearSelection() Gui.Selection.addSelection(App.ActiveDocument.ActiveObject) import nurbswb.analyse_topology_v2 reload(nurbswb.analyse_topology_v2)
this is a nice to use information but will not work if the Part or some subparts are scaledshaise wrote: ↑Wed Nov 01, 2017 6:16 amI guess, the motivation behind the topological naming is to prevent braking of a model when doing changes up the tree.
If this is the reason, I suggest a simpler to implement method, perhaps not as good as a full blown topological naming, but good enough to solve many cases:
Leave the naming as today with simple numbering. simple transformations like rotate and translate will not affect it.
When ever there is a topological changing operation, in most cases pockets, pads and other booleans:
1. each vertex that occupies the same location as a vertex in the previous stage will have the same number.
You are right, the next step after identification of the vertexes is simpler.2. each edge that have the same 2 vertices as before will have the same number. all others new numbers.
3. each face that shares at least 3 vertices as before will have the same number. (in this case it can be ambiguous if a face is being split, in this case select one randomly and give it the same number. this way if a sketch was attached to it, it will at least stay in the same plane)
I admit there are lots of cases it will not work, but it is easy to implement and much better then randomly numbering objects as today.
Even if the numbering comes from OCC, shaise's idea could result in an an improvement in many cases:
In this case the keys for middlepoints of 4 faces change but the keys for the corners and the middlepoint of the top and bottom stay.
Indeed this is a big issue, as it is common to change heights of pads/pockets. But perhaps in theses cases we can take the original OCC numberings, as in cases where the shape does not change topologically (but rather only change some dimensions) the numbering stays consistent.