View Issue Details

IDProjectCategoryView StatusLast Update
0023167CommunityOCCT:Meshpublic2012-11-16 13:18
Reportergoeranbarz Assigned Tobugmaster  
PrioritynormalSeverityminor 
Status closedResolutionopen 
PlatformWindowsOSVC++ 2010 
Product Version6.5.3 
Target Version6.5.4Fixed in Version6.5.4 
Summary0023167: Hole in Triangulation
DescriptionHello,

when I import the attached step file the triangulation doesn't work correctly for the 397th face (started counting from 1). Their is a hole at the bottom left and a triangle is drawn accross the face.
Steps To ReproduceHandle(TDocStd_Document) hDoc;
 XCAFApp_Application::GetApplication()->NewDocument("MDTV_XCAF", hDoc);
 STEPCAFControl_Reader reader;
 reader.SetColorMode(true);
 reader.ReadFile(strFileName);
 reader.Transfer(hDoc);
 
for (TDF_ChildIterator it(XCAFDoc_DocumentTool::ShapesLabel(hDoc->Main())); it.More() && !progress.canceled(); it.Next())
 {
 if (XCAFDoc_ShapeTool::IsSimpleShape(it.Value()))
 {
 TopoDS_Shape shapeCurrent;
 XCAFDoc_ShapeTool::GetShape(it.Value(), shapeCurrent);
 
TopExp_Explorer expFace;
 expFace.Init(shapeCurrent, TopAbs_FACE);
 int nMin(397), nMax(397); //The exception occurs in face 397
 for (Standard_Integer numFace = 1; expFace.More(); expFace.Next(), ++numFace)
 {
 if (numFace < nMin || numFace > nMax)
 continue;
 TopoDS_Face myFace = TopoDS::Face(expFace.Current());
 Handle(Poly_Triangulation) myT = BRep_Tool::Triangulation(myFace, myLocation);
 if (myT.IsNull())
 {
 BRepMesh_IncrementalMesh Mesh(myFace, 0.7, Standard_False, 0.75);
 myT = BRep_Tool::Triangulation(myFace, myLocation);
 }
 }
 }
 }
 
Additional information
and documentation updates
This error might have the same reason as Bug 0023105, but in contrast to this Bug, no exception is occuring here, there is just a wronng triangulation shown
TagsNo tags attached.
Test case numberbugs demo CR23409

Attached Files

  • 32966_L_Tuer_rechts_Gr_1_CATIA.stp (1,491,216 bytes)
  • bug23167_f397.brep (89,363 bytes)

Relationships

parent of 0023409 closedoan Open CASCADE Tricheck command doesn't report problem when triangulation has unexpected holes 

Activities

goeranbarz

2012-05-21 13:38

reporter  

32966_L_Tuer_rechts_Gr_1_CATIA.stp (1,491,216 bytes)

abv

2012-05-31 08:38

manager  

bug23167_f397.brep (89,363 bytes)

abv

2012-05-31 09:04

manager   ~0020613

The triangulation problem seems to have been fixed by #22884, at least I could not reproduce it after updating to current master.

However, I noticed another problem: neither incmesh nor tricheck nor trinfo commands in DRAW notice the problem in triangulation when it existed.

I have attached file bug23167_f397.brep which is face 397 from the STEP file coming with bug report, with triangulation computed by previous snapshot of OCCT (should be similar to that produced by OCCT 6.5.3).

Do in DRAW:

restore bug23167_f397.brep a
vdisplay a
# shape looks bad!
axo
fit
isos a 0
triangles a
# free edges can be seen
trinfo a
tricheck a
# no problems are reported -- why?

oan

2012-06-28 17:44

developer   ~0020818

Dear Andrey,

trinfo command just collects information about number of triangles and display it - nothing more - no tricks, no checks.

incmesh can indicate a problem in case of classification problems such as open wire or self intersection. If some kind of exception occurs during meshing procedure, incmesh will break all computations.

tricheck command intended to collect info about free edges, nodes and takes info about absent triangulation on face.

IMHO, this kind of triangulation failure can't be recognized, because it's formally correct: face has triangulation and each edge of face has at least one triangle. This means absent triangles are considered as usual holes and therefore it's difficult to classify them as invalid areas.

goeranbarz

2012-06-29 16:06

reporter   ~0020835

I've compiled version 6.5.3 with the code changes from issue #22884 and the problem doesn't appear anymore.

abv

2012-07-11 20:24

manager   ~0020919

I believe that command tricheck can be improved to detect holes in the triangulation that do not correspond to wires (i.e. there are no edges that have polygon-on-triangulation on the links along the hole).

abv

2012-09-03 09:36

manager   ~0021386

Please add a test case for this issue, then I propose it is switched to VERIFIED

apn

2012-09-04 13:42

administrator   ~0021407

Last edited: 2012-09-04 13:47

Test case was pushed to branch CR23409.
Tricheck command was fixed in bug OCC23409.

Issue History

Date Modified Username Field Change
2012-05-21 12:56 goeranbarz New Issue
2012-05-21 12:56 goeranbarz Assigned To => jgv
2012-05-21 13:38 goeranbarz File Added: 32966_L_Tuer_rechts_Gr_1_CATIA.stp
2012-05-21 13:55 jgv Category OCCT:Modeling Algorithms => OCCT:Visualization
2012-05-31 08:38 abv File Added: bug23167_f397.brep
2012-05-31 09:04 abv Note Added: 0020613
2012-05-31 09:04 abv Assigned To jgv => oan
2012-05-31 09:04 abv Status new => assigned
2012-06-28 17:44 oan Note Added: 0020818
2012-06-28 17:45 oan Status assigned => feedback
2012-06-28 18:15 oan Status feedback => assigned
2012-06-29 16:06 goeranbarz Note Added: 0020835
2012-06-29 16:06 goeranbarz Status assigned => resolved
2012-07-11 20:24 abv Note Added: 0020919
2012-08-29 19:05 oan Relationship added parent of 0023409
2012-09-03 09:36 abv Note Added: 0021386
2012-09-03 09:36 abv Assigned To oan => apn
2012-09-03 09:36 abv Status resolved => feedback
2012-09-04 13:42 apn Note Added: 0021407
2012-09-04 13:42 apn Test case number => bugs demo CR23409
2012-09-04 13:44 apn Note Edited: 0021407
2012-09-04 13:47 apn Note Edited: 0021407
2012-09-04 17:42 apn Assigned To apn => bugmaster
2012-09-04 17:42 apn Status feedback => tested
2012-09-04 17:42 apn Status tested => verified
2012-10-01 14:25 bugmaster Target Version => 6.5.4
2012-11-09 09:51 abv Changeset attached => occt master 2e1a4dae
2012-11-09 09:52 abv Category OCCT:Visualization => OCCT:Mesh
2012-11-16 13:13 bugmaster Fixed in Version => 6.5.4
2012-11-16 13:18 bugmaster Status verified => closed