Open CASCADE, the 3D modelling kernel
3D modeling & numerical simulation

Search the Forums
See All Topics
Open CASCADEShowroomGet it!Developer CornerSupport and ProductsAbout us
Technical overview
Areas of use
Advantages
FAQ
Screenshots
Shape factory
Shape gallery
Demonstrations
What's new
System requirements
Download Center
Public license
Documentation
Getting started
Forums
Open Source community
Training and e-learning
A-la Carte Support
Value-added software
Complementary Components
Customer Corner
Company Profile
Marketing Materials
Contact Us
News
Home / Developer Corner / Forums / Usage issues / BRepMesh_IncrementalMesh fails to create any triangles for this IGES file

BRepMesh_IncrementalMesh fails to create any triangles for this IGES file

BRepMesh_IncrementalMesh fails to create any triangles for this IGES file
Tod Courtney 2013/01/27 08:25
I have two different IGES files of the same geometry. The geometry is a wheel. The first version was created by the Rhino CAD tool. The second version was created by OCCT by loading the first version and saving with IGESCAFControl_Writer. The both versions render correctly in Rhino and FreeCAD (version 0.12 Revision: 5382). Only the first version renders correctly in our tool that is built on top of OCCT 6.5.4. For the second version, BRepMesh_IncrementalMesh creates 0 triangles. I also tested our tool with OCCT 6.5.2 and found the same problem.

The first version contains a single IGES 128 surface. The second version contains an IGES 144 surface with a trimming curve. The trimming curve traces the radial cross section of the wheel. Both versions represent the same geometry -- a wheel -- but they use different IGES entities.

I have made good progress in debugging the BRepMesh_IncrementalMesh code and can see that it is failing to find the correct myvmax value in BRepMesh_FastDiscret::Add. When it adds the edge points for the two trimming curves, the V value of the points is always 0. somehow it never sees the part of the trimming curve where V=vmax of the surface. You can see this from these lines in the output :

BRM_FD::Add 8
BRM_FD::AddNode 1 1=(4.694805 0.000000)
BRM_FD::AddNode 2 2=(0.000000 0.000000)
BRM_FD::AddNode 3 3=(4.443159 0.000000)
BRM_FD::AddNode 3 4=(4.216677 0.000000)
BRM_FD::AddNode 3 5=(4.002098 0.000000)
BRM_FD::AddNode 3 6=(3.763746 0.000000)
BRM_FD::AddNode 3 7=(3.513214 0.000000)
BRM_FD::AddNode 3 8=(3.262861 0.000000)
BRM_FD::AddNode 3 9=(3.038453 0.000000)
BRM_FD::AddNode 3 10=(2.823973 0.000000)
BRM_FD::AddNode 3 11=(2.585512 0.000000)
BRM_FD::AddNode 3 12=(2.334623 0.000000)
BRM_FD::AddNode 3 13=(2.085048 0.000000)
BRM_FD::AddNode 3 14=(1.860914 0.000000)
BRM_FD::AddNode 3 15=(1.646515 0.000000)
BRM_FD::AddNode 3 16=(1.407957 0.000000)
BRM_FD::AddNode 3 17=(1.156760 0.000000)
BRM_FD::AddNode 3 18=(0.907833 0.000000)
BRM_FD::AddNode 3 19=(0.683930 0.000000)
BRM_FD::AddNode 3 20=(0.469599 0.000000)
BRM_FD::AddNode 3 21=(0.234799 0.000000)


I need help to find a fix for this issue. I believe the problem is due to the fact that the wheel is constructed with one NURBS surface and is closed in both U and V. If I use an external CAD tool to split the NURBS surface into 2 pieces, either in U or V, OCCT will build a mesh of the entire wheel.

While its good to know I can fix this particular wheel, I have seen this issue on other models. I would like to find a solution within OCCT that avoids this issue -- it is not practical to 'fix' every model that our tool based on OCCT writes out with an external CAD program. One possible fix would be to change the way the IGES file is written so that it does not add trimming curves or creates different trimming curves. Another fix would be to change BRepMesh_FastDiscret so that it can handle this type of surface. Suggestions?

I help reproduce and diagnose this issue I have attached a zip file with these files:

* 3 C++ files from BRepMesh in OCCT 6.5.4. I added print statements to trace the code flow.
BRepMesh_FastDiscret.cxx
BRepMesh_FastDiscretFace.cxx
BRepMesh_IncrementalMesh.cxx
* version 1 of the IGES file -- the good version
gh1-wheel-version1.igs
* version 2 of the IGES file -- the bad version
gh1-wheel-version2.igs
* output of my tool when it creates BRepMesh_IncrementalMesh on version1 and version2 of the IGES file:
occt-debug-output-version1.txt
occt-debug-output-version2.txt

The lines in the occt-debug file correspond to the printf() calls in the 3 .cxx files.


Thank you,
Tod Courtney
You have to be logged in to download the attached file
Tod Courtney 2013/01/30 07:41
I was able to solve this issue by adding this line to the code we use to read IGES files:

Interface_Static::SetIVal("read.surfacecurve.mode",3);

it tells the reader to trust the 2D curves and recompute the 3D curves. I found this in the OCCT doc/iges.pdf file and in this forum post:

http://www.opencascade.org/org/forum/thread_20801/
 
 
Latest news
  • Open CASCADE Technology 6.7.0 is available for download!
  • Open CASCADE Technology 6.6.0 is available for download!
  • Open CASCADE Technology 6.5.5 is available for download!

  • © OPEN CASCADE 2000 - 2014  |  Search  |  Contacts   |  Site map