9月 6, 2022

FAQ and Tips for IFC translation of Model Derivative API

 

More recently, more customers asked similar Model Derivative questions related to IFC. So, I tried collecting the IFC translation FAQ and tips I shared with the customers in this blog to help our IFC users better understand how to process their IFC models on Forge.

How does Forge Model Derivative process IFC models to svf/svf2?

All Forge IFC conversion methods use the same techniques as Navisworks does. So, on the other hand, the IFC translation from IFC to svf/svf2 will be processed with the Navisworks techniques, but with different user-chosen IFC conversion methods. Here are available options on Forge and their short descriptions. In addition, customers can see similar options on the Navisworks Options Editor.

  • legacy - the legacy IFC conversion method, which is under maintenance mode. It's the default IFC conversion method if you don't specify any when submitting the translation job via POST job.
  • modern & v3 - the Revit-based IFC conversion methods. They are based on the Revit techniques integrated with Navisworks.

Navisworks IFC Loaders

Which IFC conversion method is the right one for my IFC models on Forge?

This is the frequently asked question from our customers, but I would say it depends on what you need. Here is the comparison table for your reference:

Comparison/Conversion Methods Legacy Modern v3
Context Legacy Navisworks IFC conversion method Revit-based IFC conversion method that is based on the Revit techniques integrated with Navisworks. Similar to the Modern, but has some improvements and enhancements that Modern doesn't have.
Which service use it as default? Model Derivative BIM360 Docs and Autodesk Docs before June 2022 BIM360 Docs, Autodesk Docs, and Navisworks 2023
File process speed Faster than modern Slower than legacy Quicker than Modern for large IFC models based on internal tests.
Default length & property units Native IFC file units Feet always, as Revit does Native IFC file units
IFC Schema support IFC 2x3 IF2x3 & IFC4 (Not yet support IFC4.x) Same as modern.
IfcElementAssembly support No Yes Yes
Model orientation No Maybe, it depends on the orientation data set in IfcProject. Same as modern.
Advanced IFC options support (buildingStoreys, spaces, and openingElements) No Yes Yes
Skip axis presentation No Yes Yes
Multiple IfcSite/IfcBuilding support Yes No Yes
Additional information It's under Maintainance mode, so it won't get updates and bug fixes.   Recommended one if you want to use modern, but with native file unit support as the legacy does.

 

Notes.

  • See also on Navisworks IFC User Guide from Navisworks perspective.
  • For the model orientation-related issues, please check the IfcDirection value of the IfcProject's IfcGeometricRepresentationContext with my experience. In addition, if your model is exported from Revit, please ensure the coordinate base is Survey Point, Project Base Point, and Share Coordinate during exporting.
  • For elevation-related issues, if your model is exported from Revit, please ensure the coordinate base is Survey Point or Project Base Point during exporting. Using Share Coordinate, the elevation is always set to zero, according to our engineering team.

Georeferencing in IFC

We also get some customers asking why the georeference data in IFC is incorrect after translating with Forge and how to convert CRS (coordinate reference system) from WSG84 to others. So, here are the notes we need to be awarded in the IFC file from our engineering team before processing the IFC files with Forge:

  • In IFC2x3, there is no good support for georeference except using the site longitude, latitude, elevation, and true north set in IfcSite. In addition, the longitude and latitude are assumed to be WGS84.
  • In IFC4, BuidingSmart introduced IfcMapConversion and IfcProjectedCRS. The georeference data can be defined in a pair of these two entities. Revit read EPSG code from IfcProjectedCRS, and then get Easting, Northing, Elevation, and X-axis orientation from IfcMapConversion for georeferencing.

Troubleshooting locally

Before uploading to Forge for translation, we can also do local tests to see what the final translation result of Forge Model Derivative would look like.

Autodesk techniques

As we mentioned above, Model Derivative uses the same techniques as Navisworks does to process IFC models on Forge so that we can test our IFC files locally with Navisworks and Revit.

Testing with Navisworks

When you find some unexpected results after translating IFC files with Forge, it's a good idea to test it with Navisworks locally. Before starting the tests, please ensure you have installed the latest Navisworks, service packs, and Revit IFC Addins (from Appstore or GitHub). Afterward, here are the test steps:

  1. Open your IFC files using Navisworks with either IFC conversion method. (If you don't change the settings in the Options Editor > File Reader, Navisworks 2023 uses v3 by default.)
  2. Wait for the file loading to be completed.
  3. Check if unexpected results appear in Navisworks as well.
    • If yes, check if any error message appears in the log file besides the IFC file, like the below one. For example:
      Navisworks IFC processing log file
      Navisworks IFC processing log content
    • If not, go to step 4.
  4. Change the IFC conversion method to others in the Options Editor > File Reader, and then go back and repeat step1 - step3  to see if unexpected results appear as well.
  5. After testing all conversion methods, share the test results, your findings, and reproducible models with us via our support channels for further investigations. Note. Don't need to share the whole model. Partial model contents that can reproduce the issue should be fine.
Testing with Revit

When the IFC issues can be reproduced with the modern or v3 IFC conversion method, it's good to test further with Revit to help narrow down the issue. Before starting the tests, please ensure you have installed the latest Revit, service packs, and Revit IFC Addins (from Appstore or GitHub). Afterward, here are the test steps:

  1. Both modern and v3 IFC conversion methods use a similar feature as Revit Link IFC does. So, the first step is to create a new Revit project (RVT) from the template.
  2. Use Revit's Link IFC to open your IFC models and link them to the host RVT.
  3. Wait for the file loading to be completed.
  4. Check if unexpected results appear in Revit as well, and check if any error message appears in the log file besides the IFC file like the step3 of Testing with Navisworks.
  5. After testing, share the test results, your findings, and reproducible models with us via our support channels for further investigations. Note. Don't need to share the whole model. Partial model contents that can reproduce the issue should be fine.

3rd-party IFC viewers

Besides Navisworks and Revit, we can also use 3rd-party IFC viewers to help narrow down the issue. We can find suggested 3rd-party IFC viewers from the Revit IFC Manual Version 2.0. Here I choose FZKViewer, for example, which often helps me investigate IFC model problems. Here is what its UI looks like.

FZKViewer

Show All Presentations

Turning on "Presentations > Show All" is a good idea to help investigate the graphic problem. For example, last year, there was a Forge issue that some IFC objects would be far away from the origin while fitting to view the object (logged as NWLMV-199). After turning on "Presentations > Show All", I can see the problem objects have an axis far away from the actual geometry, which is skipped by most 3rd-party IFC viewers, but Autodesk techniques respect the data so that the axis will be included in the final result. After releasing the fix of NWLMV-199, the axis presentations in the IFC object will be ignored when using modern and v3.

FZKViewer all presentations

 

 

That's all. Hope this blog helps you better in handling IFC files on Forge!

Posted by

Eason Kang is a member of the Autodesk Developer Network ADN DevTech team, focusing on providing programming support, consulting, training and evangelism to external developers. He started his career in Taiwan and now lives in Taipei, Taiwan.


He is a developer consultant in the team DevTech, the worldwide team of API gurus providing technical services through the Autodesk Developer Network. He supports various product...

Related Posts