REED SMARTBIM LIBRARY

[JohnS]

EVERYONE should write to Reed and ask them to support IFC in their new SMARTBIM online library of products instead of just Revit. This is very important!

Someone at Nemetschek should get on the phone with other Cad manufacturers and get them to start to lobby REED to support IFC instead of just Revit. Also someone from the IAI should call Reed. Autodesk is pulling a fast one here to make Revit the industry standard instead of IFC. This is a beachhead that can't be allowed to stand.

Edited October 10, 2010 by jsibert1

[Bob Holtzmann]

I've seen Reed Construction Data's new BIM services too.

Their message essentially says "We are Revit. You will be assimilated into our collective. Resistance is futile".

Not a good case for open source. I've been going to Arcat.com for online objects for CAD and BIM. They have 3D DWG library objects, which can import into Vectorworks.

[Robert Anderson]

jsibert1, I wholehearted agree with you as to the importance of this; I would think that almost all manufacturers would welcome a single, consistent, data rich form of product data delivery that would apply to all platforms.

Now, having said that, and being very involved at high levels with the BuildingSMART alliance who runs the IFC biz, let me say that there are still technical challenges to this. The IFC powers-that-be have in general been working hard on just getting the exchange between programs up to a reliable quality level. They are making progress on this, and have signed up many software manufacturers (Nemetschek Vectorworks included) to obtain a second round of certification on IFC 2x3 using their new automated testing service. I believe the prospect of automated testing of IFC exchange is a long-overdue improvement in quality certification of the standard.

I am also involved with R&D groups at Georgia Tech headed by the esteemed Chuck Eastman who are focusing (among other topics) on this topic. There is a will out there to see this thing done.

That said, until there is a published standard for IFC-for-product-data (which will probably be an IFC "Model View Definition" or MVD), I doubt that Reed or any of the other "Revit houses" will stick their necks out. I mean, I think it could be done, but why should they take a risk? Their perception (wrongly) is that Revit is the standard. Only time and the marketplace will disabuse them of this notion.

It can be a little frustrating to see how long it takes for "open standards" to be promulgated. But that's community politics for you

[Christiaan]

One advantage to objects that are native to a program is that they can be parametric. A difficult one for IFC to compete with.

[Jeffrey W Ouellette]

Why would you want manufactured objects to be parametric? After all, they manufactured that way. A particular item is manufactured with specific parameters and resulting performance data. Changing any other parameter invalidates the entire data set or specifications for the object.

Besides, the transfer of parametric values in IFC is entirely possible. Some applications do it today in order to make some objects at export able to be "reconstituted" at import in the same app. Not an ideal, or even real workflow, but a trick worth noting. Eventually, when we get past the new Certification of all the major apps for IFC, we will see movement on developments (implementation agreements) which will guide all the software vendors, and manufacturers, toward supporting the exchange of data in an IFC file will allow some objects to be easily translated into native application objects, with consistency.

buildingSMART has never claimed that IFC was intended to be used in this method (roundtripping), or that users should expect any of the sort today. Over time, with end user and vendor support, we may see development, though, that can make some small, but important headway in this direction... But users better align their expectations with some cold, hard realities.

[Chris D]

buildingSMART has never claimed that IFC was intended to be used in this method (roundtripping), ...[snip]... But users better align their expectations with some cold, hard realities.

In such a prolonged absence of an open standard, is it any wonder that RVT will become the DWG of BIM?

Better sort out your RVT export rather than your IFC export then Jeffrey...

[Jeffrey W Ouellette]

But Chris,

Part of the problem is defining the workflows for such roundtripping to be used. Where? Why? What are the consequences? How is it managed? Who is sending the data? Who is receiving it? Why is it being used?

All these questions are important to answer. I think that the exchanges and workflow demonstrated with the DC Riverside project address this in a meaningful way. The exchange of model data between disciplines is meant for referencing the work of one discipline (e.g. architecture) while the the other discipline expert does their work and adds their data (e.g. structural engineer). In the US, at least, these are two completely separate domains with different responsibilities and liabilities. As such, there is a need to segregate data and representation in a way that prevents "cross contamination".

The case for using a single platform/file format for editing, like Revit, doesn't hold up without a significant amount of work done to negotiate the reach and responsibilities of modeling, data entry, and editing between each of the design disciplines. A project in which every designer and the contractor use a platform like Revit (or ArchiCAD) means that somewhere a LOT of rules need to be created about who makes what and who changes what, and when it happens, AND someone needs to be responsible for enforcing these rules across ALL participants. Talk about a hornet's nest...

With the file-based model exchange workflow, using IFC as the format, meaningful data can be exchanged with more control over who gets what and when and in what format. Every player retains control over their native data and editing, yet benefits from more complete reference data.

[VincentCuclair]

A project in which every designer and the contractor use a platform like Revit (or ArchiCAD) means that somewhere a LOT of rules need to be created about who makes what and who changes what, and when it happens, AND someone needs to be responsible for enforcing these rules across ALL participants. Talk about a hornet's nest...

Having seen the Teamwork layout ArchiCAD has developed the basics for this are almost already in place, there is a strong hierarchy of teamwork members, with many different levels of administrative rights, implementing further administrative rights and rules, specifically for the external parties involved, to this existing layout shouldn't be a problem.

[Chris D]

But Chris,

Part of the problem is defining the workflows [snip]

Hmm, I'm not even a big fan of BIM...at least in its current worldy incarnation.......why am I getting myself into a discussion with someone called "the BIM guy"... ;-)

Perhaps my naivety is an advantage....I don't have any baggage to bring to this discussion, but the way i see it is this - I think your view of BIM is based on an old 2D workflow (the one I use day in, day out).

With BIM, I expect to see a single building model, which I expect to live in the cloud. Nobody owns the model...it's developed jointly by the design team. Consultants - the architects, structural engineers and services engineers check out their own 'elements' of the project, and then check them back in when complete. Other team members can review these submissions and comment on them, or even veto them. This review procedure is the only rule. Like a wiki server, you can roll back any changes that users make if you believe them to be incorrect.

Does this happen on any BIM platform? If not, why not?

[VincentCuclair]

With BIM, I expect to see a single building model, which I expect to live in the cloud. Nobody owns the model...it's developed jointly by the design team. Consultants - the architects, structural engineers and services engineers check out their own 'elements' of the project, and then check them back in when complete. Other team members can review these submissions and comment on them, or even veto them. This review procedure is the only rule. Like a wiki server, you can roll back any changes that users make if you believe them to be incorrect.

I think you're bang on the money there Chris! To start with it would suffice if the 'model parts' done by other parties could be shown as a snappable referenced trace (with an auto updating option), no need for importing, scaling, creating viewports, etc. etc.......

[Chris D]

Perhaps my naivety is an advantage....

You know what, in for a penny, in for a pound, as we say here..

I'm all for open standards, but there are open standards and open standards. The first sort are evolved, slowly and painfully, by a stalinist navel-gazing committee, like IFC. The second route, as Steve Jobs did with FaceTime, is to just get on with it, implement it, and then open the doors to the house party. I reckon FaceTIme will have wide adoption before IFC is even finished.

So, here's the FaceTime* style plan:

Nemetschek already own and control three platforms - Allplan, ArchiCAD and Vectorworks. Bentley (any enemy of your enemy is your friend) would join an anti-Revit alliance, so add in Microstation.

Take these four platforms and don't just agree some exchange protocols, agree a single file format which each program can edit natively.

OK, it's still a committee, but a committee of two. Two companies, with four platforms, coming together to head off the closed Revit platform becoming the de-facto standard for BIM.

Develop the common file type, publish it, then invite everybody else (Revit, Sketchup etc) to play.

*Cue anti-apple lashback in 3-2-1...

Edited October 11, 2010 by Chris D

[Robert Anderson]

Chris, you know, it's kind of funny if you look at it just right. On one hand, you're very idealistic, very touchy-feely cooperative:

a single building model, which I expect to live in the cloud. Nobody owns the model...it's developed jointly by the design team. Consultants - the architects, structural engineers and services engineers check out their own 'elements' of the project, and then check them back in when complete. Other team members can review these submissions and comment on them, or even veto them. This review procedure is the only rule. Like a wiki server, you can roll back any changes that users make if you believe them to be incorrect.

On the other hand, you decry IFC (which after all has been developed in a cooperative method as you describe for projects) as

evolved, slowly and painfully, by a stalinist navel-gazing committee

So, which is it? I personally think the KISS approach to interoperability as forwarded by the openBIM initiative is the way to go. Today. I think exchange/sharing of parametric models is (for the present) the wrong approach. Why?

When you propose that Nemetschek AG develop a parametric standard, that is just the strategy that AutoDesk is using with its RVT/RFA standard. Any standard that is exclusive will fail, because professionals like (understandably) to use their preferred tools.

Parametric standards are problematic. While NAG could develop such a standard (and bSI is looking to do the exact same thing for a future version of IFC,) software developers make their living not by being the same, but by differentiating their products. So any parametric standard will by necessity be "dumbed down".

Is this what users want? Or would they prefer having absolutely accurate geometry with data that they can use, reference, query? They can do this today with IFC.

[Christiaan]

Why would you want manufactured objects to be parametric? After all, they manufactured that way. A particular item is manufactured with specific parameters and resulting performance data. Changing any other parameter invalidates the entire data set or specifications for the object.

But not all building objects are non-configurable static objects. The editable parameters could even be manufacturer specific.

See examples here: http://www.smartbim.com/ObjectFinder.aspx#area=2

[Chris D]

Chris, On one hand, you're very idealistic, very touchy-feely cooperative:

[snip]

On the other hand, you decry IFC

[snip]

So, which is it?

Sometimes, the ends justify the means.

Is democracy always the right answer - two lions and a lamb voting on what to eat for lunch?

I'm all for open standards, but sometimes you have to cut through the bureaucracy and just get on with it.

I don't decry IFC. I decry how limited in scope it is and how slowly the navel-gazing is going.

[Chris D]

Today. I think exchange/sharing of parametric models is (for the present) the wrong approach. Why?

[snip]

because professionals like (understandably) to use their preferred tools.

[snip]

Parametric standards are problematic.

[snip]

software developers make their living not by being the same, but by differentiating their products. So any parametric standard will by necessity be "dumbed down".

I think this statement reveals that NV Inc is afraid of a common file format, in the same way Autodesk would be. I believe you are wrong, and not just from a user's point of view, as our lives would be infinitely easier, but also from a developer's point of view.

Differentiation is derived by the software, not by the file format. As an analogy, we can all sculpt with identical blocks of ash wood, but those with the better chisels will have an advantage. Those who want a state-of-the-art wood-turning lathe will also pay more for it than those who prefer a basic sets of tools from the hardware store.

Differentiation of BIM software that could manipulate a common file format would take the form of the tools available, their usability, their power, their automation, their customization, their localization (language and local practice) - many, many factors.

Do I even need to point out that there are a multitude of HTML editing apps out there, all editing the exact same, open, standard*, code (*for the most part..). Sure, Dreamweaver is a big player in this market, but even small developers make money out of producing HTML tools for those who don't need and can't afford DW.

Edited October 12, 2010 by Chris D

[J Lucas]

Serif, for example.

[Jeffrey W Ouellette]

Chris,

You are making the exact same arguments for IFC by claiming the HTML analogy.

IFC -> BIM = HTML -> Internet

Development appears slow from your end, because any software development, at this scale, is hard and time consuming.

I forsee that the development of BIM software will follow a similar arc to the development of Web tools. We're just starting to pick up the pace 10 years later than the WWW explosion.

[Chris D]

Chris,

You are making the exact same arguments for IFC by claiming the HTML analogy.

IFC -> BIM = HTML -> Internet

Is that the case though Jeffrey? It has been argued in this thread that IFC is no more than a glorified exchange protocol, and Robert even rejected the idea of a common file type. So is IFC really analogous to HTML?

[Jeffrey W Ouellette]

Yes.

Unless someone else comes up with another completely open, international, standard file format/data structure that is robust enough, logical enough, extensible enough, and flexible enough, that is OPEN, then IFC is it.

If Autodesk wants to "give" .rvt up to be an international standard, fine, so be it. But I'll bet after an hour of examining the file format, as it exists today, in any detail, everyone will be resigned to going back to using IFC because it doesn't really fit the bill.

[Chris D]

Unless someone else comes up with another completely open, international, standard file format/data structure that is robust enough, logical enough, extensible enough, and flexible enough, that is OPEN, then IFC is it.

If Autodesk wants to "give" .rvt up to be an international standard

At the risk of going round in circles....

Nemetschek already own and control three platforms - Allplan, ArchiCAD and Vectorworks. Bentley (any enemy of your enemy is your friend) would join an anti-Revit alliance, so add in Microstation.

Take these four platforms and don't just agree some exchange protocols, agree a single file format which each program can edit natively.

If IFC is too slow, and too limited in scope, then this is the alternative.

[Dieter @ DWorks]

IFC is not good as it is now implemented. I tried today to import an IFC file into VW, guess what, I can't edit the components!

It seems that VW just imports all components as IFC objects and not like walls, columns, .... I thought the power of IFC was that you can draw with walls, floors, ... in one program and be able to get it into another program?

[Christiaan]

I have to say I'm amenable to IFC taking time to mature. I can foresee a transition period in the BIM process where we use IFC in much the same way as we do DWG. That is to supply engineer's with backgrounds for their work and for engineer's to supply us their information that we either incorporate directly into our models as static information or use to check against our own.

Apple looks to have made a pretty good move with FaceTime but they're in a great position to do so. They have the leading technology and they have a huge amount of clout. They've made similar moves with USB and so on. Maybe Nemetschek and Bentley could pull off such a move but it's hugely risky and could permanently fragment the whole industry.

[Robert Anderson]

DWorks, this is what we mean by IFC not being "parametric". You have an expectation of IFC that is just not part of the protocol, at least as the schema currently stands. IFC is about sharing and referencing data-rich 3D building models, not about file exchange from one native format into another.

You can draw with walls and floors in a program (say Vectorworks) and get it into another program (say Revit, ArchiCad) and get accurate 3D geometry and data and semantics (i.e., high-level object type). You cannot edit it as you could a native object.

TIP: In Vectorworks, you can edit the geometry of an IfcEntity object by using the "Enter Group" command and standard geometric editing tools.

[VincentCuclair]

As long as ifc is static information imported into VW there needs to be an improvement in the management UI of these files.....if we receive an IFC file from all the disciplines involved (ie. At least 4 or 5) and with the knowledge that we will be getting edited versions every month for up to a year in some cases, we need an easier, clearer and more intuative way of viewing, updating and editing them. Not having worked so much with this however I can't help wondering what will happen to VW speed and stability when working on larger projects when quadrupeling the amount of 3D data in one file.......

Edited October 12, 2010 by Vincent C

[VincentCuclair]

DWorks, this is what we mean by IFC not being "parametric". IFC is about sharing and referencing data-rich 3D building models, not about file exchange from one native format into another.

Though I'm an adamant loather of all things dwg, i don't understand why if parametric object support integration is not high on the priority list why bother, why not take an already widely accepted transferable file format (dwg) and base it on that? I for one still use dwg vs ifc = 100:0% of the time. (and have started considering using pdfs because once referenced, all you subsequently need to do is update the actual pdf and Bobs your uncle.)it's all about ease of use and time saving.

It also beats me why if all information is included in the the IFC why it then isn't possible to have an option to convert to parametric objects on import......