topic Re: IFC vs Adesk in Modeling

IFC vs Adesk

Rob — Thu, 05 Mar 2009 01:47:58 GMT

I have recently attended a quite interesting seminar about the green building design. Apart from usual fancy words about sustainability there was a really interesting outcome based on the recent study about energy efficiency of already built green-designed buildings. It said that the total amount of used energy was not different to non green-designed buildings at all. The study actually suggested that it is not the design that determines the green rating but how a building is being run within its life span.

The relevancy to this forum would be that Adesk attempts to potentially eliminate IFC is really short-sighted. There is no way that one company could effectively establish a standard that goes well beyond the design process and cover multinational standards, climate conditions etc. That makes me wonder about all that excitement in regards to Adesk acquisitions as it puts all of it in the light of market driven decisions which IMHO is destined to an utter failure. The market itself is reacting mostly to the current demand (by its definition along demand-supply lines). It does not look further (that is a building facility/energy management) as it is not possible to define building running costs precisely enough in a long run to determine the value of a building in regards to green initiatives.

A long story short:
- I am not trying to say that IFC is the perfect one but at the moment it is only serious (and viable) world-wide adopted initiative. So AC should stay with it.

- getting rid of (or ignoring) IFC in the future will leave our design attempts in vain, virtually reducing it to a 'green tick' on our building permits without any real impact to a life of the building itself.

- any attempts to sway IFC format to a 'dictate' of one company will result in a distorted market-preferred output (usable perhaps in design stages however ignoring the post-construction stage at all). In other words I use the interoperability format which is suitable when designing a building on a certain platform only however the further use in the post-construction stage is very limited as a platform developer is not covering this by their software solution (as I doubt it would be possible due to a huge diversity in that particular field). I think Adesk wants to cash on this ‘blinkers-on view’ but unfortunately from our accounts at the end.

Re: IFC vs Adesk

Rakela Raul — Thu, 05 Mar 2009 12:23:00 GMT

interesting post !!

to add something related to the green building and archicad at the same time:
a co-worker & ac12 user went to a LEED seminar (alot of architects taking the seminar!!) and believe it or not archicad was unknown to them.

Re: IFC vs Adesk

Erika Epstein — Thu, 05 Mar 2009 16:17:11 GMT

I agree; Lifecycle costs are an important part of both IFC and LEED.
LEED analysis affects all phases of work from pre-design through to Lifecycle.

I was watching a VICO webinar recently showing several case-studies of contractors who use Navisworks and the effect it has on construction costs. Use of clash analysis softwares such as Solibri (IFC) and Navisworks (3D DWG) should and perhaps are worth LEED points.

The results I saw were consistant with the savings, both time and money, achieved by Hensel Phelphs on a local high school project.

Contractors have been having VICO build 3D models for the building or consultant portions of the job when they are not provided with them. They are requiring their subs to use 3D software.

Re: IFC vs Adesk

Laura Yanoviak — Thu, 05 Mar 2009 19:19:53 GMT

There are SO many potential BIM applications (and Adesk can't own all of them), that IFC is a necessity. BIM for owners and facility managers, for architects and engineers, for contractors, subcontractors and fabricators. To abandon IFC would be to abandon the concept of BIM.

Re: IFC vs Adesk

Rob — Fri, 06 Mar 2009 02:51:31 GMT

for anyone who is interested this is a website of the company in Norway which runs IFC server:
http://www.epmtech.jotne.com/built-environment.79297.en.html

I have attended their seminar 3 years ago!!! the major features:

1. server based entirely on IFC so any software supporting IFC in/out can tap to the central database.
2. administration of data is purely in a domain of the server provider so coherency and clarity of IFC data is protected from any attempts of contributor's 'tweaking' in regards to standardised protocol.
3. also liability for security and data access privileges are with the server provider rather than any design-involved party (which could impose undesirable overheads).
4. accessible via the internet - the advantages are apparent

Re: IFC vs Adesk

SeaGeoff — Fri, 06 Mar 2009 07:18:50 GMT

I agree that IFC is essential. In a (more) perfect world IFCs would be capable enough that all BIM applications would use it as their native format. That in turn would unlock the potential of BIM servers, Software-as-Service offerings, Cloud-BIM and all manner of specialized analysis tools that could really help with energy modeling, collaboration, and sustainable design.

All of these things are technically feasible today. The problem is there is insufficient incentive to develop IFC to the degree required. To say A’desk is trying to kill IFC is a bit cloak and dagger. They are far bigger than Graphisoft, but like Graphisoft their products have unfulfilled wishlists thousands of items long. Why would they, or any developer, invest heavily in IFC it there is little demand. Most BIM is happening in the confines of isolated teams. Collaboration workflows sound nice, but they need curtain wall tools now.

And therein lies the rub. Crappy results=no demand. No demand=stalled development=crappy results.

The ice breaker is governments. If all the public sector projects that flow from the massive stimulus plans required real, working IFC models, and were held to high, verifiable standards then all the AEC firms doing all the grunt work would demand action form Graphisoft, Bentley, A’desk, and all the rest, as well from the consortium itself, to move this thing forward.

Re: IFC vs Adesk

Laura Yanoviak — Fri, 06 Mar 2009 16:20:44 GMT

Geoff wrote:
The problem is there is insufficient incentive to develop IFC to the degree required.

What's sad (scary?) is that the IFC effort is being undertaken with minimal funding and much volunteer effort. The level of support is not equal to its level of importance.

Re: IFC vs Adesk

Anonymous — Sat, 07 Mar 2009 02:14:54 GMT

Geoff wrote:
I agree that IFC is essential. In a (more) perfect world IFCs would be capable enough that all BIM applications would use it as their native format.

I don't think the solution is (or can or should) be IFC as a native or working format. There are just too many reasons that this is not feasible.

Foremost perhaps is that it is designed as an exchange format and not optimized for performance in a live working environment. Presently export/import are tediously slow and while this can certainly be improved (Solibri is pretty good in this regard) I doubt it can be made to match the speed of various softwares' own optimized formats. It is also inconceivable that GS, Autodesk, et al would be willing (or even able) to rewrite their programs to work with a substantially different data structure.

What would be great, and should be technically possible, is for all software to exchange data with an IFC model server in a manner similar to AC's teamwork. This way every one on the project can use whatever (IFC compliant) software they want and interoperate readily with all the other participants.

Of course performance will still be a major issue but it certainly should be better than the present "Save as...", "Export", "Import", "Link", "Publish", IFC, DWG, NWC, 3DS, PLN, MOD, RVT, DWF, PDF, etc, etc, etc... This ad hoc solution is clearly not sustainable in the long run.

Re: IFC vs Adesk

stefan — Thu, 12 Mar 2009 13:22:00 GMT

A fundamental problem: IFC will not reflect the potential of the software. So you have fancy features in Revit and other fancy features in ArchiCAD, but you would not be able to use them, as IFC does not support them.

If you export IFC from App X, many X-specific data is stored as custom properties. X could (in theory, as it's not bullet-proof) restore these properties when importing the IFC.

However, there is no guarantee that App Y, with different properties, filters the App X properties out. It will most certainly ignore them at import time and the question is will they be retained at export time?

So only when you can roundtrip an App X model into App Y and back into App X through IFC, without loss of your functionality, will people start using IFC on a server level.

You have probably seen the less-than-stellar IFC-compatible library objects from ArchiCAD, which can only do a fraction of the native IFC library objects.

Re: IFC vs Adesk

Rob — Fri, 13 Mar 2009 00:24:02 GMT

So only when you can roundtrip an App X model into App Y and back into App X through IFC, without loss of your functionality, will people start using IFC on a server level.

No this is not a necessary step. I am talking about 3rd party server service which will administer the data on the server. That means the server provider will coordinate and administer a set of 'rules' within IFC communication.

At the moment (after my experience) any coordination of such data inevitably lands on a desk of architects (being a project coordinator). This experience makes all BIM collaboration really painful as we have to look after several models at the same time and secondly when we are importing any consultant’s model we are getting lots of 'rubbish' with it too. That should be 'filtered' by the IFC server coordinator or whatever we will call them.

Re: IFC vs Adesk

Anonymous — Fri, 13 Mar 2009 06:58:50 GMT

stefan wrote:
So only when you can roundtrip an App X model into App Y and back into App X through IFC, without loss of your functionality, will people start using IFC on a server level.

Like Rob, I disagree with this. The server only has to retain (and the subscriber apps maintain) the data necessary to the particulars of the project. The specifics of this will vary depending on these particulars including the size and scope of the work, the available resources, the capabilities of the participants and the limitations of the software.

The enabling technology is just the set of management tools that can allow this to be set up and administered. The other main issue is performance. Even if the arrangement is possible in principle, it is useless in practice if the processes take longer than the time available.

The perfect world of totally transparent interoperability will never come. All we can do (and the best we can hope for) is to keep improving the tools and the process while we also keep getting the job done in the field.

Re: IFC vs Adesk

SeaGeoff — Mon, 16 Mar 2009 20:21:30 GMT

The fancy features tend to be more in the realm of tools and workflows. The product of those tools can and should be digital representations of real-world building assemblies, the vast majority of which are quite standard even if their particular geometry varies by region. That’s what IFCs are supposed to codify. I don’t think anyone expects a perfect world, just one where interoperability is recognized as a requirement and thus considered a development priority.

Re: IFC vs Adesk

stefan — Tue, 17 Mar 2009 08:43:28 GMT

And the opinion from the new Graphisoft CEO:

http://www.aecbytes.com/viewpoint/2009/issue_43.html

Re: IFC vs Adesk

Anonymous — Tue, 17 Mar 2009 17:35:04 GMT

stefan wrote:
And the opinion from the new Graphisoft CEO:

http://www.aecbytes.com/viewpoint/2009/issue_43.html

Looks like GS finally came up with THE structural package and it is called Revit Structural