I'am not sure where to ask this question. But I'll start here.
Although IFC is meant as "open" and should always give the same output, there are differences between viewers. When we export an IFC from Revit, it will show up correctly in one viewer and give problems in a different viewer. It looks like the IFC is correct and the viewer is not ‘good enough’. But it still can be a problem in our Revit based IFC. We don’t know.
Right now we are having a few problems with a contractor that uses Navisworks. They experience some problems with the IFC in Navisworks while Solibri has no problem at all. They expect us to solve this. But if my IFC is good enough for Solibri what else can I do?
We have e.g. problems with profiles. They ought to be modelled in the first Quadrant - this is not really an option with structural profiles. Then we are also not allowed to have small curves in this profile. There are also some wall openings not cutting a wall while others are. And finally there seem to be some problems related to the way a curved wall is modelled.
So, are there really some general restriction while modelling in Revit and generating an IFC for Navisworks?
Or are these just missing functionality of Navisworks. And something that Navisworks should address?
Or is the IFC generated in a way that will be problematic for Navisworks and not for Solibri?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So it seems to be better to use to native way from Revit to Navisworks, if having problems.
And if it is really neccesary to deliver IFC files. You can still make IFC files from Revit to use in other software (e.g. Solibri). Or, make an IFC from Navisworks based on an Navisworks file (not tested yet) with a paid Addin like e.g.: http://www.codemill.fi/#siddownloads https://iconstruct.com/feature/smart-ifc4-exporter/ Hopefully a nice workaround for mirrored linked files in Revit to IFC,
without the need to make mirrored copies of these linked files.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The fact that IFC is open is its strength and weakness. Unlike, say, DWG, there is no "reference" viewer or product that can determine what a "correct" IFC file should be like with 100% confidence. The fact that there are so many dialects with so many quirks also means that an application might not yet expect a "valid" IFC file that didn't exist before (or was uncommon in practice).
Internally, we have been consolidating our IFC experiences. Inventor uses the Revit engine for output, and Navisworks, as of 2017.1, uses the Revit engine for import. I hope that this will extend into more products. That would not solve all problems, but it would mean greater consistency within our ecosystem, which is a big deal.
We are also looking into providing guidance on the Revit side for using IFC. I think that in practice there will be "restrictions"in how you model if you want to maximize your IFC experience; we want to minimize those restrictions, but the IFC format isn't the Revit format, so there are going to be translations that are better than others. We need to provide more guidance on what those are.
So I'd say that there are plenty of places for improvements. As vendors, and especially Autodesk Revit, which is the only one I can directly speak for, we can continue to improve our IFC support IFC, and provide more consistancy in what is supported across products. As an IFC community, and as buildingSMART, we can provide better validation of IFC files, to try to determine if the problem is on export or import (or both). And we on the Revit team can provide better guidance on how to model your Revit project to maximize your IFC output.
Thanks for your feedback on this journey to improve open standards and our participation in them, and in trying to identify the most relevant pain points to address first.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So if I understand you correctly: There will remain restrictions on how to model in Revit for optimal IFC experience. But do you recognize the ones I mentioned while modelling in Revit and viewing in Navisworks? Or is this workflow from Revit > IFC > Navisworks simply not the preferred one. We should definitely be sure that the latest import functionality of Navisworks 2017.1 is being used. (And check an older version if the latest one is not correct.)
* I think it is a smart move to consolidate all the IFC experiences with the Autodesk products. Has Autodesk a place to assemble questions for better IFC input / output within their ‘ecosystem’. And is this Sourceforge site a place to gather these questions?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
At this point in time, it's quite difficult for a person authoring or receiving IFC files to determine why they display differently in different software etc.
So if required software has particular requirements about the contents of an IFC file (ie no short profile curve segments), it would be possible to define this in an MVD and check that an IFC file is compliant with this. It will be particularly helpful when exporters can accept an input that is an MVD and adjust the generated file as appropriate.
For the time being, it would be possible to post process the IFC file to get particular adjustments. If you would like assistance in pursuing this, then please get in touch.
Cheers,
Jon
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'am not sure where to ask this question. But I'll start here.
Although IFC is meant as "open" and should always give the same output, there are differences between viewers. When we export an IFC from Revit, it will show up correctly in one viewer and give problems in a different viewer. It looks like the IFC is correct and the viewer is not ‘good enough’. But it still can be a problem in our Revit based IFC. We don’t know.
Right now we are having a few problems with a contractor that uses Navisworks. They experience some problems with the IFC in Navisworks while Solibri has no problem at all. They expect us to solve this. But if my IFC is good enough for Solibri what else can I do?
We have e.g. problems with profiles. They ought to be modelled in the first Quadrant - this is not really an option with structural profiles. Then we are also not allowed to have small curves in this profile. There are also some wall openings not cutting a wall while others are. And finally there seem to be some problems related to the way a curved wall is modelled.
So, are there really some general restriction while modelling in Revit and generating an IFC for Navisworks?
Or are these just missing functionality of Navisworks. And something that Navisworks should address?
Or is the IFC generated in a way that will be problematic for Navisworks and not for Solibri?
To answer my own Navisworks related question:
There were some known limitations for Navisworks while importing IFC (may 16th 2016)
But i'am not sure if this list is still up to date when Navisworks 2017.1 is using the Revit engine for import:
https://knowledge.autodesk.com/support/navisworks-products/learn-explore/caas/CloudHelp/cloudhelp/2017/ENU/Navisworks-Manage/files/GUID-19138169-BCA1-426C-9BF7-06D87DE64D4B-htm.html
Voided BReps
Bounded half-space solids
Complex parametric profiles
BSpline curves
Curve styles
Swept surfaces
Textures and complex lighting
Loading of server-based IFC models
So it seems to be better to use to native way from Revit to Navisworks, if having problems.
And if it is really neccesary to deliver IFC files. You can still make IFC files from Revit to use in other software (e.g. Solibri). Or, make an IFC from Navisworks based on an Navisworks file (not tested yet) with a paid Addin like e.g.:
http://www.codemill.fi/#siddownloads
https://iconstruct.com/feature/smart-ifc4-exporter/
Hopefully a nice workaround for mirrored linked files in Revit to IFC,
without the need to make mirrored copies of these linked files.
The fact that IFC is open is its strength and weakness. Unlike, say, DWG, there is no "reference" viewer or product that can determine what a "correct" IFC file should be like with 100% confidence. The fact that there are so many dialects with so many quirks also means that an application might not yet expect a "valid" IFC file that didn't exist before (or was uncommon in practice).
Internally, we have been consolidating our IFC experiences. Inventor uses the Revit engine for output, and Navisworks, as of 2017.1, uses the Revit engine for import. I hope that this will extend into more products. That would not solve all problems, but it would mean greater consistency within our ecosystem, which is a big deal.
We are also looking into providing guidance on the Revit side for using IFC. I think that in practice there will be "restrictions"in how you model if you want to maximize your IFC experience; we want to minimize those restrictions, but the IFC format isn't the Revit format, so there are going to be translations that are better than others. We need to provide more guidance on what those are.
So I'd say that there are plenty of places for improvements. As vendors, and especially Autodesk Revit, which is the only one I can directly speak for, we can continue to improve our IFC support IFC, and provide more consistancy in what is supported across products. As an IFC community, and as buildingSMART, we can provide better validation of IFC files, to try to determine if the problem is on export or import (or both). And we on the Revit team can provide better guidance on how to model your Revit project to maximize your IFC output.
Thanks for your feedback on this journey to improve open standards and our participation in them, and in trying to identify the most relevant pain points to address first.
Thanks Angel for your reply.
So if I understand you correctly:
There will remain restrictions on how to model in Revit for optimal IFC experience. But do you recognize the ones I mentioned while modelling in Revit and viewing in Navisworks? Or is this workflow from Revit > IFC > Navisworks simply not the preferred one.
We should definitely be sure that the latest import functionality of Navisworks 2017.1 is being used. (And check an older version if the latest one is not correct.)
* I think it is a smart move to consolidate all the IFC experiences with the Autodesk products. Has Autodesk a place to assemble questions for better IFC input / output within their ‘ecosystem’. And is this Sourceforge site a place to gather these questions?
At this point in time, it's quite difficult for a person authoring or receiving IFC files to determine why they display differently in different software etc.
But hopefully this changes in the near future.
From attending the Building Smart Summit in April, Model View Definitions will help end users validate and audit IFC files with specific requirements. http://www.buildingsmart-tech.org/specifications/mvd-overview/mvdxml-releases
So if required software has particular requirements about the contents of an IFC file (ie no short profile curve segments), it would be possible to define this in an MVD and check that an IFC file is compliant with this. It will be particularly helpful when exporters can accept an input that is an MVD and adjust the generated file as appropriate.
For the time being, it would be possible to post process the IFC file to get particular adjustments. If you would like assistance in pursuing this, then please get in touch.
Cheers,
Jon