Jump to content

VW 2016 IFC export issues (that were not in VW 2015)


TheatreG

Recommended Posts

Dear all,

recently we started a BIM project in VW 2016 SP2 that we need to share as IFC with other parties. As a standard we use the VW classes to give local building classifications to the different building elements.

While in VW 2015 those classes were automatically included in the export to IFC (shown as "layer" in the Solibri model viewer) this information seems to be lost when exporting from VW 2016.

Also we could not find back other information we gave to symbols like VW IFC ObjectType, VW Classification_Classification Source, VW Classification_Classification Edition, VW Classification_Classification Edition Date, VW Classification_Location, and several other data we added to the "Export IFC Project" sheet.

Furthermore a re-imported IFC (that we exported ourselves before) seems to loose some information compared to the original VW file (and compared to the Solibri viewer as well).

Could we solve this by changing some settings in VW 2016 SP2, or is this about bugs to be solved in the next service pack ? Any suggestions are welcome !

Best regards, Georg

Link to comment

Hi Georg,

We just moved our project on to 2016 and classes still follow into solibri as Layers.

Now it does not help you but, in our case it worked.

We had also filled in some fire- and acoustic-rating (Pset_DoorCommon) and that follows as normal into Solibri from 2016.

We have VW 2016 OS and SP2

Ida

Link to comment
  • 2 weeks later...

I have got a new Model from Revit by IFC.

Geometry looks quite good.

But beside the empty classifications in the Tables, all IFC Info is hidden

in the IFC Tag.

Somehow I expected to search for IFC Tags and deeper TAGs

(like Material information > Visualization)

with the Magic Wand Tool.

Unfortunately not there and Symbol+Name doesn't work either.

The next problem is, the IFC Objects are sorted on Classes, which is fine.

But as soon as I collapse these, the group inside as well as the geometry

in the group are assigned all to the Class that was active when importing IFC.

This makes it hard to sort and separate the geometry.

Beside it would be nice if VW would create and assign a basic Material (RW Texture)

for all Material Tags found in the IFC Tags.

Link to comment
  • 2 weeks later...
Dear all,

recently we started a BIM project in VW 2016 SP2 that we need to share as IFC with other parties. As a standard we use the VW classes to give local building classifications to the different building elements.

the classes structure aims at mirroring the construction national standards, anyway. what do you use for this? omniclass naming?

Furthermore a re-imported IFC (that we exported ourselves before) seems to loose some information compared to the original VW file (and compared to the Solibri viewer as well).

this is not how it was supposed to be done. there's no round tripping of the ifc models ! it's just a reference for others to work with.

otherwise we'd have editable ifc elements and a whole bunch of copy rights and professional insurance issues with them.

rob

Edited by gester
Link to comment

Furthermore a re-imported IFC (that we exported ourselves before) seems to loose some information compared to the original VW file (and compared to the Solibri viewer as well).

this is not how it was supposed to be done. there's no round tripping of the ifc models ! it's just a reference for others to work with.

otherwise we'd have editable ifc elements and a whole bunch of copy rights and professional insurance issues with them.

rob

That is what you will do, to check what came out, after you will hear that clients

had problems with missing information.

Second,

I think it is mandatory that VW can edit imported IFC geometry as if it would

be VW architectural objects ant that these behave like this, just as it works in

Archicad.

If there are any legal issues with IFC elements being non editable, it is up to

IFC to bring some encryption, locking mechanisms and user permissions to

parts of geometry.

Link to comment

1. the full information is in the model. if the information is missing, then it lays on the modellers. ifc is able to transport what ever the other party needs.

2. editing ifc is pure bs, it isn't, and it will never be. check the specification of ifc4 and the strategy papers of your fellow countryman thomas liebich. ifc is not to be edited !

of course, you could edit its parts, as it's a text format, but it will always be on your own personal responsibility.

rob

edit:

the archicad's ability to transform ifc into native objects while importing into the application is 'vergebliche muehe'.

do you want, say, a structural engineer, or maybe even a construction bim manager to manipulate architectural or mechanical objects ????

Edited by gester
Link to comment

IFC started as a way to exchange building information against the chaos of

proprietary file formats misused, especially by one market leader.

Putting all data into one non-editable model is just the least of possibilities and

makes only some sense.

As nearly everyone speaks IFC now, it should be used for general exchange.

I don't mind what IFC is intended for by license, and restrictions made by commercial

developpers.

Editing IFC data is no BS for sure. IFC is the only real open exchange format and will

be the most lossless exchange format soon. It is the future for collaboration, not only

something to separate claims of different parties.

As VW is not one of the best concerning getting data out of it with classical old

proprietary DWG and more DXF CAD formats (Missing faces from Windows, non-welded

faces in meshes, coming from Generic solids, flipped faces from extrudes and slabs, ...)

insufficient or tedious ways for settings for FBX, after 30 years of development,

I would be very happy to optimize internal geometry with FBX in the back of their minds.

Archicad has just been lucky that their internal geometry organizations fitted well

to upcoming IFC format.

Edited by zoomer
Link to comment

no party is authorised to change the other party's contribution, so ifc goes with this flow. there are copy rights and professional liabilities, even the subcontractors that contribute their shop models are responsible for them, even if done by other 3rd party subjects.

ifc is designed to work only in one direction (not as round-tripped exchange), and used as a reference for others to do their work.

what you write is a compete misunderstanding of the notion of ifc.

and: the ability of dwg to be changed was its major flaw.

rob

Link to comment

Hi Gester,

You make a good point regarding the non-editability of IFC. At a recent product demo for Solibri, a speaker noted IFC was the only file format that would be able to protect a studio's intellectual property.

That said, architects have very different needs to the various consultants or suppliers that are engaged as part of the project team. Three points;

1. We sculpt the building to suit our designs. As a part of that, getting prelim versions of consultants models that we can edit in a format that Vectorworks can natively edit, cuts down the time taken in the design iteration process.

2. Bringing in IFC files from consultants for design review, clash detection etc slows Vectorworks to a crawl. Having Vectorworks convert IFC into a native format/geometry would take much of this grief away — rather than the mess of 3D polys that are currently created.

3. I am seeing more suppliers creating their product object libraries as IFC files. As architects we need to bring them into our files. But if Vectorworks either; creates rubbish IFC conversion; or due to Vectorworks place in the market, we only have the option of Revit, ArchiCAD or IFC; or if the original object is drawn in a less than satisfactory manner — we end up re-drawing it all again anyway.

I understand the purpose of IFC to protect the I.P. of each team member, and control versioning etc, but if Vectorworks could read and export IFC natively, it removes much of the friction created by limited interoperability, without overstepping IFC's mandate.

Link to comment

hi diamond,

(..)

That said, architects have very different needs to the various consultants or suppliers that are engaged as part of the project team. Three points;

1. We sculpt the building to suit our designs. As a part of that, getting prelim versions of consultants models that we can edit in a format that Vectorworks can natively edit, cuts down the time taken in the design iteration process.

why would you want to edit the consultants' contribution? isn't it their kettle of fish?

i model the representation of the geometry, and then the consultants use it as a reference for their job. what they export is the model (preferably ifc) that contains objects that have special rules and behaviours. if i convert them to vectorworks native rules and behaviour then the information intelligence gets lost, in spite of convenient 3d geometry, which is only one of the bim dimensions, by far not the most important one, if you're doing a full-fledged bim / ipd.

2. Bringing in IFC files from consultants for design review, clash detection etc slows Vectorworks to a crawl. Having Vectorworks convert IFC into a native format/geometry would take much of this grief away — rather than the mess of 3D polys that are currently created.

well, it's not the vectorworks goal to collect all the branch models into a federated one. for this there is a bunch of bim management software packages (solibri model checker, tekla bimsight, navisworks, bim vision a.s.o.).

again, in case you're in for bim / ipd. if you're doing small bim, then you're maybe right, then no rules apply.

3. I am seeing more suppliers creating their product object libraries as IFC files. As architects we need to bring them into our files. But if Vectorworks either; creates rubbish IFC conversion; or due to Vectorworks place in the market, we only have the option of Revit, ArchiCAD or IFC; or if the original object is drawn in a less than satisfactory manner — we end up re-drawing it all again anyway.

I understand the purpose of IFC to protect the I.P. of each team member, and control versioning etc, but if Vectorworks could read and export IFC natively, it removes much of the friction created by limited interoperability, without overstepping IFC's mandate.

i've just assumed you're mentioning the architectural objects to be imported, it might then make sense.

on the other hand, it's suppliers' and manufacturers' responsibility for the accuracy of the shop models that will be inserted into a federated model in a lod500 status (again, preferably in ifc format), to be calculated and simulated by bim evaluation software packages (costx, bimestimate, ecodomus, simplebim, ies ve etc.).

from the bim objects' libraries bimobject.org are just creating a vectorworks interface, and from what i know they will convert all existing models and objects in their library into vwx format, too. i regard it as a temporary situation, though. in the end we'll be dealing exclusively with ifc data, and maybe then with something more sophisticated.

bim level 3 assumes a unified ifc federated model where all contributions are parts in their own rights, not editable, and with very accurate more-dimensional information from every project stakeholder's expertise field.

i can't imagine how other process' participants may mess around with parts of work they have no authorisation for nor knowledge of.

rob

  • Like 1
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...