Importing IFC models

As noted in previous tutorials, HOOPS Native Platform uses HOOPS Visualize for rendering, HOOPS Exchange for importing model files, and HOOPS Publish for exporting to 3D PDF. We will begin this tutorial by loading an IFC model using the HOOPS Exchange importer. If needed, please refer to the sandbox walkthrough for additional details on the import process.

The sandbox imports models with a default set of options, but for this tutorial, we’re going to change some of those options to ensure we import the IFC-specific attributes we need. To do this, we’ll use the HPS::Exchange::File::Import method with an appropriate ImportOptionsKit.

The ImportOptionsKit is where you specify which data you want to import from your model file. Example options would be things like B-rep, PMI, configurations, and other attributes. HOOPS Exchange can import both B-rep and tessellated data from many industry-standard file formats. However, in the case of IFC, only tessellation is available. Therefore, for SetBrepMode() we’ll just select tessellation. We will also ask for all IFC metadata to be loaded with the model, which we will need to access later in this tutorial. If the option is not set, only IFC object GUIDs will be returned.

If you open CHPSDoc.cpp from the sample project, and find ImportExchangeFile(), you’ll see how these function calls fit in to the rest of the application:

		HPS::Exchange::ImportOptionsKit ioOpts = options;

Once the options are set, we are ready to run the project and load the sample model, samples/data/ifc/Duplex_A.ifc.

    // get the filename and the file format
HPS::UTF8 filename(lpszPathName);
HPS::Exchange::File::Format format = HPS::Exchange::File::GetFormat(filename);
// special case for CATIA V4 files
HPS::UTF8Array selectedConfig;
HPS::Exchange::ConfigurationArray configs;
if (format == HPS::Exchange::File::Format::CATIAV4
    && !ioOpts.ShowConfiguration(selectedConfig)
    && !(configs = HPS::Exchange::File::GetConfigurations(filename)).empty())
    // If this is a CATIA V4 file w/ configurations a configuration must be specified to perform the import.
    // Since no configuration was specified, we'll pick the first one and import it, otherwise, the import will throw an exception.
    getConfiguration(configs, selectedConfig);
// a progress dialog is created
CHPSExchangeProgressDialog dlg(this, notifier, filename);
// here is where the model file is read
notifier = HPS::Exchange::File::Import(filename, ioOpts);

You’ll notice the value returned from File::Import is a notifier. This is an important object which informs on the status of the import operation, and is discussed in the HOOPS Visualize Programming Guide section on file I/O.

Component hierarchy

Model files are represented in memory by a hierarchical scene graph where the nodes of the scene graph roughly correspond to features of the model. Each node in the scene graph is known as a component.

CAD files (those models loaded by HOOPS Exchange) are just one type of component hierarchy. Before working with any type of model on your own, make sure to read the Component hierarchy section of the HOOPS Visualize Programming Guide. That section explains how model files are structured in general. For CAD models loaded by HOOPS Exchange, more details can be found in the Exchange Component classes section.

The short summary is that each HPS::Component is an abstraction which corresponds to a native HOOPS Exchange type. In particular, turn your attention to the following types:

  • HPS::Component::ComponentType::ExchangeModelFile

  • HPS::Component::ComponentType::ExchangeProductOccurrence

  • HPS::Component::ComponentType::ExchangeRIPolyBRepModel

Under the hood, these values are enums, and each component is assigned one based on its type. The values listed above represent an imported CAD model root node, assembly node, and tessellated 3D model, respectively. There will only ever be one component of type ExchangeModelFile which repesents the root of the CAD model component hierachy and contains important information about the model file. There may be many objects of type ExchangeProductOccurrence and ExchangeRIPolyBRepModel, depending on how the model file was authored.

Product occurrences define a hierarchy of objects, with the PolyBrepModels as leaf elements used to define the 3D geometry. Each of these objects will have attached metadata which determines what IFC object type each Component object corresponds to. We’ll be looking at accessing the metadata in the next section.