MantisBT
Mantis Bug Tracker Workflow

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0032363Community[OCCT] OCCT:Modeling Algorithmspublic2021-05-13 10:032021-07-28 12:07
Reporterfarello 
Assigned Tobugmaster 
PrioritynormalSeveritymajor 
StatusclosedResolutionno change required 
PlatformMicrosoft VC++ 2019OSWindowsOS Version10 64-bit
Product Version[OCCT] 7.5.1 
Target Version[OCCT] 7.6.0*Fixed in Version 
Summary0032363: Modeling Algorithms - BRepBndLib::AddOBB() produces wrong results
DescriptionGood 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 ReproduceBnd_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(...)
  {
  }
TagsNo tags attached.
Test case number
Attached Fileszip file icon examples.zip (10,091 bytes) 2021-05-13 10:03
pdf file icon 1D$j$J000Ar34pC3WrDJSu and OBB.pdf (29,257 bytes) 2021-06-15 18:16
png file icon aabb.png (3,459 bytes) 2021-06-15 19:25
png file icon obb_default.png (3,951 bytes) 2021-06-15 19:25
png file icon obb_optimal.png (3,369 bytes) 2021-06-15 19:26

- Relationships

-  Notes
(0101845)
kgv (developer)
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.

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
(0101848)
farello (reporter)
2021-06-15 18:18
edited on: 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.

(0101851)
kgv (developer)
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).

(0101862)
farello (reporter)
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!
(0101864)
kgv (developer)
2021-06-16 12:05

farello,

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

Otherwise, I propose closing this bug.
(0101865)
farello (reporter)
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?
(0102008)
farello (reporter)
2021-06-23 13:27

OK please close the ticket to stop Mantis keep sending me reminders :)
(0102009)
kgv (developer)
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.

(0102013)
farello (reporter)
2021-06-23 15:40

Thanks for the detailed explanation! I think the bug can definitely be closed.

- Issue History
Date Modified Username Field Change
2021-05-13 10:03 farello New Issue
2021-05-13 10:03 farello Assigned To => msv
2021-05-13 10:03 farello File Added: examples.zip
2021-05-14 22:36 kgv Relationship added child of 0029311
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 farello File Added: 1D$j$J000Ar34pC3WrDJSu and OBB.pdf
2021-06-15 18:18 farello Note Added: 0101848
2021-06-15 18:18 farello Note Edited: 0101848 View Revisions
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 View Revisions
2021-06-15 19:39 kgv Note Edited: 0101851 View Revisions
2021-06-15 19:41 kgv Note Edited: 0101851 View Revisions
2021-06-15 19:42 kgv Note Edited: 0101851 View Revisions
2021-06-15 19:42 kgv Note Edited: 0101851 View Revisions
2021-06-15 19:43 kgv Note Edited: 0101851 View Revisions
2021-06-16 11:59 farello Note Added: 0101862
2021-06-16 12:05 kgv Note Added: 0101864
2021-06-16 12:20 farello Note Added: 0101865
2021-06-23 13:27 farello Note Added: 0102008
2021-06-23 13:55 kgv Note Added: 0102009
2021-06-23 13:56 kgv Note Edited: 0102009 View Revisions
2021-06-23 13:57 kgv Note Edited: 0102009 View Revisions
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 farello Note Added: 0102013
2021-07-28 12:07 bugmaster Status feedback => closed


Copyright © 2000 - 2021 MantisBT Team
Powered by Mantis Bugtracker