View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0027200 | Community | OCCT:Modeling Data | public | 2016-02-24 17:31 | 2016-08-18 15:43 |
| Reporter | nicolas_c | Assigned To | bugmaster | ||
| Priority | normal | Severity | minor | ||
| Status | closed | Resolution | not fixable | ||
| Platform | Windows | OS | VC++ 2012 | ||
| Product Version | 6.7.0 | ||||
| Target Version | Unscheduled | ||||
| Summary | 0027200: Bounding box of Surfaces | ||||
| Description | The bounding box of the attached surface is larger than expected (648m >> 0.018m). | ||||
| Steps To Reproduce | Import exp.igs and compute bounding box with BRepBndLib::Add(shape, box); then sqrt(B.SquareExtent()) gives 648.5m even if the face is less than 2cm. | ||||
| Additional information and documentation updates | I was able to achieve an accurate enough result by switching from GeomAbs_BSplineSurface method using surface.Poles() to default method (UV Sampling of surface) in BndLib_AddSurface::Add(S, UMin, UMax, VMin, VMax, Tol, B). I think poles are outside of the surface in BSPlineSurface definition. So actual implementation gives wrong result | ||||
| Tags | No tags attached. | ||||
| Test case number | |||||
|
|
exp.igs (27,945 bytes) |
|
|
The method BRepBndLib::Add is known to compute box by poles of b-spline. If we computed it by UV samples we could skip some areas of a surface thus getting a box of less size than expected. It would be much worse then computing a box larger than expected. It is because the bounding box must include all points of the shape, and if it includes some extra space it is not so crucial for algorithms as when it does not include some space. By the way, this method has been improved since 6.7.0 version, and in the current version (7.0 beta) it returns mush less bounding box for the attached face, due to taking out of consideration the poles that do not take part in the piece of surface on which the face is built: in 6.7.0: Draw[9]> bounding a -486977.59931860428 -17150.230749889812 973.93123226598641 127108.75830253531 87454.155837981787 181435.96443249242 in 7.0: Draw[5]> bounding a -4529.1900235495541 248.0745436809822 990.00742501574109 -4218.9689926495166 286.58002984226323 1045.7647693584593 |
|
|
OK, results are better but still far from expected result (31cm > 1.8cm). I'll try to investigate why triangulation method doesn't work. |
|
|
We cannot make the method BRepBndLib::Add compute optimal bounding box, because it would raise a lot of regressions for performance cause. However, recently we have added the new method BRepBndLib::AddOptimal, which computes optimal axis-aligned bounding box for a shape. So, this bug can be closed. |
|
|
The class BndLib_AddSurface also acquired the new methods AddOptimal. |
|
|
Dear bugmaster, please close this bug. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-02-24 17:31 | nicolas_c | New Issue | |
| 2016-02-24 17:31 | nicolas_c | Assigned To | => msv |
| 2016-02-24 17:31 | nicolas_c | File Added: exp.igs | |
| 2016-02-24 18:19 |
|
Note Added: 0051089 | |
| 2016-02-24 18:25 |
|
Relationship added | related to 0025631 |
| 2016-02-24 18:27 |
|
Assigned To | msv => nicolas_c |
| 2016-02-24 18:27 |
|
Status | new => feedback |
| 2016-02-24 18:27 |
|
Target Version | => Unscheduled |
| 2016-02-24 18:47 | nicolas_c | Note Added: 0051090 | |
| 2016-03-16 11:37 | nicolas_c | Assigned To | nicolas_c => msv |
| 2016-08-18 09:17 |
|
Note Added: 0056813 | |
| 2016-08-18 09:20 |
|
Note Added: 0056814 | |
| 2016-08-18 09:21 |
|
Note Added: 0056815 | |
| 2016-08-18 09:21 |
|
Assigned To | msv => bugmaster |
| 2016-08-18 09:21 |
|
Resolution | open => not fixable |
| 2016-08-18 15:43 | bugmaster | Status | feedback => closed |
