Integrating 3D InterOp into a CAD Application

By Bikash Parida, Developer

The most common example of use of an 3D InterOp product in a CAD application is to import CAD files of various formats into its own format. Then the entities in the application are edited in some way, and possibly exported back to original CAD format.

If the user application is developed on top of ACIS or the Parasolid kernel, InterOp provides straight forward APIs for this workflow. The CAD file is converted directly into live entities and then those entities are directly used for further processing in the application. The entities changed by the application can then be directly exported to other file formats. Since the translation is in-memory and the same entities are used by InterOp and the kernel of the application, the version of InterOp must be compatible to the version of kernel used. For example, if the application is using ACIS R20, then InterOp version has also to be R20.

There are situations where this version compatibility requirement is not desired. For example, the application developer does not want to perform the work required to update to every ACIS kernel version released, but does want to keep up with new InterOp versions in order to take advantage of the latest version support , to use new functionality like Assembly PMI, or just for getting critical bug fixes. In this case the solution is to use the file-to-file translation capability of InterOp. The workflow will be to call the CreateProcess windows API (or a combination of fork and exec on Unix) from the application to spawn a separate translation process, and then translate a single CAD file to the correct ACIS or Parasolid file (by using SaveVersion InterOp option to back save file). The final step is to read back from that ACIS or Parasolid file into the application to get live entities and proceed further.

Another example where the common in-memory ACIS/Parasolid APIs won’t be useful is when the application kernel is not ACIS or Parasolid, but the application still needs to translate to and from that kernel. In that case, they can write their own reader or writer component by implementing InterOp CSDK interfaces. Then the component will work as seamlessly with InterOp as any other natively supported file format.