FreeCAD|
|
|
|
|
bumped thread |
|
|
Still an issue in master. OS: Ubuntu 14.04.5 LTS Word size of OS: 64-bit Word size of FreeCAD: 64-bit Version: 0.17.9822 (Git) Build type: None Branch: master Hash: 0df4af4ba5e6edce825af6ecf6d024c704292633 Python version: 2.7.6 Qt version: 4.8.6 Coin version: 4.0.0a OCC version: 6.8.0.oce-0.17 |
|
|
Adding screenshot from forum thread IMG_0041.JPG (24,420 bytes) |
|
|
@kunda1 @abdullah Checking if I can trigger myself, so that I have an unread email in my account. I can not "unread" forum posts and now I am at two other issues simultaneously. https://forum.freecadweb.org/viewtopic.php?p=176804#p176804 Ref ticket:issue 0002508 Abdullah wrote: ping Is this a PDN blocker? |
|
|
This isn't a bug, not even an issue. The documentation statesThis means that if one is doing a loft between two squares, the maximum twist possible is <45°.F2 is twisted 45° so the twist of the loft is expected. |
|
|
It cannot be a PDN blocker since this bug was wrongly reported to PartDesign instead of Part. This is about the Part Loft tool, but admittedly it may affect the PDN additive/subtractive loft feature as well. @all the link to the page that mentions it: https://www.freecadweb.org/wiki/Part_Loft_Technical_Details (@DeepSOIC wrote that page) Should this be indicated as an upstream OCC issue then? |
|
|
@normandc It is misquoted that I asked whether it is a PDN blocker. I just pasted the text from an email where I was asked whether it is a PDN blocker. That clarified. It is as a PDN blocker as it is a Part blocker, i.e. the same issue happens in PDN. DeepSOIC did a great job explaining what is under the hood when creating a Loft. It is not uncommon to get lack of correspondence of the profiles (which honestly it is not the best explanation ever in a pop up). It is not uncommon to have a flipped profile path like above. I am not sure that profile is overtwisted (as per documentation). I would tend to think that if the one half of the arc was possible, the other half should be possible as well. What I understand from the documentation is that if the twist would me more than 45º, the selection of correspondance would change so as to minimize the twist. We best ask the master (ping @DeepSOIC), but I would tend to think that it is a bug and I am not so sure it is on the OCC side (I am somewhere 50-50 it is our bug). However, I did not try to fix it. Though I might try if I keep having this kind of awful flipping in my designs (it gets even worse with a subtractive loft feature, the poor thing does not know what to remove and what to leave)... |
|
|
@DeepSOIC ping |
|
|
sorry guys, I don't have an answer, and I don't want to dive into this problem at the moment. |
|
|
|
|
|
I looked through the FreeCAD code and nothing jumped out at me - I stopped looking when I started seeing calls to BRepOffsetAPI_ThruSections (which I assume is OCC code). Anyway, I'm siding with abdullah - I think it's a bug, and it might be an OCC bug. The reason is because I've encountered this edge flipping effect between profiles which had a twist substantially less than 45 degrees. At first, I thought I was doing something wrong, but I could see no immediate difference between the lofts with the flipped edges and those which generated correctly. In my case, I created a profile in a sketch and simply reproduced it several hundred times along a wire, orienting each duplicate normal to the wire at whatever interval it was placed. When I saw an edge flip between profiles, I decreased the profile interval and, not surprisingly, the issue went away. It doesn't happen a lot, but it does happen, and without any apparent consistency. The attached file shows a very long wire with a loft consisting of hundreds of profiles. If you move along it, you will see multiple examples of what I'm referring to - in one case, the rotation between the profiles is about 3 degrees on the z-axis. I'm siding with abdullah - I think it's a bug, but I don't see anything in the FreeCAD code that makes me think it's our bug. I stopped looking when I saw BRepOffsetAPI_ThruSections, which I presume is an OCC library call... |
|
|
I think that at least in the first file (Loft_6) it works as expected - it gets Edge1, Edge2, Edge3, Edge4 from F5 and connects them to coresponding Edge1, Edge2, Edge3, Edge4 from F6. Classic TopoNaming problem with Sketch edge names. SketchEdgeOrder.jpg (77,859 bytes) |
|
|
This ticket has been migrated to GitHub as issue 5650. |
- Anonymous
