View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0032363 | Community | OCCT:Modeling Algorithms | public | 2021-05-13 10:03 | 2021-07-28 12:07 |
| Reporter | Assigned To | bugmaster | |||
| Priority | normal | Severity | major | ||
| Status | closed | Resolution | no change required | ||
| Platform | Microsoft VC++ 2019 | OS | Windows | ||
| Product Version | 7.5.1 | ||||
| Target Version | 7.6.0 | ||||
| Summary | 0032363: Modeling Algorithms - BRepBndLib::AddOBB() produces wrong results | ||||
| Description | Good morning, normally the BRepBndLib::AddOBB() function works correctly, but with some geometries, even simple ones, the generation of the OBB is heavily wrong. In the case of the example '1D$j$J000Ar34pC3WrDJSu' not only the dimensions are wrong, but also the orientation. But if the geometry is modified a bit (example '1D$nPX0000Mp4pC3WrDZGm'), the result is correct. I attach the code snippet with which I generated the attached examples. The dumpShape() function is simply a wrapper of BRepTools::Write(). For each pair of examples the first file contains the original shape while the one with the suffix '_obb' contains the shape derived from the OBB. | ||||
| Steps To Reproduce | Bnd_OBB obb; try { BRepBndLib::AddOBB(inShape, obb); if(!obb.IsVoid()) { gp_Pnt obbVtx[8]; std::string folderPath("C:\\Users\\Amedeo\\Test"), obbFileName(inProduct->GlobalId()); dumpShape(folderPath, obbFileName, inShape); obb.GetVertex(obbVtx); obbFileName.append("_obb"); gp_Ax2 axes(obbVtx[0], gp_Dir(obb.ZDirection()), gp_Dir(obb.XDirection())); BRepPrimAPI_MakeBox mb(axes, obb.XHSize()*2, obb.YHSize()*2, obb.ZHSize()*2); dumpShape(folderPath, obbFileName, mb.Solid()); } } catch(...) { } | ||||
| Tags | No tags attached. | ||||
| Test case number | |||||
|
2021-05-13 10:03 reporter |
examples.zip (10,091 bytes) |
|
|
> normally the BRepBndLib::AddOBB() function works correctly, > but with some geometries, even simple ones, > the generation of the OBB is heavily wrong. What exactly looks "heavily wrong" in produced result? OBB does not fit in the shape? If you are looking for a tight OBB, then consider using 'theIsOptimal' option BRepBndLib::AddOBB(). > In the case of the example '1D$j$J000Ar34pC3WrDJSu' not only > the dimensions are wrong, but also the orientation. Could you please elaborate what is wrong with dimensions here? I don't see any issues with produced OBB.
pload MODELING VISUALIZATION
restore {1D$j$J000Ar34pC3WrDJSu.brep} b
#bounding b -obb -shape bb
bounding b -obb -shape bb -optimal
vinit View1
vdisplay -dispMode 1 b
vdisplay -dispMode 0 bb
vfit
|
|
2021-06-15 18:16 reporter |
1D$j$J000Ar34pC3WrDJSu and OBB.pdf (29,257 bytes) |
|
|
If the criterion for determining that this function is correct is simply that the shape is included in the resulting OBB, then a normal bounding box would also be correct. It seems to me that the essence of the question is that the OBB should be precise. Anyway using the parameter 'theIsOptimal' == true does not change the result at all. I would say that the error is heavy because the OBB is not even oriented concordantly with the main plane of the shape. I'm attaching an image. |
|
|
aabb.png (3,459 bytes) |
|
|
obb_default.png (3,951 bytes) |
|
|
obb_optimal.png (3,369 bytes) |
|
|
> It seems to me that the essence of the question is that the OBB should be precise. OBB only means that Bounding Box *could* be Oriented - that is, it may be more tight than AABB if construction algorithm will be able to orient it well. OBB definition doesn't *imply* a most tight bounding box, even if in your use case it is the only expected behavior. Neither OBB imply to preserve an object orientation, as it's definition is non-trivial and not necessarily most optimal for OBB. The same applies to AABB construction - by default, it is expected to construct just large enough AABB fitting the shape, not the most tight AABB as this could be computationally expensive (unjustifiably in many usage scenarios). What theIsOptimal flag is supposed to do is to find a tighter orientation for OBB, while basic algorithm stops earlier and might return a suboptimal OBB - as a compromise for speed. This flag works to me as expected in Draw Harness (see obb_optimal.png). |
|
|
My apologies: indeed the 'theIsOptimal' flag allows me to get the expected result. I don't know how I made this mistake. Thanks for prompting me to try again! |
|
|
farello, if you found existing documentation of BRepBndLib confusing - feel free to propose the improvements. Otherwise, I propose closing this bug. |
|
|
What is not clear to me is if I always want the maximum precision, should I set 'theIsTriangulationUsed' == false to save time or not? |
|
|
OK please close the ticket to stop Mantis keep sending me reminders :) |
|
|
> if I always want the maximum precision, > should I set 'theIsTriangulationUsed' == false to save time or not? Triangulation is usually a great speed up for an algorithm, but also a source of some additional computation error. BRepMesh algorithm is specifically designed to prepare a shape tessellation within specified deviation - defined by linear and angular deflection parameters. So that normally, application is expected to call BRepMesh with desired precision and then pass this mesh in various algorithm. If you are using existing mesh within TopoDS_Shape, prepared implicitly by some algorithm for other purposes (like AIS_Shape, with Prs3d_Drawer::IsAutoTriangulated() option turned on, preparing a mesh just to be able displaying something on the screen), then deviation could be arbitrary and larger than expected by other algorithms (this is one of the reasons why it is recommended disabling Prs3d_Drawer::IsAutoTriangulated() option). The same applies to BRepBndLib, although this particular tool is rarely used to compute _precise_ bounding box - AABB and OBB are used most often as an early discard filter for other algorithms, so that it is not critical if box is larger than real shape (but with theIsOptimal flag computed OBB is expected to be tight, at least within the triangulation precision). I haven't checked how OBB is computed without triangulation, so I cannot comment if theIsTriangulationUsed=false + theIsOptimal=true combination is actually implemented and if it is able providing a more precise solution using exact geometry stored in the B-Rep. To answer this, one should dive into source code and perform some experiments, I guess. |
|
|
Thanks for the detailed explanation! I think the bug can definitely be closed. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2021-05-13 10:03 |
|
New Issue | |
| 2021-05-13 10:03 |
|
Assigned To | => msv |
| 2021-05-13 10:03 |
|
File Added: examples.zip | |
| 2021-06-15 16:30 | kgv | Summary | BRepBndLib::AddOBB() produces wrong results => Modeling Algorithms - BRepBndLib::AddOBB() produces wrong results |
| 2021-06-15 16:45 | kgv | Note Added: 0101845 | |
| 2021-06-15 16:45 | kgv | Assigned To | msv => farello |
| 2021-06-15 16:45 | kgv | Status | new => feedback |
| 2021-06-15 16:45 | kgv | Resolution | open => unable to reproduce |
| 2021-06-15 16:45 | kgv | Target Version | => 7.6.0 |
| 2021-06-15 18:16 |
|
File Added: 1D$j$J000Ar34pC3WrDJSu and OBB.pdf | |
| 2021-06-15 18:18 |
|
Note Added: 0101848 | |
| 2021-06-15 18:18 |
|
Note Edited: 0101848 | |
| 2021-06-15 19:25 | kgv | File Added: aabb.png | |
| 2021-06-15 19:25 | kgv | File Added: obb_default.png | |
| 2021-06-15 19:26 | kgv | File Added: obb_optimal.png | |
| 2021-06-15 19:36 | kgv | Note Added: 0101851 | |
| 2021-06-15 19:38 | kgv | Note Edited: 0101851 | |
| 2021-06-15 19:39 | kgv | Note Edited: 0101851 | |
| 2021-06-15 19:41 | kgv | Note Edited: 0101851 | |
| 2021-06-15 19:42 | kgv | Note Edited: 0101851 | |
| 2021-06-15 19:42 | kgv | Note Edited: 0101851 | |
| 2021-06-15 19:43 | kgv | Note Edited: 0101851 | |
| 2021-06-16 11:59 |
|
Note Added: 0101862 | |
| 2021-06-16 12:05 | kgv | Note Added: 0101864 | |
| 2021-06-16 12:20 |
|
Note Added: 0101865 | |
| 2021-06-23 13:27 |
|
Note Added: 0102008 | |
| 2021-06-23 13:55 | kgv | Note Added: 0102009 | |
| 2021-06-23 13:56 | kgv | Note Edited: 0102009 | |
| 2021-06-23 13:57 | kgv | Note Edited: 0102009 | |
| 2021-06-23 13:58 | kgv | Assigned To | farello => bugmaster |
| 2021-06-23 13:58 | kgv | Resolution | unable to reproduce => no change required |
| 2021-06-23 15:40 |
|
Note Added: 0102013 | |
| 2021-07-28 12:07 | bugmaster | Status | feedback => closed |
