MantisBT - Community
View Issue Details
0023746Community[OCCT] OCCT:Data Exchangepublic2013-02-07 23:022013-12-19 13:56
[OCCT] 6.5.2 
[OCCT] 6.7.0[OCCT] 6.7.0 
bugs iges(003) bug23746
0023746: IGES wheel model fails to load when OCCT unit is meters
We discovered a problem with a airplane IGES model. When I load the model into our tool, based on OCCT 6.5.2, I can see all parts of the airplane fine. When I save the model from our tool it saves fine. When I reload the saved file, several of the wheels are missing.

To debug the problem I have created a test program. I also removed a single wheel from the original IGES file.

It appears that the problem is caused by setting:
  Interface_Static::SetCVal ("xstep.cascade.unit", "M");

in our code.

I can load the files fine with the Rhino v4 CAD tool. I can also load them fine with my tool, if I comment out the above "xstep.cascade.unit" line.
I created a simple test program to diagnose and reproduce this issue. It is 'testloadsave.cpp'. It loads a file, translates it, populates a writer, and saves. It takes 3 arguments:

USAGE: testLoadSave <input file> <output file> <1=meters,2=millimeters>

if the last option is 1, the "xstep.cascade.unit" is set to "M". If its any other number, the default of "MM" is used.

to reproduce, I ran these commands ('#' are comments, '>' are commands)

# load original model, keep in MM, save
> ../testLoadSave wheel.igs wheel-0.igs 0 >out-0.txt
# load original model, convert to M, save
> ../testLoadSave wheel.igs wheel-1.igs 1 > out-1.txt

# load "MM" model, keep in MM, save
> ../testLoadSave wheel-0.igs wheel-0-0.igs 0 > out-0-0.txt
# load "MM" model, convert to M, save
> ../testLoadSave wheel-0.igs wheel-0-1.igs 1 > out-0-1.txt

# load "M" model, keep in MM, save
> ../testLoadSave wheel-1.igs wheel-1-0.igs 0 > out-1-0.txt
# load "M" model, convert to M, save
> ../testLoadSave wheel-1.igs wheel-1-1.igs 1 > out-1-1.txt

the source code, wheel*.igs and out*.txt files are all in the attached zip file.

If you look at the 'out' files, two of them will have "BAD" in them. They are the ones that convert to Meters for the second load/save.

If you look at the file sizes and entity lists, you can see that they change for each of the files.

I believe that there is a problem with the tolerances when the files are converted to meters. I have spent several days trying to track down the problem, but I am not yet enough of an OCCT expert to find the solution.
this issue is the same as two forum posts: [^] [^]
No tags attached.
zip (168,479) 2013-02-07 23:02
Issue History
2013-02-07 23:02todcourtneyNew Issue
2013-02-07 23:02todcourtneyAssigned To => gka
2013-02-07 23:02todcourtneyFile Added:
2013-02-12 14:18szvAssigned Togka => szv
2013-02-12 14:18szvStatusnew => assigned
2013-02-12 14:28szvNote Added: 0023308
2013-02-12 14:28szvAssigned Toszv => todcourtney
2013-02-12 14:28szvStatusassigned => feedback
2013-04-22 21:24todcourtneyNote Added: 0024243
2013-05-09 06:31todcourtneyNote Added: 0024352
2013-05-09 09:17abvAssigned Totodcourtney => ika
2013-05-09 09:17abvStatusfeedback => assigned
2013-06-26 14:17ikaNote Added: 0024883
2013-06-26 14:17ikaAssigned Toika => gka
2013-06-26 14:17ikaStatusassigned => resolved
2013-07-18 11:12ikaNote Added: 0025108
2013-07-18 15:21gkaNote Added: 0025110
2013-07-18 15:22gkaAssigned Togka => ika
2013-07-18 15:22gkaStatusresolved => assigned
2013-07-18 15:46ikaNote Added: 0025111
2013-07-18 15:46ikaAssigned Toika => gka
2013-07-18 15:46ikaStatusassigned => resolved
2013-07-18 15:49gkaNote Added: 0025112
2013-07-18 15:49gkaStatusresolved => assigned
2013-07-18 15:49gkaStatusassigned => resolved
2013-07-18 15:50gkaNote Added: 0025113
2013-07-18 15:50gkaStatusresolved => reviewed
2013-07-18 16:04mkvAssigned Togka => mkv
2013-07-19 14:17mkvNote Added: 0025122
2013-07-19 14:18mkvTest case number => bugs iges(003) bug23746
2013-07-19 14:18mkvAssigned Tomkv => ika
2013-07-19 14:18mkvStatusreviewed => assigned
2013-07-23 14:12ikaNote Added: 0025135
2013-07-23 14:12ikaAssigned Toika => mkv
2013-07-23 14:12ikaStatusassigned => feedback
2013-07-23 14:42bugmasterAssigned Tomkv => apn
2013-07-23 19:20apnNote Added: 0025140
2013-07-24 09:32apnAssigned Toapn => bugmaster
2013-07-24 09:32apnStatusfeedback => tested
2013-07-24 09:32apnTarget Version => 6.7.0
2013-07-26 12:33ikaChangeset attached => occt master fdabc211
2013-07-26 12:33ikaAssigned Tobugmaster => ika
2013-07-26 12:33ikaStatustested => verified
2013-07-26 12:33ikaResolutionopen => fixed
2013-12-19 13:52bugmasterStatusverified => closed
2013-12-19 13:56bugmasterFixed in Version => 6.7.0

2013-02-12 14:28   
By default, the static parameter "write.iges.brep.mode" is set to "Faces". In the case of wheel.igs, it leads to the loss of connectivity within the model during writing, and consequent errors in multiple reading-writing cycles. Setting the static parameter "write.iges.brep.mode" to "BRep" solves the problem.

Please confirm if this solution works on your side.

Here is a sample script to reproduce in Draw:

param write.iges.brep.mode BRep
param xstep.cascade.unit MM
igesbrep D:/occt-bugreport/wheel.igs a *
brepiges a D:/occt-bugreport/occ-wheel-0.igs
param xstep.cascade.unit M
igesbrep D:/occt-bugreport/wheel.igs b *
brepiges b D:/occt-bugreport/occ-wheel-1.igs
param xstep.cascade.unit MM
igesbrep D:/occt-bugreport/occ-wheel-0.igs a0 *
brepiges a0 D:/occt-bugreport/occ-wheel-0-0.igs
param xstep.cascade.unit M
igesbrep D:/occt-bugreport/occ-wheel-0.igs b0 *
brepiges b0 D:/occt-bugreport/occ-wheel-0-1.igs
param xstep.cascade.unit MM
igesbrep D:/occt-bugreport/occ-wheel-1.igs a1 *
brepiges a1 D:/occt-bugreport/occ-wheel-1-0.igs
param xstep.cascade.unit M
igesbrep D:/occt-bugreport/occ-wheel-1.igs b1 *
brepiges b1 D:/occt-bugreport/occ-wheel-1-1.igs
2013-04-22 21:24   
I believe that OCCT should be able to save this geometry using either output mode. It is good to know that BREP mode could be used as a work-around, but I feel that the BREP entities are less-likely to be compatible or well-supported by 3rd-party CAD tools compared to the FACE entities like 144 and 142.

Also, this CAD model was originally produced by our customer's software based on a non-OCCT CAD library. We do not have the ability to change that software to use BREP entities. We need to be able to import those CAD models into our OCCT-based tools with confidence that we are not loosing or corrupting the geometry.

Our work-around was to stop using the unit-conversion features of OCCT and to explicitly convert the geometry to/from MM in the application code, after the CAD file is loaded and before it is saved. This seems to work with the FACES mode but causes a lot of extra effort on our part. It would be better to have this issue fixed inside OCCT.
2013-05-09 06:31   
I keep getting reminders about this ticket, but there is nothing that I can do. I do not think this ticket should be resolved, but that is the only option I have. What can I do to change the state of this ticket to something besides feedback (the current state) or resolved (it is not resolved)?
2013-06-26 14:17   
Add check for too small distances between loops of edges during edge's reordering.

Branch CR23746 is ready to be reviewed.

Dear GKA,
Please review.
2013-07-18 11:12   
Fix writing TrimmedSurface (Type 144).
Fix checking for too small distances between loops of edges during edge's reordering.
Add checking for too small BSpline segments during reading and writing IGES.
Fix wire splitting by adding checking that vertexes same not only in 3d, but in 2d too.

Branch CR23746 was updated.

Dear GKA,
Please review.
2013-07-18 15:21   
In 2d space it is necessary to use tolerance vertex recomputed through resolution surface.
2013-07-18 15:46   
Dear GKA,
Thank you for your remarks, branch CR23746 was updated.
Please review.
2013-07-18 15:49   
Branch CR23746 is ready to test.
2013-07-18 15:50   
Branch CR23746 is ready to test.
2013-07-19 14:17   
Dear BugMaster,

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

http://occt-tests/CR23746-master-occt/Debian60-64/summary.html [^]
http://occt-tests/CR23746-master-occt/Windows-32-VC9/summary.html [^]
de iges_1(001) A4, A5, A6, A8, D1, H2, H5, H7, I2, J2, J3, K2, K3, K4, K8, L5, L9, N3, N4, O4, P7, Q2, R4, R6, R7
de iges_2(002) A1, A5, B2, B3, B8, B9, C2, C3, C5, D3, E6, G2, G8, I9, J1
de iges_3(003) A4, A5, A7, B1
de step_1(004) E3, E6
de step_5(008) A1

http://occt-tests/CR23746-master-occt/Debian60-64/summary.html [^]
http://occt-tests/CR23746-master-occt/Windows-32-VC9/summary.html [^]
de iges_1(001) I7, K6, K7, M9, R1
de iges_2(002) A2, C9, D1, F1, F8, G3, G6, G9, H5, H6, I8
de iges_3(003) A3, A6

Testing cases:
bugs iges(003) bug23746
It is neseccary to correct bugs iges(003) bug23746 : it is OK with fix and it is OK without fix.

Testing on Linux:
Total MEMORY difference: 355360276 / 355650848
Total CPU difference: 47580.30000000041 / 40205.49000000056

Testing on Windows:
Total MEMORY difference: 418366672 / 418133236
Total CPU difference: 29330.5 / 27771.046875

There are not differences in images found by testdiff.
2013-07-23 14:12   
Dear MKV,

All regressions were analyzed and the results are:

iges_3 A5: because of new check for too small bspline segments (one knot) some faces didn't lost, so number of them after second reading became more, than in reference data.

step_1 E3:one of wires wasn't splitting (it really shouldn't splitting) due to changes in shape healing.

step_3 E6, step_5 A1:some wires weren't splitting, so appropriate faces weren't splitting too.

Other tests failed because of difference in numbers of vertices, edges and shared edges between reference and current data, this is due to the fact that after fix some couples of edges can be reading from IGES like seams and some edges aren't lose because of checking for too small bspline segments.

So I think, that these tests are not regressions, but correct behavior.

Test case OK without fix because it should be
"param write.iges.brep.mode Faces", please check it.
2013-07-23 19:20   
All testing cases with regressions and improvements were corrected according to new reference data.
Test case bugs iges bug23746 - OK (modified).