Jump to content
taavilooke

IFC modelling with Vectorworks

Recommended Posts

We have just finished making the first really standard-compliant BIM model with Vectorworks. Vectorworks is indeed capable of producing correct IFC models but there are lots of weird behaviours and bugs that need some kind of a workaround. So, I though I'd share the knowledge I have gathered going through this. Hopefully it will make it easier for those who have to start working with BIM. We worked on VW2017, so some of those might be fixed in 2018 (I have tried some on the new version as well and these have not been fixed).

 

Following is a list of things that do not work as expected or need some weird workaround to accomplish:

 

Walls/Slabs

  • If the wall profile has been set by dragging the handles for the wall ends, but the profile is still horizontal, the wall exports to IFC with the full height (displayed in the OIP) rather than the where the handles are, even though it shows the correct geometry in VW).
  • U-values of wall and slab styles should be written directly into the ThermalTransmittance field in the IFC Data. The style parametric object does have a field for the U-value of the wall (that is also exported to IFC), however this field is not exposed anywhere in the interface to write values into that field.
  • When you offset the profiles some of the components of walls or assign some components to different classes, the data about the wall components and thicknesses is not exported to IFC. Also walls are exported by component, data about the materials is missing as well.
  • Roof faces are missing most of the IFC data, it has to be entered manually through the style IFC Data option.
  • Curtain Walls are exported with the IFC layer field empty (all other objects export the VW class as the IFC layer)
  • Wall End Caps export to IFC with the geometry corrupted.
  • Wall recesses export to IFC only if they are made with a 2D object, but not with a 3D object (or a 2D symbol). I think it should be possible to accomplish the same thing with symbols with a wall hole component.

Windows/Doors

  • The geometry of the window frames is corrupted in IFC— the jambs of windows are not rectangular but in an X shape. Also, both the window and the jamb are transparent.
  • Adding U-values to doors and windows through the style IFC Data does not work consistently for me. It is more foolproof to add the value to one of the User Data fields in the style and map this value to export to the ThermalTransmittance field in IFC through the Data Mapping dialog.
  • Even though there is a field in window data for frame and glazing materials, this is not exported to IFC. I have not managed to change the data mapping to make those fields export. The best way I found is to write this info to a User Field and change the mappings accordingly.

Symbols

  • Symbols are not exported to IFC unless they have an IFC type attached (same is true for solids). They also do not export if the object does not have a fill. This can easily lead to mistakes, because there is not really an easy way to check that all object that should be exported do have a IFC type assigned.
  • Symbols export with the IFC layer field set to the VW class that is assigned in the Symbol options dialog (not the class that the symbol instance is actually on like all the other objects)
  • If an IFC object is placed inside another symbol, the export behaviour is somewhat unpredictable. If the symbol is a VW parametric object it exports without having a IFC type attached (however it does not create a wall hole, unless the IFC type IS attached). For symbols containing other symbols, it does not export without the IFC type and also makes all the content into one IFC object (that does not decompose into the subobjects).
  • Scaled symbols export with the original size not the scaled size.
  • This one is actually useful: if you assign an IFC type to a symbol but do not change the name field, it will export with the name of the symbol as the name field by default (even though it does not show this in the IFC Data tab).

Project Sharing

  • IFC Export Settings are not saved to the project file on commit. To get them to save you have to turn the project file back into a regular document, make the changes and convert it back to project file.
  • Data Mapping settings are stored in the local computer and are not saved in the project file (or a regular file either).
  • In a Project Sharing document, the changes made to IFC Data of symbols are not saved to the Project File, changing them needs the same procedure as the export settings.

Miscellaneous

  • Adding data to PIOs that cannot be styled is a hassle, because the same data has to be added to all the objects separately. In these cases I have resorted to creating symbols of these objects. I think this gets better with VW2018, even though stairs and railings still cannot be styled.
  • Assigning an IFC type to a group does not make it export to IFC.
  • Spaces export to IFC only if they have the Show 3D option checked. Also it seems there is no way to make a space object with variable height.
  • Parking spaces export as IfcSpace objects. This can lead to confusion, because you cannot differentiate real spaces and the parking spaces. It’s best not to export Parking Spaces at all.
  • Solids and Autohybrids are sometimes assigned weird colors in IFC (it seems to depend on the IFC type attached to them).
  • Stairs and Curtain Walls decompose to subobjects in IFC that do not have any data attached (the object that contains them does have all the data though).
  • Some BIM standards expect object in IFC to have two levels of names, a generic name (Type Name in Solibri) and a specific name (Name). It seems that Revit and Archicad make use of these two levels to organize the objects and styles, while Vectorworks resource structure does not (this might be changing with the new window and door catalogs in VW 2018). The content of the Type Name field can be controlled for most objects in some way or another, but it seems easier to just declare that the content of this field does not matter.
  • Like 2

Share this post


Link to post

Thanks A LOT for sharing your experiences !

 

 

18 minutes ago, taavilooke said:

Symbols are not exported to IFC unless they have an IFC type attached (same is true for solids). They also do not export if the object does not have a fill. This can easily lead to mistakes, because there is not really an easy way to check that all object that should be exported do have a IFC type assigned.

 

Even worse, you can't assign a IFC tag when you have selected more than 1 Symbol Instance.

You would need to do that one by one.

Share this post


Link to post
8 minutes ago, zoomer said:

Even worse, you can't assign a IFC tag when you have selected more than 1 Symbol Instance.

You would need to do that one by one.

You can actually assign the IFC type to the symbol definition in the RB. Or if you change the IFC Data of an instance it asks you if you want to assign the same data to all other instances. However there is still this problem with Project sharing...

Share this post


Link to post

OK, I'll try it in RM

But I have too many Symbols to have fun with that.

If I select more than 1 Symbol at once - IFC option gone.

 

It didn't ask me about other instances but I will try again ....

Share this post


Link to post
24 minutes ago, taavilooke said:

Or if you change the IFC Data of an instance it asks you if you want to assign the same data to all other instances.

 

Thanks for mentioning this.

It does not work by assignment in OIP,

but it works over the menu command as you described !

EDIT

and it works by RM

 

But why can't I simply select all my Symbols in my Window or Furniture Folders

and assign IFC tags for all ?

Edited by zoomer

Share this post


Link to post

I'ld prefer to assign IFC Tags like this anyway ....

 

Screenshot-36.thumb.jpg.c94c3779d151169b9889249e28974c6e.jpg

Edited by zoomer

Share this post


Link to post

It would make a lot of sense that all objects would have some IFC type attached already (like IfcObject). Then they you could see that something some data is missing or erroneous and make the appropriate changes. At the moment these objects just do not appear in IFC and unless you intentionally look into it, no-one will find out that something is missing.

 

The workaround that I found is to make a worksheet that looks up all symbols without an IFC type attached...

 

Also, weirdly, if I assign the type IfcObject to an object, it does not show up in the export at all.

Share this post


Link to post
11 minutes ago, taavilooke said:

The workaround that I found is to make a worksheet that looks up all symbols without an IFC type attached...

 

Thank, I tried by using custom selection yesterday ;)

Share this post


Link to post

Wow, assigning IFC Tags can get really tedious.

You tediously selected all your Solids for Walls, but the IFC Tag option in OIP

is deactivated - because some of the Solids already had a IFC Wall Tag.

You can tediously custom-Deselect all Walls to get the IFC option back.

 

Select Similar also has no IFC option.

 

Seems table are really the only option.

 

Share this post


Link to post
17 hours ago, rowbear97 said:

@zoomerWould it be possible to use a worksheet to select objects without IFC tags and then edit from there?

In the Default library at Reports_schedules/Architectural Reports.vwx there is a worksheet Objects without IFC Entity that lists all object without an IFC tag attached. There you can right click on the row header (the gray color thing on the right with the worksheet row number on it) and click Select item.

 

This is only useful for solids, autohybrids and some PIOs that cannot be styled (railings and stairs). Adding data to windows, doors, symbols, walls and slabs should go through the Resource Browser.

Share this post


Link to post
On 27.11.2017 at 1:51 PM, taavilooke said:

Assigning an IFC type to a group does not make it export to IFC.

 

On 27.11.2017 at 1:51 PM, taavilooke said:

Symbols

  • Symbols are not exported to IFC unless they have an IFC type attached (same is true for solids). They also do not export if the object does not have a fill. This can easily lead to mistakes, because there is not really an easy way to check that all object that should be exported do have a IFC type assigned.
  • Symbols export with the IFC layer field set to the VW class that is assigned in the Symbol options dialog (not the class that the symbol instance is actually on like all the other objects)
  • If an IFC object is placed inside another symbol, the export behaviour is somewhat unpredictable. If the symbol is a VW parametric object it exports without having a IFC type attached (however it does not create a wall hole, unless the IFC type IS attached). For symbols containing other symbols, it does not export without the IFC type and also makes all the content into one IFC object (that does not decompose into the subobjects).
  • Scaled symbols export with the original size not the scaled size.
  • This one is actually useful: if you assign an IFC type to a symbol but do not change the name field, it will export with the name of the symbol as the name field by default (even though it does not show this in the IFC Data tab).

 

 

I currently tested a older Generic Solids only Project.

I assigned a lot of IFC tags and was very surprised how much did not export.

 

1.

Is it enough if Symbols get an IFC Tag itself or is it also needed that all its components get tagged ?

 

2.

Will groups work if the group and its components are tagged.

 

3.

And as I am just missing lots of separate simple Solids,

isn't a Wall tag itself not enough for export, do I need to also care about the Sub Tags ?

 

 

Share this post


Link to post
1 hour ago, zoomer said:

1.

Is it enough if Symbols get an IFC Tag itself or is it also needed that all its components get tagged ?

My impression was that that the symbol definition has to have a tag. Then it will export as one element/component. Otherwise the behaviour was inconsistent.

Also, I could not find any way to export solids and symbols into IFC so that they would have subtags (like the way walls decompose into components or curtain walls into plates and members).

 

For the other things I don't have much experience with those.

 

 

Share this post


Link to post

I'm currently testing.

 

What I found so far is that I don't notice any difference in export options :

- BREP (simpler Solids)

- Export Walls/Slabs by Components

in Solibri or Bricscad.

 

Solids come in fine and Walls always by Components.

(So also no options to export "simpler" Walls ?)

Share this post


Link to post
3 minutes ago, zoomer said:

(So also no options to export "simpler" Walls ?)

 

Simplified Geometry does the trick.

But it will produce overlapping geometries if some Wall Components will extend.

 

Another thing is that I have again some dislocations with Symbols in a group :D

They are moved for another distance as the group had from the origin + the objects

to each other have a double distance.

 

Share this post


Link to post

Hi All,

 

Great thread, thanks @taavilooke. Has anybody had any experience of adding IFC data to Referenced objects? i.e. Viewports in the model? Struggling to get this working at the moment, the referenced info in the viewport shows up but is displaced.

Share this post


Link to post
Posted (edited)

Hi @Jeffrey W Ouellette - We have a model containing the building, and a seperate model file containing a complex roof arrangement which is being referenced into the main building file. This is how we would prefer to structure the file for various reasons. Is it not possible to attach IFC data to referenced models then?

 

P.S. - Screenshot below, the referenced roof does appear (outline block for the time being). But it floats approximately 14m above where it should be.

 

724744961_SolibriScreenshotFloatingRoof.thumb.JPG.30cb749521ada02404f088f29c2b68d8.JPG

Edited by Asemblance
Attach Screenshot

Share this post


Link to post

In VW terms a referenced file is just a viewport that displays stuff, not the elements themselves. The same goes for DLVPs, you just get the display, not the objects. The whole purpose is to NOT bring the objects into the primary file. You can change how it displays, but not the contents.

 

If you tag elements in the referenced files they should be included in the IFC export. But I'm only 80% sure of that.

Share this post


Link to post

Hi @RickR - Yes that was also my thought. As you can see from the screenshot above (where the roof was IFC tagged in the referenced file), this geometry does show up. But for some reason it is displaced. I can only assume this is something going on behind the scenes, mostly likely to do with layer levels or origins or some such??

 

It feels like it should work but I'm missing something.

Share this post


Link to post

Yeah, showing up is one issue displacement is another. 

 

I recently had issues with ref. files moving. That was all origin bugs. I moved the user origin in the ref file to the master file origin (both)

 

Worth a good look.

Share this post


Link to post

Thanks for your thoughts @RickR,

 

I've also had problems with origins moving etc. However in this case the roof appears on the correct place in the model once referenced in. It just somehow moves in the export to IFC process!

Share this post


Link to post

Sometimes things move in the IFC export process when they are in symbols or groups. 

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×