Willy, The use of hash codes in the Topology module *is* the essential difference.
Regarding your sample at the end of the message, the result is not a surprise: the t.vertices() returns an iterator over the shape topology. When moving the vertex, you just move a copy of this vertex. But you also have to tell the TopoDS_Shape that it has to take the new coords into account. In your sample, when moving the vertex, you actually don't modify the shape, so the second time you iterate the vertices, you get the same results. I remember we already discussed that topic with Jelle: if one move a vertex, how could we update the underlying topology? This question is not simple, since when moving one vertex, you may modify the topology: for instance, if you move one vertex from a cylinder shape, the resulting shape is not a cylinder anymore. I know it is doable in the SpaceClaim CAD software: you load any topology (from a STEP file for instance), and then you just drag edges/vertices while the kernel ensures the shape consistency. Jelle started to implement something in this way: the Topology module provides a edges_from_vertex(self, vertex) method that returns edges connected to a vertex. But I don't know which algorithm should be performed over resulting edges. Best Regards, Thomas 2010/2/25 Willy Hertz <willy.he...@yahoo.com> > Hi Thomas, > > thank you very much for the quick answer and for the simple solution. > > (I studied the Topo._loop_topo() method, and I can't see why their use of > TopExp_Explorer succeeds while mine fails. I don't see an essential > difference except they use hash codes to get unique result sets. > Strangely, in my example code after the first call v[0]=ex.Current(), v[0] > is not Null. But after ex.Next() and v[1]=ex.Current(), both v[0]==v[1] and > v0.IsNull() is True. Whatsoever, the Topology package solved this problem) > > Next I want to implement possibilities to clean data stored in a large > wireframe of Edges, or in a Compound of Faces. > I need to relocate single vertices so that the Edges follow the movement of > the vertices. (A more complicated case would involve to relocate edges or > faces of a compound so that neighbouring elements follow the movement > without changing the topology. Of course this is not always possible, so > lets discuss the simple movement of edges connected to one vertex in a > wireframe.) > I cannot use a mesh structure, because it does not preserve the topology of > solids, faces and edges which make our parts. > > Making use of your Topology.Topo class I have modified my previous example. > I get the coordinates of the two vertices correctly, translate them, and get > them a second time from the original edge. Unfortunately they are the same > before and after the translation: > > before: > (0.0, 0.0, 0.0) > (0.0, 0.0, 1.0) > after: > (0.0, 0.0, 0.0) > (0.0, 0.0, 1.0) > > Apparently the translation only operates on a copy of the edge vertices, so > that the edge itself is not modified. > I know this has been discussed before, and the only solution I have found > is to delete the edge and create a new edge with the modified vertices. But > this is infeasible if you are working on a large structure, where the edges > and faces may be connected to hundreds of other elements. > > Has someone recently found a method to modify the vertices used by the > Shape structure? I can't imagine this is such a difficult problem, or is the > reason the way how smart pointers are handled in pythonOCC/Swig? Is it > easier to translate vertices using OpenCascade directly instead of > pythonOCC? > > I attach the new code snippet and hope you have another simple explanation. > Did I mention how much I appreciate this project and the support on this > list? It is outstanding :) > > Willy > > from OCC.BRepBuilderAPI import * > from OCC.TopoDS import * > from OCC.TopAbs import * > from OCC.TopExp import * > from OCC.TopLoc import * > from OCC.gp import * > from OCC import BRep > > from OCC.Utils.Topology import Topo > > e=BRepBuilderAPI_MakeEdge(gp_Pnt(0,0,0),gp_Pnt(0,0,1)).Edge(); > t = Topo(e) > > trsf=gp_Trsf() > trsf.SetTranslation(gp_Vec(0,0,-1)) > > bt=BRep.BRep_Tool() > > print "before:" > for vertex in t.vertices(): > print bt.Pnt(vertex).Coord() > vertex.Move(TopLoc_Location(trsf)) #translating every vertex, as example > > print "after:" > for vertex in t.vertices(): > print bt.Pnt(vertex).Coord() > > #why are these the same as before?? > > > ________________________________ > From: Thomas Paviot <tpav...@gmail.com> > To: pythonOCC users mailing list. <pythonocc-users@gna.org> > Sent: Thu, February 25, 2010 12:46:54 PM > Subject: Re: [Pythonocc-users] retrieve vertices of an edge > > > 2010/2/25 Thomas Paviot <tpav...@gmail.com> > > 2010/2/25 Willy Hertz <willy.he...@yahoo.com> > > > > > >>> > >>The conversion between TopoDS_Shapes, Vertices and Coordinates is driving > me crazy. > >>My goal is to find the vertex coordinates of any displayed object. I > found a few similar questions here and in the opencascade forums, but the > replies seem not to work with pythonOCC. I am trying the following > procedure: > >>>> > >>1) extract all vertices with TopExp_Explorer > >>2) convert each TopoDS_Shape into a Vertex > >>3) get the coordinates using OCC.BRep.Brep_Tool.Pnt(vertex) ... not > discussed in this post > >> > >>Please have a look at the following code, which creates an Edge and > attempts to extract the vertices. > >>>> > >>Unfortunately in step 1) three shapes with ShapeType=Vertex are returned, > the first two being identical and pointing to Null. Why? > >> > > > > > >Hi Willy, > > > > > >This point has already been discussed on this ml (I don't have the > reference to the discussion, will find it). > > > > > >Jelle implemented a topology traversing algorithm on top of the built-in > TopExp_Explorer class. I sugest you use it. It can be done very simply: > > > > > >from OCC.Topology import topo > >t = Topo(my_TopoDS_Shape) > > > > > >Then you can iterate to ver shapes, vertices, edges etc: > > > > > >for vertex in t.vertices(): > > ...do_whatever_you_want > > > > > >Have a look at the source code of the Topo class ( > http://code.google.com/p/pythonocc/source/browse/trunk/src/addons/Utils/Topology.py) > and/or the documentation (http://www.pythonocc.org/APIREF/index.html). > > > > > >Best Regards, > > > > > >Thomas > > > >In step 2) the method TopoDS.Vertex(vs[2]), applied to the > >> third shape vs[2] complains about "<type 'exceptions.RuntimeError'>: > Standard_TypeMismatch". > >> > >>How do I retrieve the Vertex coordinates of an Edge or (later) any other > Shape? > >> > >>Regards, > >>>> > >>Willy > >> > >>The code example: > >>from OCC.BRepBuilderAPI import * > >>from OCC.TopoDS import * > >>from OCC.TopAbs import * > >>from OCC.TopExp import * > >>from OCC.gp import * > >> > >>e=BRepBuilderAPI_MakeEdge(gp_Pnt(0,0,0),gp_Pnt(0,0,1)).Edge(); > >>>> > >>exp=TopExp_Explorer() > >>exp.Init(e,TopAbs_VERTEX) > >>vs=[exp.Current()] > >>exp.Next() > >>vs=vs+[exp.Current()] > >>exp.Next() > >>vs=vs+[exp.Current()] #strangely 3 vertices are found > >> > >>print 'identical:' > >>>>print vs[0]==vs[1] #True > >>>>print vs[1]==vs[2] #False > >>print 'IsNull:' > >>print vs[0].IsNull() #True > >>print vs[1].IsNull() #True > >>print vs[2].IsNull() #False > >> > >>tds=TopoDS() > >>vx=tds.Vertex(vs[2]) #ERROR: <type 'exceptions.RuntimeError'>: > Standard_TypeMismatch > >>>> > >>print vx > >> > >> > >> > > My previous message was not very clear. Here is a small sample to > illustrate it: a box is created, all vertices are then obtained from the > Topo class (8 vertices) and converted to a gp_Pnt. Finally, the X,Y an Z > coordinates are displayed: > > ############## Python Code ################## > from OCC.BRepPrimAPI import * > from OCC.Utils.Topology import * > from OCC.BRep import * > > # Create shape > my_shape = BRepPrimAPI_MakeBox(10,20,30).Shape() > > # Traverse topology > t = Topo(my_shape) > for vertex in t.vertices(): > pnt = BRep_Tool().Pnt(vertex) > print 'X',pnt.X(),'Y',pnt.Y(),'Z',pnt.Z() > ############# End of python code ################ > > And here is the ouput: > X 0.0 Y 0.0 Z 30.0 > X 0.0 Y 0.0 Z 0.0 > X 0.0 Y 20.0 Z 30.0 > X 0.0 Y 20.0 Z 0.0 > X 10.0 Y 0.0 Z 30.0 > X 10.0 Y 0.0 Z 0.0 > X 10.0 Y 20.0 Z 30.0 > X 10.0 Y 20.0 Z 0.0 > > > > > > _______________________________________________ > Pythonocc-users mailing list > Pythonocc-users@gna.org > https://mail.gna.org/listinfo/pythonocc-users >
_______________________________________________ Pythonocc-users mailing list Pythonocc-users@gna.org https://mail.gna.org/listinfo/pythonocc-users
