Automated Revit annotation and simple IFC roundtripping

[theoryshaw]

@yorikvanhavre @dimven

Hey guys, let's continue the conversation here...

I added a very rough IFC detail to the IFC Roundtrip folder. Basically each object has a "description" attribute ( common to all ifcproducts ) that contains the text to be extracted for annotation. Not sure how usable it is, but it's a start!

• @yorikvanhavre, As you can see from the following video, i don't have access to the "description" parameter. https://www.youtube.com/watch?v=3CJvjOzjxkw&feature=youtu.be
  • @dimven what your thoughts here? a particular parameter we should embrace?
• Also, @yorikvanhavre, as you'll see i copied one of those 3-dimensional studs, the one that was editable. Hopefully upon another roundtrip all 3 of those studs will be editable.
• Workflow proposal...
  • how about we use 'detail_MASTER.ifc' as the file we merge our individual branch files into (detail_Yorik.ifc & detail_Ryan.ifc)
  • would you like to try and use Constructivity to see if the merge works? Or do you want me to do it?
    • also, do you think this is the tool we should use for merging. Seems to me the only one viable at them moment.

[yorikvanhavre]

This is strange, when I reimport my own IFC file, indeed the lower stud comes cleanly, while the 2 others have some defects. This is clearly a flaw somewhere in the exporter, I'll try to locate the problem. The very good thing is that Revit is apparently able to edit any object as long as it doesn't come triangulated. We might be able to improve the workflow a lot, because normally FreeCAD's IFC exporter should only triangulate when absolutely unavoidable (curves that it can't attribute to a 2D profile).

About the master file, we could try something like this: leave a couple of objects there (for example the exterior panel, or the window), then each of us models different parts and we try to merge...

About Constructivity, unfortunately I cannot run it at the moment (crashes on Linux and in my Win7 virtual machine), but Tim said he would have a new version son that might solve that problem. Anyway, we should certainly explore it. But having several partial IFC files, I think both FreeCAD and Revit can handle it.

About the "description" field, I'll try to store the same info inside an IfcProperty too, let's see if it works better.

EDIT ok, found the problem already...

[dimven]

I'll copy my e-mail from yesterday to ease further discussion:

Thank you for your detail. My initial observations are that if you open the IFC file straight away in Revit, all the intelligent data is wiped. That eliminates the option of editing anything in the file inside Revit before linking.

Luckily if you link it directly, all the juicy bits remain inside.

When annotating 3d views, there are a few things to keep in mind:

- The 3d view will need to be locked first. Upon unlocking and navigating the 3d view, tag placement will need to be redone.
- We cannot use generic annotations in 3d views.
+ One possible solution is to straight away use text fields. Read the information from the component and write it to the text field.
+ Another solution is to place placeholder components and copy the data from the linked entity to the placeholder component, finally tagging the placeholder component with the appropriate tag.

The below is a quick mock-up:

During the previous weekend I toyed around with one of Yorik's previous models - the FreeCAD-testhouse. I understand that this is an older file and that now FreeCad's export functionality has progressed and the outcome is most likely differnet. However I think it's important to share my observations. I saw different behavior between linking vs. opening the IFC file.

When linking, the "void" forms from the solid Boolean operations performed in FreeCad seem to remain inside the file as an "IFCOpeningElement".
Some forms seemed to be exported as an "IFCSpace".

The above mentioned elements fail to be created when opening the file, instead of linking.

When opened:

As it appears when linking:

To further add to my observations every time the IFC file is opened natively inside Revit, the file is supposedly being "updated". I believe the information is lost due to FreeCad's IFC file format being more recent than Revit's IFC format. If possible, we should experiment by exporting the FreeCad model to all supported IFC formats.

[theoryshaw]

This is strange, when I reimport my own IFC file, indeed the lower stud comes cleanly, while the 2 others have some defects. This is clearly a flaw somewhere in the exporter, I'll try to locate the problem.

okay, sounds good. Just curious, did my IFC file with the new copied studs come in triangulated?

About the master file, we could try something like this: leave a couple of objects there (for example the exterior panel, or the window), then each of us models different parts and we try to merge...

About Constructivity, unfortunately I cannot run it at the moment (crashes on Linux and in my Win7 virtual machine), but Tim said he would have a new version son that might solve that problem. Anyway, we should certainly explore it. But having several partial IFC files, I think both FreeCAD and Revit can handle it.

sound good. I'll look at running merge tests with our 'detail file' as we evolve it.

About the "description" field, I'll try to store the same info inside an IfcProperty too, let's see if it works better.

sounds good. From my perspective, i feel we should look into using the IFCSURFACESTYLE or the IFCMATERIAL property. Having run tests, upon import, Revit translates those properties to Revit's native material property.

If we approach this way, i can from Revit's side globably change a material throughout the file, if necessary, instead of changing each instance if we went with another parameter for example.

@yorikvanhavre, would it be the same from FreeCAD's side, that is changing the material property globally?

@dimven what's your thoughts here?

When annotating 3d views, there are a few things to keep in mind:

• The 3d view will need to be locked first. Upon unlocking and navigating the 3d view, tag placement will need to be redone.
• We cannot use generic annotations in 3d views.
• One possible solution is to straight away use text fields. Read the information from the component and write it to the text field.
• Another solution is to place placeholder components and copy the data from the linked entity to the placeholder component, finally tagging the placeholder component with the appropriate tag.

Actually i wasn't looking to view our 3D details in an axon view. I was looking to model in 3D, but view and annotate this content in 'plan' and 'section' only.

examples...

[yorikvanhavre]

Yes your file opened correctly. I updated mine too, I believe now the 3 studs should be editable.

At the moment FreeCAD will export "basic" material info as IfcSurfaceStyle, but will create a separate one for each object. I could change that easily I think.

Replying to some @dimven's observations above:

• FreeCAD exports to the IFC 2x3 format, which is the current "stable" release. IFC 4 (older notation: 2x4) is already there but not yet considered "official". Normally, 2x3 is what Revit also uses. If anything FreeCAD produces is not good, then it's probably a bug in FreeCAD.
• Having IfcOpeningElement and IfcSpaces "pop up" as separate, solid objects is strange, because these two objects are specifically meant to represent spaces, not solids... In any case FreeCAD exports them correctly, IfcOpeningElements are subtractable voids for walls, and IfcSpaces represent open spaces... Maybe something to configure in Revit? Is this the case with other IFC files that have IfcOpeningElements or IfcSpaces? (for ex this one: http://ifcopenshell.org/ifcopenhouse/v4/IfcOpenHouse.ifc )
• I also see that some of the curved walls don't appear for you... Unfortunately I cannot test right now because my Revit chose to not start anymore :(
• From your screenshots above, it looks like all Ifc properties get lost when opening (instead of linking). I suppose then that by using an IfcProperty to put the text, instead of the IfcDescription, we won't get much better results... But I'll try anyway.

[dimven]

@yorikvanhavre
I'm getting similar behavior with the IfcOpenHouse.
When opened:

When linked:

This is all running on Revit 2015 UR5 (build 20141119_0715)
I tried playing with the "Import IFC Options" but that doesn't seem to have any effect on lined files.
"IfcOpeningElements: seems too be its own element type when opening the file but it's grouped under the "Generic Models" category.

@theoryshaw
It would be great if we could get the material properties to work for sure, however that would mean that we'll need to open the Ifc file in Revit and that might flush the parameter data.
One alternative we could explore is to instead create view filters for linked files:

Another interesting find was that when you link the file, import and ungroup, the parameter data remains inside.
https://www.youtube.com/watch?v=bHeMDG55Nzo&feature=youtu.be

[dimven]

I've been digging through the API. It seems like Revit 2015 has two modes of opening an IFC files - Reference and Parametric. This might be what is taking away the parameter data.
Edit: I created a simple dynamo definition to ease the ifc to rvt conversion. You don't need to link,bind and ungroup to keep the parameters anymore. Please test it and tell me if it works as expected for you.
@yorikvanhavre I'm not sure if Dynamo can run on a virtual box. You'll need the latest dotNet libraries ( 4.5+)

[theoryshaw]

Sure, i'll test it.

as you hinted above, the objects are not editable when you bind an IFC file into Revit.
as shown here: https://www.youtube.com/watch?v=yYa3OibySK0

[dimven]

Yes. Unfortunately the above dynamo graph makes elements uneditable as well. It seems that during the conversion process from IFC to RVT components, the assigned parameters are lost. The dynamo definition bypasses the conversion process by importing the file in "Reference" mode.

[theoryshaw]

resultant files: a499c59

video workflow:
https://www.youtube.com/watch?v=BSUHKhMzAx0

Unfortunately we need those objects/parameters to be editable for roundtripping.

Can we entertain using IFCSURFACESTYLE or the IFCMATERIAL property? Those translate into revit's native material parameter.

[dimven]

Hmm, ok I think I've got some ideas how to fix this.
Revit (2015 and above) has a dedicated method that supposedly can handle this kind of parameter mapping:
http://revitapisearch.com/html/87327a4b-94fd-5a21-df33-9beb1921cb4d.htm
However it seems to be based on dictionaries, which at the moment are not working with Dynamo's ironPython version. I think I can rig something similar tho. The great news is that the IFC file is a plain text file and you can extract any information from it. That and also Revit seems to preserve the IfcGuid parameter. We can use it to match the components with the appropriate data:

Another alternative would be to use a Revit macro( that can handle dictionaries), but I'm not sure if my c# skills are not up to the challenge.

[theoryshaw]

sounds good. I would only say let's keep an eye toward future expand-ability to other platforms (archiCAD, microstation, for example). If we embrace a parameter that is already consistently translated with existing MVD's like CV 2.0 then it will make it easier to translate this roundtripping workflow to those platforms in the future.

Obviously the automated annotation part of this will be Dynamo/Revit specific, but let's try and keep the ability to roundtrip the object/parameter/value as agnostic as possible. (or as close to an existing MVD, as possible) If that makes sense.

[yorikvanhavre]

@dimven dynamo works in a virtual machine, I just installed it and seems to work fine. Cool! Now I need to look a that python thing. You might not be aware of that, but FreeCAD can be imported as a python module in another application (once the path is set in sys.path, a simple "import FreeCAD" does it) imagine freecad running inside dynamo, sickening wild possibilities!

I'm working on proper materials support in FreeCAD now (discussion here if anyone interested http://forum.freecadweb.org/viewtopic.php?f=23&t=10503 ), not finished yet but we'll soon have something reliable I think.

[theoryshaw]

Thanks @yorikvanhavre for the update.

including these for others...
https://twitter.com/theoryshaw/status/587697778190635008
https://twitter.com/theoryshaw/status/587698122794672130

openIDF or BSDD might not be appropriate here, but wanted to log nonetheless.
Defer to you on best approach.

Thanks.