DiscussionsIssue archiveOCCT:Modeling Algorithms

Archived issue #0025631

Bounding box is too big for the face.

Open CASCADEOCCT:Modeling Algorithmsclosed12 public notes

Search issues

Description

Bounding box is too big for the face.

The goal is:
To compute bounding box more precisely

Steps to reproduce

Use the following commands to reproduce the problem:
#
restore fbx f

bounding f
# please have a look on axonometric view
# for more details

Public activity

12 archived notes

Participants are labeled by their role within this record.

01Commenter 1
Bounding box is computed for a bspline face using poles of bspline. In the attached picture 2 boxes are shown, the larger one is computed on poles, and the smaller one is computed on triangulation nodes.
In the absence of triangulation, the larger box is computed.
In order to compute the precise bounding box, it is needed to develop a special algorithm. And most probably that it will slow down the BB computation.
02Commenter 2
It is needed to make search (in the inet) for optimal methods of global optimization.
After applying it to computing minimal bounding box for a restricted bspline surface, evaluate its performance, as well the performance of OCCT libraries (grid tests) if we replace old algorithm with the new one.
If performance will be significantly decreased then create new API method for new algorithm, and use it where it is needed case by case (may be the latter will be out of scope of this bug).
03Commenter 2
Branch [archived branch] has been created by Participant.

[revision removed]


Detailed log of new commits:

Author: aml
Date: Mon Jan 19 11:48:31 2015 +0300

    0025631: Bounding box is too big for the face.
    
    Fixed start and finish idexes of poles in case of trimmed surface.
04Commenter 4
Dear msv,
Please check current state of branch CR25631.
Current implementation reduce bounding box (look at attached image), using lightweight additional computations, which should not affect performance.

Algorithm with computing precise bounding box still in development now.
05Commenter 5
Remarks:
- Not used variable at line 323
- Strange condition at line 302: what if we want to build box on subset of the surface parametric space? It is here regardless of the current patch.
- At line 208: please think how it will work on periodic B-splines.
06Commenter 2
Branch [archived branch] has been updated forcibly by Participant.

[revision removed]
07Commenter 2
Branch [archived branch] has been updated forcibly by Participant.

[revision removed]
08Commenter 8
Dear msv,
Please check updated branch CR25631.

I
- Strange condition at line 302: what if we want to build box on subset of the surface parametric space? It is here regardless of the current patch.

Old:
In case when (UMin,VMin, UMax, VMax) not equal to topology borders then used default algorithm based on regular grid.
This behavior caused by properties of Bezier surface, on which trimmed case should be handled like untrimmed (all the poles used in any computations -> all the poles should be in bounding box).
That is why grid algorithm is used when parameters not equal to borders.

New:
In case of trimmed BSpline surface if (UMin,VMin, UMax, VMax) lies inside of geometry borders then modified convex hull algorithm is used.
Bezier surface handling not changed.


Conclusion:
Patch should change only BSpline surface handling.

II
- At line 208: please think how it will work on periodic B-splines.

Fixed.
09Commenter 9
Reviewed.
10Commenter 10
Dear Commenter 1,
Branch CR25631 from occt git-repository (and master from products git-repository) was compiled on Linux, MacOS and Windows platforms and tested on Release mode.
[revision removed]

Number of compiler warnings:

occt component :
Linux: 18 (18 on master)
Windows: 0 (0 on master)

products component :
Linux: 11 (11 on master)
Windows: 1 (1 on master)

Regressions/Differences:
No regressions/differences

Testing cases:
http://occt-tests/CR25631-master-occt/Debian60-64/bugs/moddata_3/bug25631.html
http://occt-tests/CR25631-master-occt/Windows-32-VC10/bugs/moddata_3/bug25631.html
bugs moddata_3(013) bug25631: OK

Testing on Linux:
occt component :
Total MEMORY difference: 370237700 / 369907280
Total CPU difference: 47707.11 / 46828.580000000045
products component :
Total MEMORY difference: 110073812 / 110058756
Total CPU difference: 16423.76999999998 / 15822.439999999979

Testing on Windows:
occt component :
Total MEMORY difference: 276749496 / 276885156
Total CPU difference: 36273.15625 / 39964.359375
products component :
Total MEMORY difference: 72465040 / 71278224
Total CPU difference: 12933.75 / 10959.0625

There are no differences in images found by testdiff.
11Commenter 2
Branch [archived branch] has been updated by Participant.

[revision removed]


Detailed log of new commits:

Author: mkv
Date: Thu Jan 29 13:42:21 2015 +0300

    Test case for issue CR25631

12Commenter 2
Branch [archived branch] has been deleted by Participant.

[revision removed]

Related records