L’IFC

Deux fonctions d'extension SDAI suivantes sont déclarées pour l’en-tête sdai.h:

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

Ensuite, les valeurs d'attribut des instances sont accessibles à l'aide des fonctions standards sdaiGetAttrBN/sdaiPutAttrBN.

La troisième instance de type FILE_SCHEMA n'est pas accessible et est remplie automatiquement en ecrivant un référentiel dans un fichier.

Oui, il est possible d'enregistrer des métadonnées dans VSF. Les métadonnées présentes dans le fichier n'affectent pas les performances de visualisation.

L’Open IFC Viewer prend en charge l'ouverture des fichiers IFC (format de fichier texte connu sous le nom de fichier physique Step), IFCZIP et HDF5 (considérez-le comme un fichier IFC binaire). Nous allons également apporter la fonctionnalité BCF pour l’Open IFC Viewer prochainement. ODA Viewer permet en outre d'ouvrir tous les formats que nous prenons en charge .dwg, .dgn, Revit, Navisworks, STL, OBJ.

Le SDK IFC donne accès aux données explicites/inverses du modèle, de la visualisation. Les données de visualisation peuvent être utilisées pour de tels calculs côté client.

La bibliothèque Open Cloud VisualizeJS est basée sur Visualize SDK (recompilé en javascript par emscipten). Il n'y a donc pas de différence, mais parfois de nouvelles fonctionnalités arrivent un peu tard.

L’Open IFC Viewer est disponible en téléchargement gratuit. Quant à nos autres utilsateurs, ceux-ci sont et peuvent être utilisés comme exemples pour construire les vôtres.

Voici un lien vers la visionneuse IFC: https://openifcviewer.com/

Oui, nous avons de tels wrappers (veuillez noter que vous avez également besoin d'archives Kernel et IFC).

Oui, les relations inverses sont calculées dès que le fichier est ouvert.

Tous les types d'entités IFC d'un modèle de construction peuvent être créés à l'aide de l’IFC SDK. Les clients ont accès à toutes les données du fichier IFC et peuvent remplir le fichier avec toutes les données, ce qui est confirmé par le schéma IFC.

Oui, nous prenons en charge le brep avancé IFC à partir du format IFC, le brep facetté IFC, les opérations booléennes et les plans de coupe, les extrusions, etc., la géométrie explicite.

Oui, nous avons testé notre implémentation des alignements avec les fichiers que nous recevons de Civil.

Nous avons implémenté le modeleur de facettes ODA/ODA Facet Modeler, qui exploite la géométrie à facettes. Cela fonctionne également dans le cadre du SDK de dessins, donc il garde les corps du Modeleur de facettes dans l'état approprié, il contrôle principalement la topologie et la géométrie, plus encore - juste après l'ouverture du fichier si la géométrie est nécessaire et si c’est possible, nous réparons la topologie incorrecte en géométrie.

Actuellement nous utilisons ODA Facet Modeler en tant que notre implémentation de base, mais généralement il fonctionne avec ODA Solid Modeler et en particulier quant à la géométrie de génération pour différents balayages d'IfcRoad.

Oui, dans notre module IfcGeometry, nous obtenons toutes les données du fichier IFC et de la géométrie NURBS en particulier et les convertissons en courbes GUI; nous prenons donc en charge la géométrie NURBS, les courbes et les sous-faces.

Oui, vous pouvez accéder à toutes les données du modèle IFC en utilisant l'une des API fournies. Donc, vous n'avez pas à le dessiner, vous pouvez simplement obtenir des points composants, des extrudes, une géométrie explicite ou implicite de .ifc et travailler avec ça sans visualisation ni vectorisation.

Pour le moment, l’Open IFC Viewer peut être converti en .pdf, mais à l'aide de Visualize SDK, les fichiers IFC chargés dans la base de données Visualize peuvent être convertis en formats STL et beaucoup d'autres. Ainsi, avec Visualize SDK, la conversion peut être effectuée par programme.

Oui, nous travaillons avec les fichiers de BuildingSMART.

Oui, la certification est supposée à l'avenir.

Le moyen commun d'accès aux données est de haut niveau à la limite tardive et peut être utilisé sans se lier à aucun format: IFC ou non. Par exemple, vous pouvez accéder à la hiérarchie d'arborescence d'accès aux données commune sans connaître les classes IFC.

Lorsque nous avons commencé à prendre en charge le chargement d'IFC 4, nous ne pouvions pas générer de géométrie dans un style lié au début, car nous devions travailler avec différents ensembles de classes. Donc, le mur IFC dans le schéma 2x3 est une classe différente du mur IFC du schéma IFC 4 et nous avons décidé d'implémenter un travail lié tardivement avec SDK pour avoir le même code de géométrie générée.

Et bien sûr, il est assez simple d'utiliser l'importation de données à liaison tardive d'IFC vers l'application parce que le même code - c'est le principal avantage.

Pour le moment, la partie SDAI est une base uniquement pour le SDK IFC et il n’a aucune interaction avec d'autres SDKs ODA.

L'exemple de la façon d'obtenir la géométrie du fichier IFC s'appelle ExIfcVectorize.

Faites attention au contenu de TOOLKIT_IN_DLL défini dans chaque cpp. principal des exemples. Il existe une initialisation des modules nécessaires en statique:

#ifndef TOOLKIT_IN_DLL
INIT_IFC_STATIC_MODULES_NO_GEOM;
#endif

et

#ifndef TOOLKIT_IN_DLL
ODRX_INIT_STATIC_MODULE_MAP();
#endif

Donc, en configuration md, chaque module doit être initialisé au préalable pour que notre éditeur de liens rt puisse travailler avec eux. Il semble que votre problème soit lié à cette initialisation.

Vous pouvez obtenir OdDAIObjectId d'une instance d'entité, puis en obtenir un # si nécessaire:

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

Oui, la Release Candidate 2 actuelle de l'IFC4.3 est déjà prise en charge.

Méthode const OdAnsiString&OdDAI::ApplicationInstance::typeName() const; renvoie un nom de type d'instance appliqué.

Actuellement la seule façon d'obtenir des informations sur le type d'attribut est de caser de la manière suivante:

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());
      }
    }