View Issue Details

IDProjectCategoryView StatusLast Update
0024799CommunityOCCT:Modeling Algorithmspublic2016-08-09 17:39
ReporterTimo Assigned Tobugmaster  
Status closedResolutionfixed 
Product Version6.7.0 
Target Version6.8.0Fixed in Version6.8.0 
Summary0024799: [regression] BRepAlgoAPI_Common returns empty result
DescriptionFor the given case bopcommon returns an empty compound in OCC 6.7.0.
In OCC 6.6.0 the result was not empty. It wasn't a valid shape but it was possible to fix it using fixshape.

The case can be seen as a limitation of BRepAlgoAPI as bopcheck indicates that 2 points are too near to each other.
However, this and similar cases worked in OCC 6.6.0 and previous releases.

The problem was introduced by commit:
78c66ef1c92515f5d43d299f763348e6fe8d7a85 * 0024286: Wrong result done by General Fuse algorithm.

If this commit is reverted, everything works well.
Steps To Reproducerestore Vent2.brep v
explode v
checkshape v
bop v_1 v_2
bopcommon r
whatis r
explode r
=> r is an empty compound
Additional information
and documentation updates

  Standard_Integer BOPAlgo_PaveFiller::PostTreatFF
    (BOPDS_IndexedDataMapOfShapeCoupleOfPaveBlocks& theMSCPB,
     BOPCol_DataMapOfShapeInteger& aMVI,
     BOPDS_DataMapOfPaveBlockListOfPaveBlock& aDMExEdges,
     BOPCol_DataMapOfIntegerInteger& aDMI,
     Handle(NCollection_BaseAllocator)& theAllocator)

To track the modification of the source vertices, the new vertices, created in PostTreatFF, have been added to myShapesSD map.
TagsNo tags attached.
Test case numberbugs modalg_5(010) bug24799

Attached Files

  • (819,499 bytes)


related to 0027760 closedbugmaster [regression] BRepAlgoAPI_Common returns empty result 



2014-04-04 18:42

developer (819,499 bytes)


2014-04-29 14:18

developer   ~0029135

Git branch CR24799 is ready to be reviewed.

The patch allows to create the common between attached shapes, but, actually, the case is a limitation of Boolean Operation algorithm, as the argument is self-interfered.
In general, using such shapes as arguments of Boolean Operations can lead to unpredictable results.

Dear Timo,

If you know that the shape is self-interfered and such shapes should not be used as arguments of BOPs, why are you still using these shapes?

Basing your programs on the Boolean Operations with such shapes is not a very good idea. Doing so, You should be ready to get such unexpected results constantly.

Why don't you try to fix the shape (and similar shapes) before Boolean Operation. Or, even more, try to find out how that shape became self-interfered and fix it to prevent creation of such shapes in the future.

For example, in this particular case, If you merge the vertices in the first shape, which interfere with each other, there won't be any problem with creation of the common part between these shapes.

Try the following script in DRAW:

restore Vent2.brep b
explode b; copy b_1 b1; copy b_2 b2

#merging vertices
explode b1 f
bfuse r b1_1 b1_8
explode r f

#shell creation
shape b1sh sh
add r_1 b1sh
add b1_2 b1sh
add b1_3 b1sh
add b1_4 b1sh
add b1_5 b1sh
add b1_6 b1sh
add b1_7 b1sh
add r_2 b1sh
#solid creation
shape b1 so
add b1sh b1

#check for self-intersections
don b1 b2
bopcheck b1
# This shape seems to be OK.

#boolean operation
bop b1 b2
bopcommon r
checkshape r
# This shape seems to be valid


2014-04-29 14:24

developer   ~0029136



2014-05-08 12:11

tester   ~0029249

Dear BugMaster,

Branch CR24799 (and products from GIT master) was compiled on Linux and Windows platforms and tested.
SHA-1: d9e047b13398a78131cb43e6964f70018cc66fb7

Number of compiler warnings:

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

products component :
Linux: 12 (12 on master)
Windows: 2 (2 on master)

No regressions/differences

Testing cases:
bugs modalg_5(010) bug24799: OK

Testing on Linux:
Total MEMORY difference: 356308212 / 355561056
Total CPU difference: 57380.759999999864 / 53337.799999999814

Testing on Windows:
Total MEMORY difference: 379157332 / 379517796
Total CPU difference: 39089.921875 / 36585.703125

There are no differences in images found by testdiff.


2014-07-14 13:59

developer   ~0030118

Dear emv,

thanks for the note about merging faces. I wasn't aware of the necessity to fuse the faces. Normally, I just sew the faces to create a solid. I thought sewing takes care of such things like merging vertices, doesn't it?
Can you explain the difference between just sewing the faces and fusing them first?


2014-08-28 09:26

developer   ~0031132

Dear Timo,
can you reproduce the sewing problem in draw? If yes, please register another issue concerning this problem.

Related Changesets

occt: master 6a43d224

2014-04-29 10:07:16


Committer: bugmaster Details Diff
0024799: [regression] BRepAlgoAPI_Common returns empty result
To track the modification of the source vertices, the new vertices, created in PostTreatFF, have been added to myShapesSD map.
Affected Issues
mod - src/BOPAlgo/BOPAlgo_PaveFiller_6.cxx Diff File

Issue History

Date Modified Username Field Change
2014-04-04 18:42 Timo New Issue
2014-04-04 18:42 Timo Assigned To => ifv
2014-04-04 18:42 Timo File Added:
2014-04-04 18:43 Timo Steps to Reproduce Updated
2014-04-28 15:40 emv Assigned To ifv => emv
2014-04-29 12:58 abv Target Version 6.7.1 => 6.8.0
2014-04-29 14:18 emv Note Added: 0029135
2014-04-29 14:18 emv Assigned To emv => pkv
2014-04-29 14:18 emv Status new => resolved
2014-04-29 14:18 emv Additional Information Updated
2014-04-29 14:24 pkv Note Added: 0029136
2014-04-29 14:24 pkv Assigned To pkv => mkv
2014-04-29 14:24 pkv Status resolved => reviewed
2014-05-08 12:11 mkv Note Added: 0029249
2014-05-08 12:11 mkv Test case number => bugs modalg_5(010) bug24799
2014-05-08 12:11 mkv Assigned To mkv => bugmaster
2014-05-08 12:11 mkv Status reviewed => tested
2014-05-12 16:20 bugmaster Changeset attached => occt master 6a43d224
2014-05-12 16:20 bugmaster Status tested => verified
2014-05-12 16:20 bugmaster Resolution open => fixed
2014-07-14 13:59 Timo Note Added: 0030118
2014-08-28 09:26 emv Note Added: 0031132
2014-11-11 12:45 aiv Fixed in Version => 6.8.0
2014-11-11 12:57 aiv Status verified => closed
2016-08-09 17:39 Timo Relationship added related to 0027760