MantisBT - Community
View Issue Details
0032363Community[OCCT] OCCT:Modeling Algorithmspublic2021-05-13 10:032021-07-28 12:07
closedno change required 
Microsoft VC++ 2019Windows10 64-bit
[OCCT] 7.5.1 
[OCCT] 7.6.0* 
0032363: Modeling Algorithms - BRepBndLib::AddOBB() produces wrong results
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.
Bnd_OBB obb;

try {
  BRepBndLib::AddOBB(inShape, obb);

    gp_Pnt obbVtx[8];
    std::string folderPath("C:\\Users\\Amedeo\\Test"),

    dumpShape(folderPath, obbFileName, inShape);


    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());
No tags attached.
zip (10,091) 2021-05-13 10:03
pdf 1D$j$J000Ar34pC3WrDJSu and OBB.pdf (29,257) 2021-06-15 18:16
png aabb.png (3,459) 2021-06-15 19:25
png obb_default.png (3,951) 2021-06-15 19:25
png obb_optimal.png (3,369) 2021-06-15 19:26
Issue History
2021-05-13 10:03farelloNew Issue
2021-05-13 10:03farelloAssigned To => msv
2021-05-13 10:03farelloFile Added:
2021-05-14 22:36kgvRelationship addedchild of 0029311
2021-06-15 16:30kgvSummaryBRepBndLib::AddOBB() produces wrong results => Modeling Algorithms - BRepBndLib::AddOBB() produces wrong results
2021-06-15 16:45kgvNote Added: 0101845
2021-06-15 16:45kgvAssigned Tomsv => farello
2021-06-15 16:45kgvStatusnew => feedback
2021-06-15 16:45kgvResolutionopen => unable to reproduce
2021-06-15 16:45kgvTarget Version => 7.6.0*
2021-06-15 18:16farelloFile Added: 1D$j$J000Ar34pC3WrDJSu and OBB.pdf
2021-06-15 18:18farelloNote Added: 0101848
2021-06-15 18:18farelloNote Edited: 0101848bug_revision_view_page.php?bugnote_id=101848#r25366
2021-06-15 19:25kgvFile Added: aabb.png
2021-06-15 19:25kgvFile Added: obb_default.png
2021-06-15 19:26kgvFile Added: obb_optimal.png
2021-06-15 19:36kgvNote Added: 0101851
2021-06-15 19:38kgvNote Edited: 0101851bug_revision_view_page.php?bugnote_id=101851#r25372
2021-06-15 19:39kgvNote Edited: 0101851bug_revision_view_page.php?bugnote_id=101851#r25373
2021-06-15 19:41kgvNote Edited: 0101851bug_revision_view_page.php?bugnote_id=101851#r25374
2021-06-15 19:42kgvNote Edited: 0101851bug_revision_view_page.php?bugnote_id=101851#r25375
2021-06-15 19:42kgvNote Edited: 0101851bug_revision_view_page.php?bugnote_id=101851#r25376
2021-06-15 19:43kgvNote Edited: 0101851bug_revision_view_page.php?bugnote_id=101851#r25377
2021-06-16 11:59farelloNote Added: 0101862
2021-06-16 12:05kgvNote Added: 0101864
2021-06-16 12:20farelloNote Added: 0101865
2021-06-23 13:27farelloNote Added: 0102008
2021-06-23 13:55kgvNote Added: 0102009
2021-06-23 13:56kgvNote Edited: 0102009bug_revision_view_page.php?bugnote_id=102009#r25401
2021-06-23 13:57kgvNote Edited: 0102009bug_revision_view_page.php?bugnote_id=102009#r25402
2021-06-23 13:58kgvAssigned Tofarello => bugmaster
2021-06-23 13:58kgvResolutionunable to reproduce => no change required
2021-06-23 15:40farelloNote Added: 0102013
2021-07-28 12:07bugmasterStatusfeedback => closed

2021-06-15 16:45   
> 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.

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
2021-06-15 18:18   
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.

2021-06-15 19:36   
(edited on: 2021-06-15 19:43)
> 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).

2021-06-16 11:59   
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!
2021-06-16 12:05   

if you found existing documentation of BRepBndLib confusing - feel free to propose the improvements.

Otherwise, I propose closing this bug.
2021-06-16 12:20   
What is not clear to me is if I always want the maximum precision, should I set 'theIsTriangulationUsed' == false to save time or not?
2021-06-23 13:27   
OK please close the ticket to stop Mantis keep sending me reminders :)
2021-06-23 13:55   
(edited on: 2021-06-23 13:57)
> 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.

2021-06-23 15:40   
Thanks for the detailed explanation! I think the bug can definitely be closed.