View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002677||Part||[FreeCAD] Feature||public||2016-08-19 06:24||2018-10-22 20:42|
|Product Version||[FreeCAD] 0.17|
|Target Version||[FreeCAD] 0.18||Fixed in Version|
|Summary||0002677: Extend TopoShape API with topology traversing functionality|
|Description||Currently TopoShape API allows access to all subshapes, e.g. Faces, Edges etc. It does however not allow to access those subshapes in any topological order or relation. Example of those could be:|
- Get all faces adjecent to certain edge/vertex/face
- Get face connected to a face by this edge
- Get all Edges connected to a certain Vertices
- Iterate Edges in Wire in correct order and orientation
- many more
A clever API must be designed to allow a flexible querying of topological relation without providing an overhelming amount of functions.
This functionality would make scripting in FreeCAD much easier, as currently much repetitive work needs to be done to find topological related subshapes in python.
|Tags||No tags attached.|
||Is it realistic to set target for 0.17 on this issue?|
I agree that this sort of topological relationship information is needed. I question whether or not it belongs in FreeCAD though -> should this type of functionality come directly from OpenCascade? I would think that the CAD kernel itself, being that it manages the Topology, would have this information more readily available.
Any solution we come up with will likely be mostly a hack, as OpenCascade does not make very apparent (or easily available) the mechanism by which it stores and modifies underlying topologies.
As an example, you can see here in my opencascade wrapper library that I've added a method for checking whether a particular TopoDS_Face contains a particular TopoDS_Edge. What is being suggested is essentially to continue adding these sorts of "helper methods" to FreeCAD's TopoShape class.
Personally, I believe these types of "helper methods" that help with using OpenCascade should be contained in a separate library altogether - that is the intent of the OccWrapper library I'm writing.
I hope posting this on this bug is appropriate: I've been holding off on posting much in the forums regarding this OccWrapper library because it is largely incomplete, and mostly a labor of love that's made (attempting to) resolve the topological naming problem less painful. I thought this comment would be well placed here, though, given the topic of the bug report.