Alias to Icem Convert

[Anonymous]

In our team we work both with Icem and Alias. 

But the data-conversion is constantly an issue.

While our customers partly work with icem, a good data conversion is essential.

The edf-format by now is quite good with data-structure (Layers and Groups) and also a bit with shaders. but still trimmed surfaces always cause trouble (trim-borders are combined during translation, and because of that start to wave around causing gaps). Quite often also some (nurbs)surfaces get lost during translation (import and export).

And also I heared that the edf format isnt well supported (its actually a very old, outdated data format).

We also use catpart for exchange. But with that, the data-structure changes during translation, and shaders are not supported very well (but rather on Dassault side). While importing a catpart into alias, trimmed surfaces also often cause problems. 

Another possibility would be iges. But again, not perfect for data-structure and shaders (Iges only converts the layers but not groups). Also our problem with iges is rather in Icem than in Alias.

I guess, the conversion problems in detail are already reported in this forum.

Is there may be an other option we didn’t thought about yet?

Or, is it considered to build up a specific converter for icem-data (.icem format)?

Most important for us, is actually lossless surface and curve translation. And at least some support of data-structure (layers/groups in Alias vs. parts/molecules in Icem)

kind regards

David

[カワダチアキ]

Hi @Anonymous,

If you haven't, please update your Alias to 2019.1 and check whether your issues are solved.

As you can see from the following release notes, some EDF issues were resolved recently.

Release note for 2019

http://download.autodesk.com/us/alias/2019/alias_2019_readme_enu.htm

Release note for 2019.1 

https://up.autodesk.com/2019/ALAUST/alias_2019.1_readme_enu.htm

[Anonymous]

Hallo ChiakiKawada

The trouble we have with the edf are actually since a long time. But I also recently checked in Alias 2019.1 and its still the same.

All g1-continuous trim-boudaries joined into one. That causes tiny gaps in the trim-boundary, usualy smaller 0.002mm, but also up to 0.01mm. 

Sounds very small, but for Class-A we usually need surfaces matching on 0.001mm.

Also creating shells in Alias, or joins in Catia always struggles on edf trim-boundaries.

Also edf always causes trouble with nurbs-surfaces, usually in Icem.

And edf-support is said to be discontinued in Icem. At least that's what we heared.

Therefor we search for an alternative.

kind regards,

David

[rauscht · Accepted solution]

Hi David,

sorry to hear that you are facing problems with our data translation framework. There is a lot truth in what you are reporting. Allow me to comment on some details.

All our translators are subject of permanent improvements. With every update release of Alias you will see improvements in specific areas of the data translation problem. As we need to deal with several external data formats (some of which only poorly documented and not owned by Autodesk), and several different geometrical set-ups using different data tolerance models, (and, and, and,) it will however remain a difficult task which probably will never be completely finalized. Apologize for that.

As you already described, the EDF format is a pretty old one which is not properly documented (if at all). Most of the problems we are facing here are related to tolerances (especially in the area of Curve on Surfaces and Trim curves). Over the past releases, we were constantly working on those problems and will continue to do so. However, we are hearing rumors from the ICEM  community that they might discontinue the support of that format. I am not in a position to comment on this and will leave it as is: as a rumor.

The .icem format is a non-open file format, i. e. it is not documented t all. Also, Dassault is not providing an API to take access to .icem files. In other words: there is no way for us to provide our users with an Icem converter, I am afraid to say.

One of our biggest invests in the near future will go into the improvement of the Catia V5 import / export mechanism. Specifically in the area of structural data (like layers and groups) there will be some improvements in. Having this in mind, probably the best strategic decision in your case would be to use Catia V5 format in the future.

Hth

Thomas

[Anonymous]

Hi Thomas,

thanks for the detailed reply. 

That really answers a lot questions. 

We probably now switch to CatPart for Data-Exchange. We testet in the last few weeks more intensly. With all the improvements on that translator with the last few releases, this is best way to go. Surface-Quality wise it seems best already. Thank you, guys!

kind regards

David