IFC

String data within IFC is always in UTF-8 format, so when you get string using getAttr, the string is in UTF-8, and when you putAttr a string, SDK assumes the string is in UTF-8 format. Such UTF-8 data is implicitly converted into so-called Control Directives ('\X\C4\X\EF\X\EA\X\DC\X\F1\X\E9\X\E1') when writing Step Physical File, and converted from Control Directives into UTF-8 when reading Step Physical File.

UTF-8 -> putAttr -> writeFile -> Control Directives -> readFile -> getAttr -> UTF-8

So when you are working with string data, OdString and OdAnsiString can be used in pair for conversions:

OdString wStr("АБВГДЕЁ");

OdAnsiString ansiStr(wStr, OdCodePageId::CP_UTF_8);

inst->putAttr("string_value", ansiStr); // or inst->putAttr("string_value", ansiStr.c_str());

_writeSpf(model, "file.ifc"); // .ifc file will contain ansiStr data converted into internal representation (Control Directives) of such strings

...

_readSpf("file.ifc", model);

inst->getAttr("stringValue") >> ansiStr; // UTF-8 string with original data

OdString wStr(ansiStr, CP_UTF_8); // WChar string

If there are no colors on facets, this means colors weren't assigned to faces during FacetModeler::Body creation. Probably there is no such information in IFC file (e.g. style is assigned to full body, not to every single face), or we don't process such case currently, so it would be helpful if you provided such file to us.

Units information can be accessed through IfcProject.UnitsInContext attribute using C++ API in following way:

// 1. Using OdIfcFile
OdDAIObjectId idProject = pIfcFile->getProjectId();

// 2. No OdIfcFile way, work with model only
OdDAI::ModelPtr model = pIfcFile->getModel();
const OdDAIObjectIds &projectExtent = model->getEntityExtent("ifcproject")->getArray();
if (projectExtent.size())
{
  idProject = projectExtent[0];
}

if (idProject.isValid())
{
  OdDAI::ApplicationInstancePtr project = idProject.openObject();

  OdDAIObjectId idUnitsInContext;
  project->getAttr("unitsincontext") >> idUnitsInContext;
  if (idUnitsInContext.isValid())
  {
    OdDAI::ApplicationInstancePtr unitAssignment = idUnitsInContext.openObject();
    OdDAI::Set *units = nullptr;
    unitAssignment->getAttr("units") >> units;
    if (!units->isNil())
    {
      for (const OdDAI::Select &selUnit : units->getArray())
      {
        OdDAIObjectId idUnit = selUnit.getHandle();
        OdDAI::ApplicationInstancePtr unit = idUnit.openObject();

        const char *unitType = nullptr;
        unit->getAttr("unittype") >> unitType;

        const char *prefix = nullptr;
        unit->getAttr("prefix") >> prefix;

        const char *name = nullptr;
        unit->getAttr("name") >> name;

        oddaiPrintConsoleString(L"\n#%u=%hs:\n UnitType: %hs\n Prefix: %hs\n Name: %hs\n",
          (OdUInt64)idUnit.getHandle(), unit->typeName().c_str(), unitType, prefix, name);
      }
    }
  }
}

Yes, Derived Attributes and Where Rules evaluation is supported by EXPRESS interpreter (ISO 10303-11) which is a part of ODA IFC SDK / SDAI.

The main initialization procedure is the same as for IFC SDK C++ API usage:

// Common ODA IFC SDK initialization part
OdStaticRxObject<MyServices> svcs;
odrxInitialize(&svcs);
odIfcInitialize(false /* No CDA */, false /* No geometry calculation needed */);

// SDAI calls can be performed just after common initialization procedure
SdaiSession session = sdaiOpenSession();
SdaiRep repo = _sdaiCreateRepositoryFromFile(session, "c:\\file.ifcXML", "");
SdaiRep repoOpened = sdaiOpenRepositoryBN(session, "c:\\file.ifcXML");
SdaiModel modelRO = sdaiAccessModelBN(repoOpened, "default", sdaiRO);
SdaiSet cartesianPoints = sdaiGetEntityExtentBN(modelRO, "IfcCartesianPoint");
SdaiIterator it = sdaiCreateIterator(cartesianPoints);
for (sdaiBeginning(it); sdaiNext(it);)
{
  SdaiAppInstance inst = nullptr;
  sdaiGetAggrByIterator(it, sdaiINSTANCE, &inst);
  ...
}
sdaiDeleteIterator(it);
sdaiCloseSession(session);

// Common ODA IFC SDK uninitialization part
odIfcUninitialize();
odrxUninitialize();

exSDAISAS example which uses SDAI calls may be investigated additionally to get information of how to create modules which use SDAI.

Two following SDAI extension functions are declared in sdai.h header:

SdaiInstance _sdaiHeaderDescription(SdaiRep repository);
SdaiInstance _sdaiHeaderName(SdaiRep repository);

Then attribute values of instances can be accessed using standard sdaiGetAttrBN/sdaiPutAttrBN functions.

The third instance of FILE_SCHEMA type can’t be accessed and is filled automatically when writing repository to file.

ODA IFC SDK supports ifcXML2X3 format since version 22.6.

Yes, it is possible to save metadata in VSF. Presence of metadata in file does not have influence on visualization performance.

Open IFC Viewer supports opening of IFC (text file format known as Step Physical File), ifcXML2X3 and HDF5 (consider it as binary IFC) files. All three types of files can be packed into IFCZIP which is also supported. Open IFC Viewer supports working with BCF (BIM Collaboration Format) files. Oda Viewer additionally allows to open all formats we support, as .dwg, .dgn, Revit, Navisworks, STL, OBJ.

IFC SDK provides access to explicit/inverse data of model, visualization. Visualization data can be used for such calculations on customer side.

Open Cloud VisualizeJS libriry is based on Visualize SDK (recompiled to javascript with emscipten). So there is no difference, but sometimes there is small delay with appearing new functionality.

Open IFC Viewer is available for download for free. As for our other viewers - those are and may be used as examples to build your own ones.

Here’s a link to the IFC Viewer: https://openifcviewer.com/

Yes, we have such wrappers (please note, that you need Kernel and IFC archive as well).

Yes, inverse relationships are calculated just after is file opened.

All types of IFC entities of a building model can be created using IFC SDK. Customers have access to all data from IFC file and can fill file with all data, which is described by IFC schema.

Yes, we support IFC advanced brep from IFC format, ifc faceted brep, Boolean operations and cut planes, extrusions and so on, explicit geometry.

Yes, we have tested our alignments implementation with files we get from Civil.

We have implementation for ODA Facet Modeler, which operates faceted geometry. It’s working also as a part of Drawings SDK, so it keeps Facet Modeler bodies in appropriate state, it controls topology and geometry mainly, more to say just after opening the file if geometry needed we repair incorrect topology in geometry, if can.

We also use ODA Facet Modeler is our base implementation at the moment, but usually it works together with ODA Solid Modeler and particularly for generation geometry for different sweeps of IfcRoad.

Yes, in our module IfcGeometry we get all data from IFC file and NURBS geometry in particular and convert in to GUI curves, so we support NURBS geometry, yes, and curves, and subfaces.

Yes, you can access any data from IFC model using one of API provided. So, you don’t have to draw it, you can just get .ifc composing points, extrudes, explicit or implicit geometry and work with it without visualization and vectorization.

At the moment Open IFC Viewer can convert to .pdf, but using Visualize SDK IFC files loaded in Visualize database can be converted to STL and many others formats. So, conversion can be performed programmatically using Visualize SDK.

Yes, we’re working with the files from BuildingSMART.

Common data access way to data is high level to late bounding and it can be used without binding to any format: IFC or not. For example, you can access to common data access tree hierarchy without knowledge of any IFC classes.

When we started to support loading of IFC 4 we cannot generate geometry in early-bound style, because we have to work with different set of classes. So IFC wall in 2x3 scheme is different class of IFC wall of IFC 4 scheme and we decided to implement late-bound working with SDK to have the same code for geometry generation.

And of course this is quite simple to use late-binding importing data from IFC to application as the same code – this is main advantage.

At the moment the Kernel and SDAI part is a base for IFC SDK and no any relation to other ODA SDKs.

The example of how to get geometry of IFC file is called ExIfcVectorize.

Pay attention to content of TOOLKIT_IN_DLL defines in each main .cpp of examples. There is an initialization of modules needed in static:

#ifndef TOOLKIT_IN_DLL
INIT_IFC_STATIC_MODULES_NO_GEOM;
#endif

and

#ifndef TOOLKIT_IN_DLL
ODRX_INIT_STATIC_MODULE_MAP();
#endif

So in md configuration each module should been previously initialized for our rt linker can work with them. Seems your problem related with this initialization.

You can get OdDAIObjectId of an entity instance and then get a # from it if needed:

OdIfcEntityPtr pInst = ...; // or IfcWallPtr pWallInst = ...;
OdDAIObjectId id = pInst->id();
OdDbHandle h = id.getHandle();

Yes, current IFC4.3 is supported by ODA IFC SDK.

Method const OdAnsiString& OdDAI::ApplicationInstance::typeName() const; returns a type name of application instance.

The only way to get information about attribute type at the moment is to case in following way:

OdArray<OdDAI::AttributePtr>::iterator nextAttribute = leftEntityAttributeFilter.begin();
    for (; nextAttribute != leftEntityAttributeFilter.end(); ++nextAttribute)
    {
      OdDAI::AttributePtr pAttrib = *nextAttribute;
      OdDAI::InverseAttributePtr pInverse = OdDAI::InverseAttribute::cast(pAttrib);
      if (!pInverse.isNull())
      {
        odPrintConsoleString(L"\nInverse attribute `%s` (%lu)", pInverse->name().c_str(), (OdUInt64)leftIterator->id().getHandle());
      }
    }