MantisBT - Community
View Issue Details
0023389Community[OCCT] OCCT:Modeling Algorithmspublic2012-08-17 19:302012-11-16 13:18
[OCCT] 6.5.3 
[OCCT] 6.5.4[OCCT] 6.5.4 
boolean bopcut_complex (023) P8
0023389: (OCC 6.5.3 regression) BRepAlgoAPI_Cut returns invalid solid
The following cut operation results in an invalid solid in OCCT 6.5.3.
In OCCT 6.5.2 the result is valid.

Draw script:

restore blade3.brep b
explode b
checkshape b_1
checkshape b_2
bopcheck b_1
bopcheck b_2
bopargcheck b_1 b_2
bop b_1 b_2
bopcut r
vdisplay r
vsetdispmode r 1
checkshape r

It was discussed on the forum: [^]

The given test case for boolean cut has valid arguments (checkshape, bopcheck, bopargcheck).

The result is invalid on:
- OCCT 6.5.3
- one-week-old version from the git repository
- modified OCCT 6.5.3 where the code of the whole TKBO-Toolkit (except for the M_PI-macro) was changed back to the state of 6.5.2.

Therefore, I think it has to do with some changes of classes that are used by TKBO.
Modified entities:


modified method:

Standard_Boolean IntPolyh_Intersection::PerformMaillage(IntPolyh_PMaillageAffinage &theMaillageS)

wrong breakdown exit has been deleted.
No tags attached.
? blade3.brep (262,532) 2012-08-17 19:30
? blade3_OCC652.brep (245,030) 2012-08-17 19:31
Issue History
2012-08-17 19:30TimoNew Issue
2012-08-17 19:30TimoAssigned To => jgv
2012-08-17 19:30TimoFile Added: blade3.brep
2012-08-17 19:31TimoFile Added: blade3_OCC652.brep
2012-08-17 19:32TimoNote Added: 0021263
2012-08-20 07:50abvAssigned Tojgv => emv
2012-08-20 07:50abvStatusnew => assigned
2012-09-11 10:34jgvNote Added: 0021452
2012-09-11 10:34jgvStatusassigned => resolved
2012-09-11 10:41jgvAdditional Information Updatedbug_revision_view_page.php?rev_id=4227#r4227
2012-09-11 12:14emvNote Added: 0021456
2012-09-11 12:14emvStatusresolved => reviewed
2012-09-12 10:28szyAssigned Toemv => mkv
2012-09-13 15:58bugmasterProjectCommunity => @97@
2012-09-14 12:30apnNote Added: 0021483
2012-09-14 12:35apnTest case number => boolean bopcut_complex (023) P8
2012-09-14 12:35apnAssigned Tomkv => bugmaster
2012-09-14 12:35apnStatusreviewed => tested
2012-09-17 17:29jgvChangeset attached => occt master 3d063ba6
2012-09-17 17:32jgvAssigned Tobugmaster => jgv
2012-09-17 17:32jgvStatustested => verified
2012-09-17 17:32jgvResolutionopen => fixed
2012-09-18 16:34jgvAssigned Tojgv => mkv
2012-09-18 16:36jgvNote Added: 0021503
2012-09-18 16:37jgvStatusverified => assigned
2012-09-28 16:00mkvNote Added: 0021595
2012-10-03 10:41bugmasterProject@97@ => Community
2012-10-03 10:43bugmasterStatusassigned => resolved
2012-10-03 10:44bugmasterStatusresolved => reviewed
2012-10-03 10:44bugmasterStatusreviewed => verified
2012-10-03 10:44abvRelationship addedrelated to 0000053
2012-10-05 10:19bugmasterTarget Version => 6.5.4
2012-11-06 15:09TimoNote Added: 0022101
2012-11-06 15:14TimoNote Edited: 0022101bug_revision_view_page.php?bugnote_id=22101#r4475
2012-11-06 15:23TimoNote Edited: 0022101bug_revision_view_page.php?bugnote_id=22101#r4476
2012-11-06 15:58abvNote Added: 0022106
2012-11-06 16:32TimoNote Added: 0022108
2012-11-16 13:13bugmasterFixed in Version => 6.5.4
2012-11-16 13:18bugmasterStatusverified => closed

2012-08-17 19:32   
blade3_OCC652.brep is the same test case but it was produced with OCCT 6.5.2 instead of 6.5.3. It shows the same behavior as described above.
2012-09-11 10:34   
The branch CR23389 is ready for reviewing
2012-09-11 12:14   
No remarks.
2012-09-14 12:30   
Dear BugMaster,
Branch CR23389 (and products from GIT master) was compiled on Linux and Windows platforms and tested.

Not detected

Not detected

Testing case:
boolean bopcut_complex (023) P8 - OK
2012-09-18 16:36   
The case

chl 935 R9

is OK if the fix is compiled under the fix to 23388. Please check it.
2012-09-28 16:00   
Dear BugMaster,
Test case chl 935 R9 is OK in IR-2012-09-27 (after raising CR23388).
2012-11-06 15:09   
(edited on: 2012-11-06 15:23)
The test case is OK now.

However, I'm unsure if this fixes really the root cause of the problem.
This problem is actually a regression from 6.5.2 to 6.5.3, but the method where the fix was applied (IntPolyh_Intersection::PerformMaillage) wasn't changed at all from 6.5.2 to 6.5.3.
Therefore, I'm wondering if this really fixes the problem or rather hides / works around it in this special case. I have another test case which is similar but still fails but I cannot report it here because the problem is hidden by another bug (0023375). Shouldn't we look for the root cause somewhere else?

What do you think about my concerns?

Why does the fix just comment the lines out instead of deleting them?

I also debugged the problem myself comparing original 6.5.3 with 6.5.2.
I found out that in 6.5.3 at the second time IntPolyh_Intersection::PerformMaillage is accessed it runs into the code which is commented out by the fix. In 6.5.2 it doesn't run at all into this code. The difference between 6.5.2 and 6.5.3 is already at the start of the method. In 6.5.3 the value of myNbSU2 is very large. Is this correct?

Kind regards,

2012-11-06 15:58   
Hello Timo,

I suggest you report the "other" test case in separate issue (hope it should be still possible even if sewing fails -- you could probably save intermediate result of the sewing produced by OCCT 6.5.2).

Please note that we do not promise fixing of the bugs reported by community, thus consider either providing a fix on yourself, or ordering a support services from us to allocate efforts on fixing the problem.

2012-11-06 16:32   
I will see concerning the other test case.

This mantis entry was originally reported by the Community but then fixed in the scope of a support service. I understand that your resources are limited. I just thought the expert who fixed it could comment on my concerns, if there might be a bug hidden which it is worth digging for and if his fix is rather a workaround.