FreeCADView Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003065 | PartDesign | Bug | public | 2017-06-01 23:08 | 2021-02-06 06:43 |
| Reporter | abdullah | Assigned To | |||
| Priority | high | Severity | major | Reproducibility | always |
| Status | assigned | Resolution | reopened | ||
| Product Version | 0.17 | ||||
| Target Version | 0.20 | Fixed in Version | 0.17 | ||
| Summary | 0003065: Part::checkIntersection returns false negatives preventing functioning of PDN Mirror transformation when faces just touch | ||||
| Description | Problem 1 Part::checkIntersection first uses first_bb.IsOut(second_bb) for a quick test. However, this function is known to fail in cases of touching (there is even a previous comment in the code). Mirror transformation explicitly asks that touching to be considered intersection. Therefore it is wrong to rely on this test. Problem 2 The Extrema method implemented in Part::checkIntersection fails: Case 1: When mirroring a feature that just touches, it sometimes fails because BRepExtrema_DistShapeShape returns BRepExtrema_IsVertex instead of BRepExtrema_IsInFace, so the manyfold detection mechanism fails to identify a non-manyfold case. In one example, instead of InFace it returns 4 Vertex: [0, 5.5, -2.5], [0,5.5,2.5], [1E-15, 13, -2.5], [1E-15, 13, 2.5] for Support1 and [0, 5.5, -2.5], [0,5.5,2.5], [-1E-15, 13, -2.5], [-1E-15, 13, 2.5] for Support2. I am unsure if this can be somehow reused. Case 2: When doing a multitransformation to create a part out of a quarter like here: https://forum.freecadweb.org/viewtopic.php?f=19&t=22747#p176513 The extrema method provides a separation (notable, in the order of milimeters) in operations with intersection parts. This may be a consequence of which parameters we are passing the to function. OTHER ISSUES Some related problems not directly related to the extrema method, but that seem to be related: https://forum.freecadweb.org/viewtopic.php?f=19&t=22747#p176509 | ||||
| Steps To Reproduce | EXAMPLE 1 1. Load the attached file. 2. Activate the first body 3. Select the pad and add a Mirror transformation (you can try directly the mirror, or a multi-transformation, vertical+horizontal to see the different cases) EXAMPLE 2 1. Load the attached file 2. Activate the second body 3. Select the pad and mirror or multi-transform mirror the pad | ||||
| Additional Information | https://forum.freecadweb.org/viewtopic.php?f=19&t=22747 | ||||
| Tags | Mirror transformation | ||||
| FreeCAD Information | |||||
|
|
|
|
|
@abdullah should this be resolved now that FreeCAD Pull Request 816 has been merged? |
|
|
Yes, this ticket is to be closed as fixed by that PR |
|
|
Thanks! Closed. |
|
|
The boolean check method fails in some circumnstances where the extrema method success. For example: https://forum.freecadweb.org/viewtopic.php?t=23029#p178800 The result is that "the shape does not intersect support" is generated, when the real problem is OCE/OCCT can not make a proper fusion of those valid and perfectly intersecting objects. IMO it is not ok to inform that something that clearly intersect does not. So this is a bug. The final outcome in these cases should be: no error because it does intersect, and a resulting bad solid because it is what OCC gives back. This can be solved by a three phase checking (instead of a two phase one): 1.Quick check 2. Extrema 3. If Extrema says it does not intersect (sometimes because of the non-manifold detection failure), boolean check. In case of OCC>6.9.0, this checkIntersection, as well as all the fusing in PDN should probably be upgraded to use generalFuse (same as Part boolean fragments fuse). |
|
|
How about avoiding the check altogether? I.e., mirror, then fuse, then check the result of fusion (it should remain a single solid; if it doesn't -> show the "does not intersect support" message to user). Another option is to drop the single-solid limitation altogether. Then, the check can also be removed. |
|
|
@DeepSOIC Good to hear from you :) What we have currently in master seems to work well. I am not sure if I "fixed" this, or what exactly went on (I can not remember). I have just updated the target version to 0.18 to get it out of the 0.17 roadmap, as this is no urgent matter. I do not close the ticket. I will eventually come back to this and assess it again. |
|
|
Changing ticket status from 'feedback' to 'assigned' |
|
|
This ticket has been migrated to GitHub as issue 5704. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2017-06-01 23:08 | abdullah | New Issue | |
| 2017-06-01 23:08 | abdullah | Status | new => assigned |
| 2017-06-01 23:08 | abdullah | Assigned To | => abdullah |
| 2017-06-01 23:08 | abdullah | File Added: Helix_Mirror2.fcstd | |
| 2017-06-01 23:08 | abdullah | Tag Attached: Mirror transformation | |
| 2017-06-18 03:49 | kkremitzki | Note Added: 0009441 | |
| 2017-06-19 12:49 | abdullah | Note Added: 0009454 | |
| 2017-06-19 17:12 | Kunda1 | Status | assigned => closed |
| 2017-06-19 17:12 | Kunda1 | Resolution | open => fixed |
| 2017-06-19 17:12 | Kunda1 | Fixed in Version | => 0.17 |
| 2017-06-19 17:12 | Kunda1 | Note Added: 0009459 | |
| 2017-06-25 09:36 | abdullah | Status | closed => feedback |
| 2017-06-25 09:36 | abdullah | Resolution | fixed => reopened |
| 2017-06-25 09:36 | abdullah | Note Added: 0009522 | |
| 2017-06-25 09:36 | abdullah | Note Edited: 0009522 | |
| 2017-11-20 10:08 | DeepSOIC | Note Added: 0010435 | |
| 2017-11-20 10:10 | DeepSOIC | Note Edited: 0010435 | |
| 2018-01-02 17:51 | abdullah | Target Version | 0.17 => 0.18 |
| 2018-01-02 17:56 | abdullah | Note Added: 0010674 | |
| 2019-02-23 20:30 | wmayer | Target Version | 0.18 => 0.19 |
| 2019-04-06 19:15 | Kunda1 | Assigned To | abdullah => |
| 2019-04-06 19:15 | Kunda1 | Status | feedback => assigned |
| 2019-04-06 19:15 | Kunda1 | Note Added: 0013009 | |
| 2021-02-06 06:43 | abdullah | Target Version | => 0.20 |
