How to import SOLIDWORKS (or Parasolid, JT, NX, Creo) files into Open CASCADE

Learn three techniques to let your OCC-based app support a broader range of 3D file formats. A single line of code would be enough, whether you use only OCC topology, XDE or your own meta-data.

Roman Lygin
Roman Lygin
6 min read

Rotor Open CASCADE model
Rotor Open CASCADE model

What is Open CASCADE

If you are reading this blog post, you most likely already use Open CASCADE in your app and are well familiar with it. For those who are not, Open CASCADE is an open-source modeling kernel which can be used as a foundation to build 3D apps. In that sense, OCC competes with commercial kernels such as Parasolid, ACIS, CGM, or C3D.

OCC has data structures to describe 3D models with precise B-Rep and various API to perform modeling operations (fillets and chamfers, Boolean operations, etc.). For the last 20+ years the OCC company has been focusing on rendering custom development services. So development of the kernel is mainly driven by those customer projects. Although some core modules are mainly in the maintenance mode, the kernel can still be a viable option for businesses evaluating the development platform for their apps.

CAD file formats supported by Open CASCADE

Out of the box, OCC supports a few neutral file formats, including IGES, STEP, STL, VRML. As paid add-ons, the OCC company offers interfaces with Parasolid, ACIS, DXF, JT. When I worked at the OCC company in the late 1990s and early 2000s, I led the engineering team which owned the development of many of those components, and I contributed lots of C++ code thereto myself. That’s when my passion for CAD data exchange started and over time drove me to start CAD Exchanger and founding the CADEX company in the early 2010s.

CAD Exchanger components vs Open CASCADE’s

In some sense, CAD Exchanger certainly overlaps with those ‘native’ offerings. However, our focus at CADEX is primarily CAD data conversion and doing it right and most efficiently, so we invested a lot into our own implementations. Whereas the OCC company switched to service-oriented business in the early 2000s and therefore has to be driven by on-demand customer projects, our primary focus is product development.

We have to have a long-term predictable R&D roadmap, invest a far greater amount of human talents into product development, and be more responsive to numerous corner cases reported by our customers. Those focused efforts result in a broader amount of formats (20+ at the time of this writing), a broader range of format versions, more efficient implementations (including two hold patents related to parallel computing), and eventually quality. With millions of users using CAD Exchanger-based applications, the stream of CAD files going through CAD Exchanger codes is in dozens of millions every year! That challenge does require us to provide world-class CAD data converters in order to be a successful sustainable business.

We have multiple clients who decided to base their apps on Open CASCADE and they use some of the techniques described below to take advantage of the two worlds – OCC and CAD Exchanger.

Integration of CAD Exchanger into an OpenCASCADE-based app

With CAD Exchanger SDK, every developer using OCC to develop his/her application has an option to support a broader range of 3D file formats and thus to make the application more appealing to the end-users. And this integration is truly seamless and only takes a few lines of codes, and minutes.

Let’s consider some technical details.

How to read SOLIDWORKS file into Open CASCADE

Let’s take an example of how you could import a SOLIDWORKS file into your Open CASCADE-based app. (Instead of Solidworks, you could read NX, Creo, JT, IFC, or any other supported file format). It only takes a single line of code to replace the respective reader class (with NX_Reader, Creo_Reader, JT_Reader, and so on).

Option 1. Topology and geometry only

If you work with OCC at the level of geometry and topology (feel free to check out my older blog posts series explaining this vital difference), then you must be using the TopoDS_Shape base class instance as a primary object holding your topological tree.

In this case, your simplest code might look as follows:

#include <cadex/SDL_Reader.hxx>

cadex::SLD_Reader aReader;
TopoDS_Shape aShape;
if (!aReader.ReadFile (“myfile.ldprt”s) || !aReader.Transfer (aShape))
    //some error happened
    return false;
//here aShape contains a full OCC shape

Option 2. Open CASCADE XDE If your OCC-based application uses XDE (eXtended Data Exchange), an OCAF (Open CASCADE Application Framework) extension, then you can import a SOLIDWORKS file into your XDE document very much like with the previous approach. The only difference is to convert an instance of cadex::ModelData_Data into OCC’s TDocStd_Document instance.

In this case, the contents of the CAD Exchanger model will be appended to the contents of aDoc: the assembly structure, colors, names, layers.

//convert CAD Exchanger document to OCC XDE document
Handle(TDocStd_Document) aDoc = ...; //
cadex::ModelXDE_Converter::Convert (aModel, aDoc);

Option 3. Open CASCADE topology and your own meta-data If your application works with meta-data (id’s, names, colors, materials, etc.) but you do not use XDE, then probably you have your own C++ classes that bind meta-data and OCC topology. In this case, you will just need to traverse the CAD Exchanger document and retrieve both the OCC topology and meta-data.

The following code snippet demonstrates how this could be done.

class SceneGraphVisitor : public ModelData_Model::VoidElementVisitor
    void operator() (const ModelData_Part& thePart) override
        auto aBRep = thePart.BRepRepresentation();
        if (aBRep) {
            const auto& aRootList = aBRep.Get();
            const TopoDS_Shape& aShape = aBRep.ToOCC(); //convert to OCC shape
            Base_UTF16String aName = thePart.Name();
            //bind aShape and aName in your data structures...

SceneGraphVisitor aVisitor;
aModel.Accept (aVisitor); //traverse model and retrieve data

Exporting Open CASCADE data into CAD files

Writing Open CASCADE geometries into external CAD files (e.g., JT, or Parasolid, ACIS, etc.) is done very much like reading, considered above. Depending on your preferred usage of OCC API (TopoDS_Shape only, XDE or mix with your own API), you basically just need to perform the workflow opposite to reading – create and populate cadex::ModelData_Model object and feed it to the cadex::JT_Writer (or alike) instance:

TopoDS_Shape aShape = ...;
cadex::ModelData_Model aModel;
cadex::ModelData_ShapeConverter::Add (aShape, aModel);

cadex::JT_Writer aWriter;
if (!aWriter.Transfer (aModel) || !aReader.WriteFile (“myfile.jt”)) {
    //some error happened
    return false;

Benefits of CAD Exchanger

If you decide to consider using CAD Exchanger SDK with Open CASCADE then here are a few key benefits you might expect to get:

  • Truly seamless integration. It takes less than 5-10 lines of C++ code as explained above. Overall, perhaps sometimes it can be even more compact than using native OCC converters.
  • Single API. The conversion between CAD Exchanger SDK and OCC objects is totally format-agnostic. So if over time, you want to add new formats (e.g., NX after Solidworks) that will take a couple of extra lines (to add cadex::NX_Reader). We plan to achieve that extra amount to be zero (yes, zero!). In that case, even recompilation will not be required!
  • Single vendor. As I said, data conversion is our core business and our core architecture is shared across all formats. Although you can mix CAD Exchanger-based components with native OCC, preferring the former gives you consistent behavior, user experience, and benefits (such as delayed loading, CPU multi-threading, etc.). Price-wise, this can be even zero extra cost – e.g., when using our bundles, you get access to all formats.
  • Support. Again, due to very different business models, it is in our best interests to keep the quality of the converters as high as possible. So whenever you might encounter a very specific corner case, that report immediately goes into our tracker and will be picked up during upcoming development sprints.
  • Performance and Quality. Multi-core parallelism was my second professional passion (developed during ten years work in Intel software group), and multi-threading and high performance were in the DNA of CAD Exchanger from day one. We received two patents related to parallel computing, and this parallelism is part of the core architecture. Therefore even those overlapping formats (e.g., STEP, IGES, etc.) are implemented in a much more scalable way than legacy OCC codes. However, I remain fully open to counter-examples: if you come across any file where CAD Exchanger will demonstrate weaker results, drop me a line and our team will gladly review.


As you have seen, integrating CAD Exchanger SDK with your Open CASCADE based app is really seamless and does not require any significant effort. The SDK comes with numerous examples demonstrating the above OCC-focused scenarios as well as many others dedicated to exploring the model (assembly structure, geometries, meta-data), working with PMI (Product and Manufacturing), generating meshes, visualizing 3D models and many more.

Should you have any questions on this topic or any other, feel free to drop me an email at roman dot lygin at cadexchanger dot com. Either myself or my support team will be happy to help.

Thanks for reading!

Roman Lygin
Roman Lygin
Founder & CEO
Roman is a CAD industry veteran since 1997. After working at Open CASCADE and Intel companies, he founded CADEX in 2014. CAD Exchanger now empowers millions of end-user seats and helps professionals in 110+ countries to communicate in the multi-CAD world. Although Roman's time is now mainly spent on business and operations, he is still actively involved into product development and customer support.

Get the CAD Exchanger Newsletter

From us to your inbox weekly.