FreeCAD|
|
cylinder.png (2,864 bytes) |
|
|
I played around with this a bit and I think there are 2 problems here. 1) As you discovered (and the commented out code indicates), Path.fromShape() does not modify the given Wire/Edges in any form. It takes each Edge as it is and translates that to a Command. In order to make a valid Path, or something you expected, the given Edges would need to be sorted /and/ re-oriented. which brings us to the harder problem here 2) If Path.fromShape starts re-ordering and re-orienting Edges, then the given example above has 8 valid resulting Paths it could generate. It has 4 possible entry points and it could process the loop CW or CCW. Obviously it gets more interesting with more complex wires. I've attached the resulting Path of a Contour of a cylinder, 5 circles and 8 lines. 2 loose ends either one can be used as a starting point ..... if I'm not mistaken there are 20 valid Paths possible .... What I'm getting at is that for any decently shaped wire the result is not predictable (and therefore of little value) iff we let Path.fromShape() modify the input wire. It's probably OK to re-orient an Edge (except for the first one) but everything else should be processed as is. The onus of placing the entry point as Vertex[0] of the first Edge in the wire and sorting the rest of the edges properly should be on the caller. There is still the question of which way to traverse a full circle though. |
|
|
@realthunder do you mind weighing in? |
|
|
My contribution is in Path.fromShapes(). For the code in Additional Information, to get the path you want |
|
|
Path.fromShape is a python implementation. It's very old and was meant to be a reference implementation to build more complex things from. I think it should be deprecated and removed. Path.fromShapes is realthunder's implementation of a similar general tool and much more powerful. The only issue I see with it is that the user can't get it into a Job so it can be postprocessed. It's a c++ implementation so I've got no clue. If someone can weigh in on how we modify fromShapes, I think this ticket can be closed pretty quick. |
|
|
@wmayer do you mind weighing in? |
|
|
@mlampert what say you in regards to 0002786:0009689 ? |
|
|
Is the result of fromShapes a valid Path object? If yes, then I suppose the problem lies within the job object itself? |
|
|
@sliptonic can you explain how path are added to jobs? Couldn't find that in the code... |
|
|
this is @mlampert's code so he knows it better than I. I believe it's done in the base class PathOp. in _setBaseAndStock() All the operations retain a reference to their job. @mlampert, can you clarify how the Job tree gets built on the GUI side? |
|
|
Job uses a Path::FeatureCompoundPython as the Operations property, and whatever gets added to that is part of the job. I've never looked at the internals of Path::Compound that code predates my involvement. |
|
|
Okay, Part.fromShapes() seems to do the job much better than the old fromShape, which could be deprecated. Indeed I see now that it is easy to add the generated object to the Group property of the Operations subobject. So I guess @sliptonic's question is solved too. I suggest then to simply change the docstring of Part.fromShape to indicate that it is deprecated? |
|
|
https://github.com/FreeCAD/FreeCAD/commit/fb8875df08146c520d8ce8cd351da624360ba5d5 |
|
|
https://github.com/FreeCAD/FreeCAD/commit/fb8875df08146c520d8ce8cd351da624360ba5d5 |
- Anonymous
