Fri, 05/06/2011 - 09:48
We have a problem importing IGES files generated by Pro/E that contain 508, 510, 514 surfaces. A simple example is in 'test03_bad.iges'. This example is a flat circle created by a circular trimming curve applied to a flat plate. When we load this file into OCCT, either within our software, or using the precompiled ImportExport sample program on windows, we see the two component pieces: the square and the circular trimming curve.
However, if we load this IGES file into the Rhino CAD tool and save it using their 'default' variation of IGES, we get a file that can be loaded into OCCT. This file is based on 126, 128, 141, 143 surfaces. It is test03_good.iges.
I am looking for some help with this. I want to understand what is wrong with the "_bad" version of the file. It is produced by Pro/E and can be read/written using Pro/E and other CAD tools. So I assume it is valid, or at least mostly valid. Is there something we need to do (ie another method to call) with OCCT so that we can read the "_bad" version of the file. If someone has OCCT 6.5 could they see if it will read it and display it correctly?
thanks,
Tod
Fri, 05/06/2011 - 09:48
here is the good version of the file
Fri, 05/06/2011 - 12:01
I just installed OCCT 6.5 and tested our application. The "bad" file is still bad.
Fri, 05/06/2011 - 12:45
Hello Tod,
if you do not want to import the square used for construction you can set the ReadVisible flag to true on the IGES reader:
IGESCAFControl_Reader aReader;
aReader.SetReadVisible( Standard_True );
This should work in all mentioned OCC versions.
I hope this is what you are looking for.
Best regards
Markus
Tue, 05/10/2011 - 22:24
Markus,
thanks for the information. The initial tests for this look good. We will try it with more models to make sure.
I have a few related questions:
Are there any risks or undesirable behaviors?
Why isn't this mode the default?
Most of the trimmed surfaces we have seen have loaded fine without this flag. Can you help me understand why it is necessary in this case but not most?
thanks,
tod
Wed, 05/11/2011 - 17:34
Unfortunately, I don´t know any answers to your questions and I would be eager to see them answered for myself.
I made this mode the default in my own application and didn´t have any problems so far. But I have only few data samples (20-30) to test with and only 2 or 3 have these kind of shapes.
Wed, 05/11/2011 - 23:18
Let me suggest some comments.
The blank flag attached to an IGES entity is meant to mark the entity as invisible. The use of this flag is sending system-dependent. For instance, a CAD system may store the construction elements (such as rotation axis or a contour generating a prism) along with the final 3D models and attach a blank flag.
The Open CASCADE importer may convert or ignore such elements depending on the parameter IGESControl_Reader::SetReadVisible(). Though, indeed, it would rather make more sense to ignore blank entities by default, it was not set for whatever legacy reasons and now has to be kept to preserve consistency with prior versions. You may set to another value in your app though.
The reason you see no difference in majority cases is that most files do not contain blank entities.
Hope this helps.
Roman
---
www.cadexchanger.com
Tue, 05/10/2011 - 10:53
Hi Tod,
I would like to inform you that the posted problem is checked and reproduced.
The corresponding issue with ID = OCC22485 has been registered.
Later you can know if the issue is resolved by checking references to the specified ID in OCCT Release Notes. The analysis of the issue will take some time depending on our technical capability and availability of resources.
If you can't wait and the problem is urgent for you, you may contact us via Contact Form http://www.opencascade.org/about/contacts/.
We will try to find a solution/workaround acceptable for you.
As well as training and e-learning courses are at your disposal - http://www.opencascade.org/support/training/.
Regards
Tue, 05/10/2011 - 11:02
Hello folks,
Could you shed some details on what you see as the problem ?
As Markus correctly explained above, there are just entities with the blank status which *are* imported unless you set to disable them.
If you use DRAW:
> pload
> igesbrep test03_bad.igs t
Select 1 (visible roots only). You end up without blank entities. You can do similar C++ settings in your code.
Where is a bug in your opinion?
Thanks for clarification.
Roman