3D Interoperability

[rbagley]

---

RV wrote:
In fact it misses PMI of non-semantic type (CatiaV5)

---

RV,

Do that many design organizations really use non-semantic PMI? 

It seems to me that the big push when 3D PMI was developed was focused on being standards-based, to eliminate the problem of non-conforming (and thus non-manufacturable) PMI coming from uncontrolled 2D drawing environments.  When Dassault first created 3D PMI (I think it was called FD&T then), the user was prevented from creating arbitrary non-compliant tolerancing.  Why do you think there has been a shift to allow non-semantic PMI?  It seems to me like a concession to the lazy or uninformed who don't want to work within the standards -- but perhaps that's too harsh and I am uninformed about the value.  I've been out of the manufacturing industries for a few years now and could be too out of touch.

Thanks,

Ray

[shailesh]

Healing is optional in both legacy and connect for all the translators. It is 'ON' by default for all the translatorts. In healing, we have 2 types : systematic healing and optional healing. The systematic healing ensures that we produce  valid ACIS/Generic models albeit with check errors. This treatment is not optional.

 Can you please tell us the problematic 2 translators for which the healing can not be turned off ?

[reswaran]

If you look in Interop Connect documentation, you will find an "N" against Pro/E and solidworks.

[reswaran]

This comes as a surprise:

"In healing, we have 2 types : systematic healing and optional healing. The systematic healing ensures that we produce valid ACIS/Generic models albeit with check errors. This treatment is not optional."

Has this been documented anywhere? I don't see anything along these lines mentioned anywhere.

There is a need for all of healing to be an option for the following reasons:

1. ACIS has a gamut of healing tools and not healing during translation will help demonstrate ACIS's ability (with its highest precision in the modeler market) to deal with "crap" from other systems. Spatial customers who don't want to deal with this can simply turn healing on in Interop.

2. It is NOT necessary that the translated geometry be used for ACIS modeling operations.So sometimes there is no necessity to produce valid ACIS models.

3. Having the option to turn healing off brings us closer to the "real data" even if there are fundamental topological/geometry problems in the "source" file because of bad design or because of the source system's inept modeler. With Interop's "blackbox" healing approach there is no way for us to ascertain what data in the original file was changed and why.

I know this is not going to be a 100% possible mainly because of procedural surfaces and curves. As far as I know Interop reads procedural data from other formats as B-Spline approximations. So a "blend surface" in Solidworks does not read in as an ACIS blend surface but as a B-Spline surface. It would be nice to have the ability to read procedural definitions but that is a different and more complex issue. Some other translation vendors support this capability although they require a much tighter intergration.

[reswaran]

I would think that making the individual part translation faster will in turn improve the performance of assembly translation? Sorry if I am misunderstanding the question?

[reswaran]

No response?

[rbagley]

---

reswaran wrote:

I would think that making the individual part translation faster will in turn improve the performance of assembly translation? Sorry if I am misunderstanding the question?

---

Yes it would, but there may also be strategies for speeding up assembly translation without necessarily improving single-part times.  Hence, the question of priority.

[oklaar]

For us, faster translation is one of the top-priorities, too.

[PeterN]

For us it would be better to speed up part translation in favor of assembly translation.

[PaulS]

From a user of the Parasolid Win32 SKU of the libraries:

1. Redistrubutables (e.g. Windows msi files) that I can integrate with my application installer.  Per importer, per reader/writer
2. ACIS, Inventor (including older versions and assemblies) and SolidWorks support (slated for R18 SP1, I believe).
3. Plugged memory leaks - they are not all "false" MFC reports, not by a long chalk
4. Thread safety
   
5. Better diagnositic messages in log files – “No entities to translate” seems to cover a multitude of sins
6. Better return codes – 15 does not provide adequate detail
   
7. Statistics detailing what cleaning/ healing was performed
8. Tolerance of bad data:  throwing bad data at the importer should not cause a crash - until then I'll have to continue a dirty great try/catch around Spatial code
   
9. Then make is faster.

PaulS