issue#262 error in bounding box computation

[mpoudot]

…edge or surface

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 48.92%. Comparing base (5cc071c) to head (8bc4021).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #239      +/-   ##
==========================================
- Coverage   48.92%   48.92%   -0.01%     
==========================================
  Files         466      466              
  Lines       50527    50522       -5     
==========================================
- Hits        24721    24717       -4     
+ Misses      25806    25805       -1     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[nicolaslg]

BEWARE : copy-pasting the sphere creation command does not work properly.

The BRepBndLib::AddClose can not be applied in our case, as it expects the shape to be polygonal with planar faces (see https://dev.opencascade.org/doc/refman/html/class_b_rep_bnd_lib.html#a1c5a09bca57f8145e163c59693a45bbf).
The analyzer.IsValid() does not check that property (see https://dev.opencascade.org/doc/refman/html/class_b_rep_check___analyzer.html#a99892412af7e25fb4d5c19c7d54a41fb)

I think checking whether the returned bounding box is flat is not sufficient. Considering a volume and the created block

ctx.getGeomManager().newSphere (Mgx3D.Point(0, 0, 0), 1, 125)
ctx.getTopoManager().newFreeTopoOnGeometry ("Vol0000")

Currently in the branch is returned the following block :

When always calling BRepBndLib::Add(shape, box) instead we have this behavior, which is what we expect :

But when the sphere is scaled, the call to BRepBndLib::Add(shape, box) will return a bounding box that is not "correct"

ctx.getGeomManager().scaleAll(1.000000e+01, 2.000000e+01, 1.000000e+01)

Whereas calling BRepBndLib::AddOptimal(shape, box) gives

BRepBndLib::AddOptimal(shape, box), or rather BRepBndLib::AddOptimal(shape, box, false) might be the better choice; I have not managed to exhibit differences when the third parameter useTriangulation==false. I guess it is better still to put it at false considering we want to behave the same way whether a triangulation is attached to the shapes or not.

[nicolaslg]

As bounding box computation is crucial I am splitting this PR into two PRs

• sphere creation Fix bug on newSphere #243
• bounding box computation (soon to come)

[nicolaslg]

Some tests fail due to the naming of the entities; the following fuse command will assign different names for the surfaces (ex Surf0006).

ctx.getGeomManager().newCylinder (Mgx3D.Point(0, 0, 0), 1, Mgx3D.Vector(0, 0, 4), 3.600000e+02)
ctx.getGeomManager().newCylinder (Mgx3D.Point(1.5, 0, 0), 1, Mgx3D.Vector(0, 0, 4), 3.600000e+02)
ctx.getGeomManager ( ).fuse (["Vol0001","Vol0000"])

Puttinguse_triangulation set to false impacts the execution even when entities are not displayed (in particular in the CI), because the triangulation (is it this triangulation that is used for bounding box computation ?) is always built (see https://github.com/LIHPC-Computational-Geometry/magix3d/blob/main/src/Core/Geom/GeomModificationBaseClass.cpp#L1908)

I am also not sure our compareOCCFace meets the requirements of C++ compare https://en.cppreference.com/cpp/named_req/Compare

I have yet to check the values returned by our computing of the bounding boxes of the nine surfaces in this case and how the sort fares on those

[mpoudot]

Using triangulation =false enables to get the same results as before. Have a look to the changed files. No id changes with main branch in test scripts. What do you think about it ?

[nicolaslg]

Let's proceed with the merge

Thanks for making do with the back and forth with the bounding box computation methods !

[nicolaslg]

I put it here as a reference :

In the fused two cylinder case when using the AddOptimal method the computed bounding boxes of the surfaces vary depending on the use_triangulation parameter (hence the sorted order also changes)

It even impacts the second digit (ex: 0.742695 vs 0.75)

avec use_triangulation==true
 Avant sort ====
entities : [
[0.742695 -1.00018 -0.00730478][2.5073 0.00730478 4.0073]
[0.742695 -0.00730478 -0.00730478][2.5073 1.00018 4.0073]
[0.75 -0.996618 -1e-07][2.5 0.996618 1e-07]
[-1.0073 -1.00018 -0.00730478][0.757305 1.00018 4.0073]
[0.75 -0.996618 4][2.5 0.996618 4]
[0.503223 -0.661438 -1e-07][1 0.661438 1e-07]
[-0.995323 -0.997261 4][0.75 0.997261 4]
[-0.995323 -0.997261 -1e-07][0.75 0.997261 1e-07]
[0.503223 -0.661438 4][1 0.661438 4]
]
sorted_entities 9
 Apres sort ====
sorted_entities : [
[0.75 -0.996618 4][2.5 0.996618 4]
[0.75 -0.996618 -1e-07][2.5 0.996618 1e-07]
[0.742695 -0.00730478 -0.00730478][2.5073 1.00018 4.0073]
[0.742695 -1.00018 -0.00730478][2.5073 0.00730478 4.0073]
[0.503223 -0.661438 4][1 0.661438 4]
[0.503223 -0.661438 -1e-07][1 0.661438 1e-07]
[-0.995323 -0.997261 4][0.75 0.997261 4]
[-0.995323 -0.997261 -1e-07][0.75 0.997261 1e-07]
[-1.0073 -1.00018 -0.00730478][0.757305 1.00018 4.0073]
]

avec use_triangulation==false
 Avant sort ====
entities : [
[0.75 -1 0][2.5 -2.44929e-16 4]
[0.75 -2.44929e-16 0][2.5 1 4]
[0.75 -1 0][2.5 1 0]
[-1 -1 0][0.75 1 4]
[0.75 -1 4][2.5 1 4]
[0.5 -0.661438 0][1 0.661438 0]
[-1 -1 4][0.75 1 4]
[-1 -1 0][0.75 1 0]
[0.5 -0.661438 4][1 0.661438 4]
]
sorted_entities 9
 Apres sort ====
sorted_entities : [
[0.75 -2.44929e-16 0][2.5 1 4]
[0.75 -1 4][2.5 1 4]
[0.75 -1 0][2.5 1 0]
[0.75 -1 0][2.5 -2.44929e-16 4]
[0.5 -0.661438 4][1 0.661438 4]
[0.5 -0.661438 0][1 0.661438 0]
[-1 -1 4][0.75 1 4]
[-1 -1 0][0.75 1 4]
[-1 -1 0][0.75 1 0]
]