March 9, 2014

BIM math

An interesting equasion surfaced this last week:

B + I(fc) + M = BIM.

The whole debate started with the release of Sketchup 2014. One of the major new features (and certainly the one that caught the most attention) is that Sketchup now has support for IFC. And other data schemes such as COBie or anything you come up with yourself.
And because of the support of IFC, Sketchup now surely qualifies for the term "BIM".
In other words: a Building Model that works with IFC automatically constitutes BIM. Let's try some logical reasoning here.


Step 1: a Model.


We can all agree that for BIM to take affect, there needs to be a Model of some sort. We can also agree that any 3D modeller, including Sketchup, is capable of creating a Model.


Step 2: an Information Model.


Ok, just a random dumb representation of reality does not constitute BIM. If it would, the LEGO Architecture sets would constitute BIM, since those are models too. So at some point Information needs to be added to the mix.
Here's how:
1. There's data in a Model: all geometric and non-geometric properties of any objects inside the Model or the Model as a whole. By creating a Model the author by definition adds this data.
2. This data will become information at that point in time when the data is reused. Data that is not reused, cannot be classified as information. Why not? Because the concept of information implies a sender AND a receiver. Information is useful data. How can it be useful if it cannot be used?
3. An Information Model therefor is a Model containing reusable data.
Does Sketchup create Information Models? Well, yes. It does. You can create a Model (step 1), which has geometrical data, and then add some more non-geometrical data (IFC or COBie data for instance). Exporting this to IFC means this data can be received and reused by someone else. Which means we now have an Information Model.


Step 3: a Building Information Model.


Up until the moment I learned about Sketchup's new IFC feature I took this "Building"-part for granted. Whether it's the noun or verb, off course we're talking about Building(s). We're in the AEC sector right?
However, the Sketchup claim to BIM made me realize something: the term "Building" does not just specify our trade. It also applies a logical connection between Model components that add up to more then a sum of all parts.

Translated into real-world scenario:
Buying all your bricks, concrete, steelwork, ducts, pipes, doors, windows, and all other parts of a building does not actually give you a building. Randomly tossing them on the construction site does not either. They have to be processed in a certain order and specific way to actually form a building together. By doing so, you not only have the components themselves but also the interaction between those components that create the actual building.

Same goes for the digital representation: BIM is not about having all the components floating around somewhere, nor is it about having all kinds of information attached to those components. What sets BIM apart from just information-enriched models is the fact that these components have relationships, a (rudimentary) awareness of their surroundings. And can interact with them.

And, regrettably, that's where Sketchup falls short at the moment. The SU engine does not have the ability to let components have a relationship, a hierarchy between each other and with the project as a whole. Which means that there is no such thing as a Building Information Model possible. The SU export to IFC can classify components in the IFC scheme, but as far as I can tell at this point, it's not able to establish hierarchy between components (Window > Wall > Building Storey > Bulding > Site > Project). Which makes it a non-valid IFC (the hierarchy is mandatory!), and worse: not a BIM. Sketchup's interpretation of IFC is a classification system. Nothing more, nothing less.

Does this render IFC in Sketchup useless?


Well no, off course not. Having the ability to map and export to IFC is a huge interoperability improvement. Having the ability to add information and export that is awesome. Imho, it takes Sketchup from a Modeller to an Information Modeller. Just don't count on it being an acceptable BIM. 


Will there ever be Sketchup BIM?



Why not...? All they have to do is embed a form of hierarchy in their modelling engine. However, this might just be the most challenging task possible. We all know that more hierarchy and relationships mean more constraints. More constraints mean less intuitive modelling. And wasn't just that generally considered SU's best feature?

The question is: why would they? What's wrong with just having a freeform modeller to quickly conceptualize design ideas? Why does that *need* to be BIM? After all, some of the most BIM-minded architects I know still use hand sketches in the earliest stages of design to channel their creative thoughts with a speed and flexibility no BIM software could achieve (in the near future). And they all use Sketchup as a digital representation of this thought-process.

And I'm wondering: why would Trimble want to move so eagerly into the realm of "real" BIM software, where they will just be one of the guys, while they now have a tool far superior for it's specific task?

January 16, 2014

The Paradox of IFC

I had an interesting discussion with mr. Velez, the head developer IFC from Autodesk. Which I thought would be nice to share with you all...

I reached the conclusion that there's an interesting loophole in place when it comes to the acceptance of IFC in the AEC industry. I could even say in the Revit-using part of it, but that would probably sell the non-Autodesk disbelievers short. So let's keep it general for now. Don't know how Angel feels about my philosofical insights yet, since he's sleeping now (hopefully). But here it goes:

Standard conversation.

Let's lay out the standard IFC-conversation I have with a lot of people not wanting to use IFC:

Them: We need partners to work with Revit
Me: Why?
Them: because we can't communicate if they don't, which kinds of defeats the purpose of BIM
Me: Why won't you use IFC then?
(from this point onward, the discussion is the same for people using other software, regardless on whether they use IFC or not)
Them: because there's always a loss of information
Me: No there isn't
Them: Yes there is.
Me: Maybe when you do it, I can get any piece of information I want
Them: No you can't
(btw, I never said these conversations are very intellectually challenging)
Me: Have you tried?
Them: Yes, we exported an IFC once. It sucked. All kinds of information missing.
Me: What settings did you apply?
Them: Settings...?
And so on...
Point is: IFC has difficulty in getting accepted because of the supposed loss of information when exchanging models. And that's partly right, however for the wrong reasons. Insufficient implementation in (ALL!) software is what's causing this, not IFC itself. The format is capable of carrying through each and any piece of information you would ever put in your model, and much more. Losless. It's just not implemented that way.
Getting this done is actually the easy part of IFC implementation. It's just a matter of mapping. Which native parameter goes into it's IFC counterpart. And which ones don't have an IFC counterpart? Nice to know, since IFC does allow you to create custom properties for any and all objects.
It's supposed to be relatively simple...

So why aren't we fixing this?


Basically because everybody keeps focussing on getting all the geometry right.
And off course this is important. You don't want to be losing all kinds of objects. But seriously: how often does this happen? 
Let me rephrase: how often does it happen and NOT because of the guy modelling it?

Cause I haven't seen it yet. I haven't seen ANY project where the loss of geometry was NOT caused by the way stuff was modelled, exported, or mapped. Period. And I've seen a lot, trust me. So maybe I haven't seen those few projects where there actually is an inexplainable loss of geometry. But it can't be more then a handful.
Yet there seems to be a huge imbalance between geometry and information in terms of focus and budget. As in: the focus is almost solely on geometry, leaving the information part with improvements that require no more then an hour of programming time max.

Is geometry that important?


No it isn't. Not in my opinion anyway. Now don't start with that "but you're just a consultant, we have real projects" bull. My clients aren't toying around all day and I get paid to deliver results, just the same as anyone else. No results = byebye consultant (even more easily then with employees I might add). It's not about projects, it's about the process.

The majority of firms uses IFC throughout the project as a means of communicating with different project partners. So you get an update every other week or even weekly. Those are used for clash detection, design sessions and so on.

By definition there is stuff missing, incomplete or not there. You're still in the design phase for crying out loud. It's supposed to be that way! Seriously, who cares whether stuff is missing because of the fact it's yet to be designed, or because something went wrong in the export. In fact, there's only one point in time when the IFC needs to be perfect, and that's when it's time to create the deliverable. And I'd rather experience all those errors upfront instead of upon delivery. That way they pop up during design sessions. And I can fix them...

So no, I'm not saying we should except the fact that stuff might go wrong. I am however saying that the impact of those errors is grocely overrated. The first thing I say when someone starts telling me horror-stories about IFC's not being correct is "wow, what did that cost you in penalties from your clients?". I usually get a blank stare... Followed by "uhm, they never knew. We found out during our first design meeting and fixed it".

Fact of the matter is: these are tools. Tools fail sometimes. Revit fails some times. Project files get corrupted all the time. Stuff goes missing, gets omitted from schedules due to wrong filters or modelling methods. Gets accidentally deleted because it's on the wrong Level or a Linked element that is remodelled.
How can someone using Revit tell me that they intend to focus solely on geometry when it comes to IFC until it's 100% reliable? Like Revit is? But when it comes to our primary tool, we build safeguards in our process. So why regard IFC differently?

Now for the Paradox.


On the one hand it's usage in the (Revit-minded) AEC industry is being held back by the general consensus that you lose information when exchanging IFC's. On the other hand, the people that DO use IFC with Revit pressure Autodesk into allocating the vast majority of their resources into focussing on geometry exchange instead of fixing the information drain. 

At the same time, fixing the information loss can be overcome rather easily. It's a User Interface thing. You need to be able to map information from Revit to IFC and back. That's it. The second part, the geometry is way, way more complicated. Needs far more resources.

Now since Autodesk is a commercial company they, to some extend, listen to their customers and drive development on their needs. And budgets are defined based on the size of the (expected) user base and commercial gain. Nothing wrong with that, that's how commerce works. The guy paying the bills gets to make the decisions. 

What we have here is the situation where existing IFC users force Autodesk away from implementing relatively cheap solutions that would actually make IFC more attractive for non-users (eliminating loss of information), which generates a bigger user base, which in turn generates larger funds to tackle the more complicated geometry-related problems.

The Paradox of IFC Implementation is that that the people actually using it with Revit prevent Autodesk from taking big steps in the implementation of it's strongest feature (and major advantage towards geometry based formats such as 3D dwg): the ability to exchange object information.

How to solve this?


I don't know really. Somehow I don't think that after reading this everyone will say "he's right, what was I thinking? Silly me...".
But I am glad I focus on the "easy" part of IFC. That might just make it possible to have another go at the whole programming thing and start doing it  myself.
More on that later...

January 8, 2014

Seasons Greetings

A bit late, but hey: better late then never... And, I promise not to swear this time!

I'm trying to type this while on the train, homeward bound from a day of Dutch museums with the kids in Amsterdam. Sitting in the entrance platform because my youngest fell asleep in the buggy. So we just boarded her while sleeping...
Looking at my 2yr old I can't help but noticing: kids her age eat, play, talk and sleep to the fullest. They don't hold back, they don't bite their tongue. When they laugh, they do so with their whole being. If they cry, it's because their world is ending. And at this point: she's not just dozing. She's not even sleeping. She's completely knocked out...

My eldest is eight. And she's already starting to loose this ability. It's probably what we call "socially accepted behavior" that's kicking in. But while learning to be civilised, we also constrain ourselves in other ways. We seem to forget how wonderful it is to experience the wonderful thrill of unfiltered joy and excitement. The cleansing power of uncensored sadness.

I'm wondering: does this dampening blanket of social standards constrain us in our work? In my last post I went nuclear on a guy who flamed me for no reason (well, in my opinion anyway). Why? Because I'm passionate about what I do. And constraining myself all the time feels like a betrayal towards that passion.

Off course my wife tells me that I probably shouldn't do that kind of stuff. Keep calm, be the better man.  That I can accomplish more if I keep my cool and be diplomatic. And she's probably right...
But you know what: I don't think it's a bad thing actually. I love it when my inner child takes over, flooding with excitement to get to work and make stuff happen. And I accept that the same child has it's temper when attacked. I actually embrace it. If I didn't care about getting crapped upon, it would mean I lost my passion.

Here's my seasons greeting to you all: may you find your inner child just a few times this year. Loose yourself in joy and excitement. Feel the uncontrollable urge to high-five everyone you meet while dancing the entire route to work.

But keep in mind though: you might not want to hit send when your inner child starts writing your emails... Luckily, there's an app for that: https://play.google.com/store/apps/details?id=com.app.scheduled.emailLite

Best of luck to you all in 2014!