Quite the opener!

And as you say, a few topics to cover - that could (should? / would?) be perhaps better be broken down into smaller threads - but I understand why you'd want to lay it all down in one go - so without much more chew, let's have a look...

As you've noticed, the 'native' modellers are a bit picky about their IFC write/read capabilities. ArchiCAD's generally considered 'better' at IFC than Revit, but the truth remains IFC is not the intermediary format it wants to be (yet), and "still" (more) an output format - which we throw together elsewhere (see Solibri). Personally I've been "lucky" to date and have only (mostly) had to deal with Revit-only workflows - thanks to the insistence of clients and contractors (who've clearly experienced the same issues you have, and/or don't like to juggle their own platforms). The last time I had any dealings with an IFC was when we had a sub-contractor model coming from Tekla - we wanted to have it in our model (for "completeness") but in the end accepted (and appreciated) that it was best to keep that body of work to Navisworks - which is infinitely more capable than Revit at accomodating other formats (and formats coming from other formats). Sure, it meant we didn't get all the beautiful rebar and panelisation in our (Revit) documentation - but when you (seriously) reflect on the true value of having such (in your design documentation) you realise you're going OTT. Navisworks provided us the means to comment on the subbies work - and (at least in the D&B world that this scenario was playing out) that was more than sufficient - it might not have satisified architectural-fetishism (for every last thing) but that's one of the many things 'BIM' is trying to steer us away from. Which a good thing.

Can't help with the warnings I'm afraid - that's the (current) nature of software conversions - but I understand there are ways and means to reduce/minimise their impact, but as above, is the desire to have their model in Revit born out of wanting their work in your (output) work, or more to "simply" have their work in your model space to coordinate-to? I dare say, if the geometry translates so poorly (via IFC) you would do well to investigate the potential of old stalwart formats like .dwg - which Revit still pukes at - but can handle a little better.


More of the same (response) really. But yes, a line needs drawing (not literally!) where "we" (Architects) need to call time on kowtowing - and if you're being sent junk, said junk needs sending back branded as such (albeit more politely). What 'BIM' does try to do - or at least the root-processes of BIM try to do - is identify these 'failings' (of human/software collaboraton) pre-emptively - establishing sound workflows between disparate teams and their weapon(s) of choice - so that you don't set off on a journey without a plan. That's why here in the UK (at least) we have all the hoo-hah about MIDPs and such (trust me, I'm not even 100% on whether that's the correct acronym'd document for this example!) to manage expectations when it comes to information exchange - and why said clients & contractors are endeavouring to steer single-software-suite workflows by having BIMmy-Competency-Questionaires (and conditions) in their further-down-the-(supply)-chain appointments.

Whoops, missed that you'd touched on these, so the above addresses this aswell - but yes, it's all still a bit of blue-sky dream to think every puzzle piece will fit perfectly, no matter how exhaustive an EIR/BEP - but that again is the point - a complex cast of characters need a fairly complex plot, and whilst some run a mile at the sight of BEP when it breaks the 20page mark, truth is, if you want things to go smoothly, everyone needs to be engaged and signed up to consider the stipulations of a BEP - and to consider 'everyone' said BEP will need to be pushing 50+ pages unless you forego any kind of (useful) diagrams and insist on using font size 8!

This is where dual-accounting kicks in (for some at least) where you model elements that are not your own - for simplicity - yes it sucks a little (a lot?) when you've still the (naive) promise of BIM suggesting each need only consider their own. But what would be swifter? You wrestle with a garbled IFC, or instead you simply edit down your wall type by 20mm on instruction? Working predominantly on Revit-only projects (as mentioned) I personally hate dual-accounting - but we still occasionally do.

For the time being, we're all forced out of our comfort zones into rosetta-stone platforms like Solibri or Navisworks. The "failure" of BIM, and the software vendors individually developing their own (ironically) silo'd platforms and formats for BIM, is that you - like so many others - are still caught up in the reality of today, and that is a need to document. The uber-evangelists will contest "You don't need drawings if you're doing BIM properly" - and one day I hope to reach that nirvana myself, but for now? Placeholders and "references-to" remain king. Which, when we're honest about things, isn't really all that much different "to the good old days" - no?

No. No. No. And this again is where 'BIM' is trying to educate the industry - you, as Architect, do not need that information in your model, presuming you're aiming at what, LOD300 at most? Roles and responsibilities are more key here than the complication of software - "we" Architects (collectively) are so very guilty of feeling the need to capture it all - and we need to (learn to) let that God-complex go (whilst defending ourselves from traditional expectations written into contracts to persist doing so) and 'push' that into the hands (and software) of those who need to be working with that (level of) information... I'm referring to construction managers and IMs here.


How's that?

"..I dare say, if the geometry translates so poorly (via IFC) you would do well to investigate the potential of old stalwart formats like .dwg - which Revit still pukes at - but can handle a little better..."

Wauw!
MY advice would be to really think *twice* before using dwg over ifc. I know what you think, dwg? well isn't that kind of a autodesk format, Revit is NOT compatible i dare to question if it will will be a autodesk for the longer stretch.. My $

So your alternative/proposal/solution, to counter the garbled geometry of ifc (when linked into Revit), would be?

All i wanted to say is, if you want to do 'bim' you shouldn't be using 'cad' in Revit.
There is no logic in that as advice. The only alternative I see is the Nwc underlay as Autodesks answer to this dilemma. How does nwc perform?

I didn't say CAD, not that that would matter even I did. No, I said a .dwg export from the 'other' software, to get the geometry into Revit if needed.

Filip's asking about BIM, and there is nothing to say .dwg (CAD even) can not be part of 'BIM' - everything has a place - and we would all be wrong to dimiss a format entirely out of some BIM-bias that ".dwg is bad" - because it is not.

fully agree, Snowy !!

Who is 'we'..? Define 'CAD??

Judging from my OWN experiences (.. maybe some Silent scivil engineers reading this?..)i can tell you that using DWG in Revit it is a BIG challange (understatement) And to be really honest, i may lead you to be a little bit of disappointing about Autodesk ability to make thing more compatible, at the end..

Maybe for the 3d modelling part of 'bim' the dwg format can certainly be used as reference model, but it stops right there. There are just too many catches, too many workarounds to get decent set of drawing using dwg element. This is the reason i say OP should look at uses IFC first!! Using that format as (referenced) import, it should become bit and bytes that Revit can work with be as platform really. You don't have to search that far some opinions about dwg from a revit point of vies..


Here is one


<back to philip in Germany..>

In my experience, many BIM users expectations of IFC exceed the intended purpose of IFC. IFC represents a static snapshot of a model at a particular time and is not intended to be anything more than that. When you load an IFC into your model, you will be able to view and interrogate the information contained, but you will not be able to modify or manipulate that information. When you "import" an IFC into your Revit model, the contents of that IFC will not become Revit families that you can use in the same way that you can use native Revit families. As I understand it, there are no plans to change this.

A good definition of where IFC fits in to the BIM arena is to be found in this excellent webinar by Prof Arto Kiviniemi (Liverpool University). Well worth a viewing if you are grappling with the complexities of working with multiple models.

I couldn't fault anything that Snowy has said here.
That is exactly my experience.

I am also currently in a part of Europe that is behind on the BIM implementation wagon, probably a good 3 years behind where the germans are (Something for the germans to feel proud of again).

The good news there is that you don't need to reinvent the Wheel, follow the trail thats been blazed already by everyone else, read the case studies, and follow the BS standards that are soon to become ISO standards anyhow. They will save a ton of headache.

That however doesn't answer the BIM using IFC question.

IFC is...a lame duck.

It dépends on the business model, and what your particular discipline needs out of an IFC.
If its just for linking geometry then it works OK, as long as its been exported well. If not, its just Junk, and as was suggested it needs to be sent back to the company that did the export and ask for Something that actually works. It is not your job to know what software they use and what rules for them to set when exporting the IFC.

As an architect, or engineer, or a mix of the two, as Snowy suggested, Navisworks or Solibri are much better adapted at reading multi-format models and making a federated model. This serves perfectly for coordination, rarely will your documentation require you to show the model of someone else behind it. I suppose the exception here may be architects that want to just show everything. If this is the case, and the architect is the lead consultant, then do like they used to do in Australia - Subcontractors MUST USE revit, otherwise they don't win the project. Demand an all revit environment, otherwise IFC will kill your project quickly depending on the competency level of your technicians and that of the technicians from your sub contractors.

Not only do they demand revit software for the project but they also want you to be able to do copy/monitor and some project coordination within the revit environment. In my experience this works really well. Once it goes to IFC it can still work, but all you want is geometry, handle clash detection in Solibri or Navisworks, and correct it in revit with your IFC geometry as a guide. You can't really do much better than that in the current environment unfortunately. Develop workflows that include IFC, in general it still works but as an architect I dont see you using native IFC geometry in your presentation in most cases.

Wait, what? If i catch a Structural, MEP, Equipment, Interiors, or Furniture consultant not plotting documents that actually show the other trades in the building, im kicking their ass off the project. The entire concept is EVERYONE should see everything, and should reference it. I get not showing it as complete noise, but dang. If a structural engineer started showing walls sections and leaving out the architectural details, i would (and have, and still do) flip out on them.


As much as i love Revit, i would never hamstring subcontractors like that. Navis is great at pulling in models that they build that are EXTREMELY detailed and very accurate... That arent from Revit.