Edges and faces names
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
Edges and faces names
Hi all,
After creating a fillet, edges and faces names have changed (Part or Part Design module). The same happens with the chamfer, pad and pocket.
The names of the existing edges and faces should remain the same or I am wrong somewhere.
Where names are determined for edges and faces, in the openCASCADE or FreeCAD?
I need names to be always the same as in other CAD packages. Is there a solution?
Thanks
After creating a fillet, edges and faces names have changed (Part or Part Design module). The same happens with the chamfer, pad and pocket.
The names of the existing edges and faces should remain the same or I am wrong somewhere.
Where names are determined for edges and faces, in the openCASCADE or FreeCAD?
I need names to be always the same as in other CAD packages. Is there a solution?
Thanks
Re: Edges and faces names
Indeed in many operations in freecad, a complete new shape is rebuilt, and the opencascade engine often rearranges stuff inside. As a general rule, the way opencascade works, you should never rely too much on consistency in underlying shape components. Edges can be reordered, inverted, or even sometimes change type (line to bspline, etc). That's how opencascade works, and there is little we can do about it.
But, depending on what you try to achieve, there are several ways to deal with that, such as comparing edges before and after the operation (they have hashcode and also a couple of python methods to compare geometry, etc...). Why do you need this?
But, depending on what you try to achieve, there are several ways to deal with that, such as comparing edges before and after the operation (they have hashcode and also a couple of python methods to compare geometry, etc...). Why do you need this?
Re: Edges and faces names
This appears to be a big problem, see the following example:yorikvanhavre wrote:Indeed in many operations in freecad, a complete new shape is rebuilt, and the opencascade engine often rearranges stuff inside. As a general rule, the way opencascade works, you should never rely too much on consistency in underlying shape components. Edges can be reordered, inverted, or even sometimes change type (line to bspline, etc). That's how opencascade works, and there is little we can do about it.
Can you show me where I can find more about hashcode?yorikvanhavre wrote:But, depending on what you try to achieve, there are several ways to deal with that, such as comparing edges before and after the operation (they have hashcode and also a couple of python methods to compare geometry, etc...).
Do other topological data types (Compound, Composolid, Solid, Shell, Face, Wire, Edge, Vertex, Shape) also have a hashcode?
I want to use existing geometry to create a model. Pad (Extrude) with direction that determines the edge, Pad (Extrude) to vertex, edge or face/surface, Sweep with path that determines Sketch, etc.yorikvanhavre wrote: Why do you need this?
Re: Edges and faces names
Comparing complex python objects by its hash not work it that case. As far as I rember the default method for __hash__ is to fall back to 'id' which will be to the adrress of the object in memory.ivanzero wrote:Can you show me where I can find more about hashcode?yorikvanhavre wrote:But, depending on what you try to achieve, there are several ways to deal with that, such as comparing edges before and after the operation (they have hashcode and also a couple of python methods to compare geometry, etc...).
Do other topological data types (Compound, Composolid, Solid, Shell, Face, Wire, Edge, Vertex, Shape) also have a hashcode?
I tried evalutating the Shape Atrribute of Part.Box. It allways returned a different hash.
Code: Select all
>>> hash(App.ActiveDocument.Box.Shape)
155057612
>>> hash(App.ActiveDocument.Box.Shape)
159524244
>>> hash(App.ActiveDocument.Box.Shape)
159524284
>>> hash(App.ActiveDocument.Box.Shape)
159524404
>>> sh1=App.ActiveDocument.Box.Shape; id(s1) == hash(s1)
True
>>> App.ActiveDocument.Box.Shape == App.ActiveDocument.Box.Shape
False
So hashing the BRep textual representation, would help in my example case. But not for your case where the order of elements in the BRep has changed.
EDIT:
the isSame looks good:
Code: Select all
>>> App.ActiveDocument.Box.Shape.Edges[0].isSame(App.ActiveDocument.Box.Shape.Edges[0])
True
Re: Edges and faces names
all Part shapes have a hashCode() and an isSame() method. The hashCode method computes a hash code based on subelements, and is always the same. I used it in several parts of the Draft module to identify elements. It is the best way to identify an edge in a list.
But in ivanzero's case, it won't work because the pad is a different object than the underlying sketch. So their edges, even if they are at the same place, are not the same object and won't have the same hashCode.
The isSame method also won't help because it returns True only if both compared objects are based on the same geom, which is not the case either... I think you would need to setup a way to compare edges for example by their endpoints, something like this:
But in ivanzero's case, it won't work because the pad is a different object than the underlying sketch. So their edges, even if they are at the same place, are not the same object and won't have the same hashCode.
The isSame method also won't help because it returns True only if both compared objects are based on the same geom, which is not the case either... I think you would need to setup a way to compare edges for example by their endpoints, something like this:
Code: Select all
def find(anEdge,inObject):
for e in inObject.Edges:
if e.Vertexes[0].Point == anEdge.Vertexes[0].Point:
if e.Vertexes[-1].Point == anEdge.Vertexes[-1].Point:
return inObject.Edges.index(e) # we return the index of the edge in the edges list
return None
Re: Edges and faces names
yorikvanhavre, shoogen
Thanks for the response.
I was browsing OpenCASCADE documentation and came across an OCAF.
Quick forum search
viewtopic.php?f=8&t=344&p=2199&hilit=ocaf#p2199
viewtopic.php?f=8&t=69&p=535&hilit=ocaf#p535
No OCAF in FreeCAD.
Is there another solution?
The same problem will occur in Assembly module.
Thanks for the response.
I was browsing OpenCASCADE documentation and came across an OCAF.
Quick forum search
viewtopic.php?f=8&t=344&p=2199&hilit=ocaf#p2199
viewtopic.php?f=8&t=69&p=535&hilit=ocaf#p535
No OCAF in FreeCAD.
Is there another solution?
The same problem will occur in Assembly module.
Re: Edges and faces names
Now, this makes sense. If you align two faces in assembly module to be one on another, after you update one part of the two, the assembly will break completely.ivanzero wrote:The same problem will occur in Assembly module.
At least it is my impression.
Regards
Petar
Re: Edges and faces names
If you make bigger topological changes to a base shape in a
modeling history you will most likely break the update. Thats true for
all CAD systems. Some systems are better in guessing what to use instead if, e.g. a edge
disapear. But changing the foundation after the house is build will never work...
Our naming service is located in the App level of FreeCAD and the document and all links in
the document work with it. E.g. the stuff you see in the selection hints on preselection show the
linkage information. Its something like "Unnamed.Box1.Edge1". Thats the way you can reference all stuff
in the document. But if you get things out of the document into python objects like TopoShape objects
wont work reliably. The Naming in OCAF also work only in the document space.
modeling history you will most likely break the update. Thats true for
all CAD systems. Some systems are better in guessing what to use instead if, e.g. a edge
disapear. But changing the foundation after the house is build will never work...
Our naming service is located in the App level of FreeCAD and the document and all links in
the document work with it. E.g. the stuff you see in the selection hints on preselection show the
linkage information. Its something like "Unnamed.Box1.Edge1". Thats the way you can reference all stuff
in the document. But if you get things out of the document into python objects like TopoShape objects
wont work reliably. The Naming in OCAF also work only in the document space.
Stop whining - start coding!
Re: Edges and faces names
I agree, but you will get feedback what is wrong. E.g. SolidWorks will report an error and will require from user to select a new edge to fillet, and there is no guesswork.jriegel wrote:If you make bigger topological changes to a base shape in a modeling history you will most likely break the update. Thats true for all CAD systems. Some systems are better in guessing what to use instead if, e.g. a edge disapear.
So FreeCAD defined names.jriegel wrote:Our naming service is located in the App level of FreeCAD and the document and all links in the document work with it.
In the same way I got the names that I used to draw both examples, but can not understand this:jriegel wrote:E.g. the stuff you see in the selection hints on preselection show the linkage information. Its something like "Unnamed.Box1.Edge1". Thats the way you can reference all stuff in the document.
Both examples I've done manually with Skecher and Part Design - no python scripts.jriegel wrote:But if you get things out of the document into python objects like TopoShape objects wont work reliably.
If I understand well, every time when TopoShape is added to document object, which was created from geometric primitives, new names are assigned to the edges and faces. Am I wrong?
Re: Edges and faces names
If you want to identify edeges by their position/orientaion have a look on http://www.thingiverse.com/thing:13655 esp. def filterZEdges.
I think also danfalk posted interessting code on pastebin which, could help to find the right edges in your geometry.
This would break parametric history unless you decide to make paramtric Python feature for it.
And what does change when using python. I thought that the Shapes BREP is contained in the python obect. And that a calculated Shape (by itsself) has no dependecies in the document, as all EDGES an VERTICES are included.
I think also danfalk posted interessting code on pastebin which, could help to find the right edges in your geometry.
This would break parametric history unless you decide to make paramtric Python feature for it.
Are there any rules employes for the naming, other than enumerating acording to the order in the underlying brep?jriegel wrote:Our naming service is located in the App level of FreeCAD and the document and all links in the document work with it.
But if you get things out of the document into python objects like TopoShape objects wont work reliably.
And what does change when using python. I thought that the Shapes BREP is contained in the python obect. And that a calculated Shape (by itsself) has no dependecies in the document, as all EDGES an VERTICES are included.