Open Inventor can read the following CAD file formats:

In order to read these files, you need to acquire a license of the appropriate CAD format from FEI and to install it on your system.

When importing one of these files, part names will be imported too. But you must keep in mind than as long as they are imported directly into nodes, the Open Inventor node name limitations will be directly applied. Those limitations can be found in documentation of SoBase::setName() method. The main thing to remember is that any unsupported character is automatically replaced by an underscore ‘ _ ‘ .

Import customization

The import of a CAD file can be customized with parameters exposed in the SoCADInputReaderParameters^{( C++ | Java | .NET )} class.

Tessellation Parameters

Open Inventor allows customer to change the quality of tessellation performed during import. For these, two API are available. The simplest one is to use directly the setTessellationOption (Quality quality = MEDIUM) allowing to specify predefined tessellation options. Quality has to be chosen from SoCADInputReaderParameters::LOW, SoCADInputReaderParameters::MEDIUM, SoCADInputReaderParameters::HIGH. Logically the better the quality is, the longer the import will be.

To go deeper into tessellation customization the API provides an inner struct, called TessellationOption that allows defining

Once the option has been defined, the application may set the options using the method setTessellationOption (const TessellationOption& option)

Import option

Among the tessellation options, application can also customize which entities of a CAD file are needed to be imported and which don’t, allowing reducing import time. These options are set via the SoCadReaderInputParameters::ImportOption struct defined in the SoCADInputReaderParameters^{( C++ | Java | .NET )} class and propose following API:

Options have then to be set using the SoCADInputReaderParameters::setImportOption(const ImportOption& option) methods and the import can be made.

Structure of the generated scene graph

In order to keep things as clear as possible, the import of a CAD file into Open Inventor generates a well-structured scene graph in which the user can retrieve all the needed information.

When importing CAD file supporting multi views, Open Inventor will generate a particular sub scene graph to store information about each view. In the generated scene graph a special switch named ivModelDisplaySwitch will always be at the top of all the views defined in the original file. Changing the field whichChild of this node will change the current view rendered in the viewer. Here are some simple code examples to manipulate the switch managing the multi-view in the Open Inventor scene graph.

SoSearchAction* searchAction = new SoSearchAction;
      searchAction ->setFind(SoSearchAction::NAME);
      searchAction ->setSearchingAll(true);
      searchAction ->setType(SoSwitch::getClassTypeId());
      searchAction ->setName("ivModelDisplaySwitch");
      searchAction ->apply(scene);

      SoPath* path = searchAction->getPath();
      SoSwitch* ivModelDisplaySwitch = NULL;
      if ( path )
        ivModelDisplaySwitch = dynamic_cast<SoSwitch*>(path->getTail());
      delete sa;

// Assume the ivModelDisplaySwitch node has been retrieved before
if ( ivModelDisplaySwitch && ivModelDisplaySwitch->getNumChildren() > 0 )
{
  int curChild = ivModelDisplaySwitch->whichChild.getValue();
  int maxChild = ivModelDisplaySwitch->getNumChildren();
   
  // Use PAGE_UP to select next view. Loop over view in case 
  // we reach the last one
  if (SO_KEY_PRESS_EVENT(ev,  PAGE_UP))
  {
    if( curChild + 1 != maxChild )
      ivModelDisplaySwitch->whichChild.setValue( curChild + 1 );
    else
      ivModelDisplaySwitch->whichChild.setValue( 0 );

    eventCB->setHandled();
  } 
  // Use PAGE_DOWN to select previous view. Loop over view in case 
  // we reached the first one
  else if (SO_KEY_PRESS_EVENT(ev, PAGE_DOWN))
  {
    if( curChild > 0 )
      ivModelDisplaySwitch->whichChild.setValue( curChild - 1 );
    else
      ivModelDisplaySwitch->whichChild.setValue( maxChild - 1 );
    eventCB->setHandled();
  }
  else if( SO_KEY_PRESS_EVENT(ev, O))
  {
    ivModelDisplaySwitch->whichChild.setValue( 0 );
    eventCB->setHandled();
  }
  // Then in all case update the viewer's camera by searching the SoCamera
  // on select child.
  if( SO_KEY_PRESS_EVENT(ev, O) 
   || SO_KEY_PRESS_EVENT(ev, PAGE_DOWN) 
   || SO_KEY_PRESS_EVENT(ev,  PAGE_UP) )
  {
    SoCamera* newCamera = SearchCameraFrom(ivModelDisplaySwitch->
                          getChild(ivModelDisplaySwitch->whichChild.getValue()));
    if ( newCamera )
    {
      viewer->setCamera( newCamera );
      viewer->viewAll();
    }
  } 
} 

In the same way as themultiple views, the import of a CAD file including Product and Manufacturing Information (PMI) is managed in a sub part of the main scene graph of the Open Inventor scene. This sub scene graph is topped by a SoSwitch^{( C++ | Java | .NET )} named ivFdtSwitch. Each element of the PMI is placed under this SoSwitch^{( C++ | Java | .NET )} and will have a name prefixed with the ivFdt_ string making them easy to retrieve with a SoSearchAction^{( C++ | Java | .NET )}.

As seen before, the import process allows defining which parts of the CAD file should be taken in consideration and which must not. This result is a particular structure in the generated scene graph once the file has been opened using Open Inventor. The main part of the scene graph starts under the SoMultiSwitch^{( C++ | Java | .NET )} named ivRenderMode. This multi switch defines the list of child’s underneath SoMultiSwitch^{( C++ | Java | .NET )} will inherit of. In other words it defines which rendering modes (Faces, edges, vertex and curves) will be done. Here is an example in a simple generated scene graph.

Under the main SoMultiSwitch^{( C++ | Java | .NET )} ivRenderMode are listed, as SoSeparator, all the parts of the imported model named with Open Inventor convention and prefixed with the name of the part they belongs to.

These separators are all under a SoMultiSwitch^{( C++ | Java | .NET )} that inherits their whichChild list from the main one. By default this main SoMultiSwitch^{( C++ | Java | .NET )} will always set its whichChild list so the four modes are rendered, meaning the list is set to 0, 1, 2 and 3 at the top of the scene graph.

To remove the edge of the rendering (for example), we must remove child number 1 in the whichChild list of the main SoMultiSwitch^{( C++ | Java | .NET )} so separator won’t be traversed when edges are underneath. This is a very convenient feature allowing rendering different parts of a given models in different modes very easily (the main SoMultiSwitch^{( C++ | Java | .NET )} can be retrieved using a SoSearchAction^{( C++ | Java | .NET )} with its very specific name)