IFC en Revit

Vaak hoor ik het verhaal dat Revit geen goede IFC kan leveren. Hierbij wordt Autodesk aangeduid als een grote speler die heel de AEC-tak op Revit wil krijgen en dat ze daarom bewust geen goede IFC wil aanleveren. Ik vind deze stelling flauwekul!

Ik zal het hier proberen uit te leggen: IFC kent een database structuur waarin een record een object voorstelt. In dat record wordt dan de klasse aangegeven (bv. “Wall” of “Window” etc.), zijn bovenliggende klasse (bv. “Huis”) en zijn onderliggende klassen (bv. raam in de wand), ruimtelijke beschrijving van het object, en verschillende eigenschappen (properties) en een GUID (Globally Unique Identifier) dit is een naam/nummer die uniek is voor het object overal op de wereld. IFC is in 1995 gestart en gebaseerd op de STEP beschrijving. De VCA (Ver. Computergebruik Architecten) Jos Bolder heeft in 1989 hier nog aan meegeholpen.
STEP en de klasse beschrijvingen (express schema) worden al door verschillende industrieën volledig gebruikt. Jouw koplamp in je auto heeft een GUID waarmee het onderdeel getraceerd kan worden in het gehele ontwerp-, maak- en beheersproces.

Verschillende CAD pakketten kunnen met IFC overweg. Hierbij wordt voor elk project in een CAD/BIM programma een database (tabel) aangemaakt. Deze tabel is direct verbonden met de objecten/entiteiten die in het CAD programma worden gebruikt. Deze informatie kan 1 op 1 overgezet worden in een IFC file. CAD programma’s bestaan uit verschillende “engine’s”. Bij Revit wordt onder andere gebruik gemaakt van Parametrics; zie geschiedenis een engine die een “relationele” database structuur kent. In 1996 gebruikte Archidesign (opvolger van Architrion) dezelfde engine waar ik nog een aantal jaren aan heb gewerkt… Dit is een structuur die uit verschillende tabellen bestaan die via verschillende ID’s met elkaar verbonden zijn. Je kan het vergelijken met een kadaster database die via postcode en huisnummer verbonden wordt aan een AH bonuskaart database. Zodat je weet hoe hoog je hypotheek is en of je wel een biefstuk op tafel hebt staan!

De database engine van Revit werkt dus met meerdere tabellen afhankelijk van de “family” die gebruikt wordt en welke “relatie” die het aangaat met andere family’s. Een goed voorbeeld is een systeemgrid plaatsen en daar een wand op vast klikken en de “slotjes” dicht zetten zodat bij verplaatsing van het systeemgrid de wand meegaat. Revit bestaat alleen maar uit dit soort ID’s. Bij het maken van family’s door de gebruiker moet in feite een protocol worden afgewerkt zodat bij het “plat slaan” van relationele tabellen in een IFC tabel de juiste zaken meegenomen wordt.

Bij andere CAD programma’s wordt dit door de software verzorgd zoals Archicad en Allplan. Bij VectorWorks is de IFC tabel zelfs de native opslagstructuur! En via een plugin is het ook mogelijk om in SketchUp een IFC aan de componenten te hangen.

Even voor de goede orde; elk CAD programma heeft verwijzingen naar een materialen bibliotheek en dergelijke maar deze relatie is duidelijk 1 op 1. Ook in Revit is dat zo. Het gaat hier meer om de relaties (ID) tussen de families. Autodesk heeft dan ook de code  van de IFC exporter in open source gezet zodat wij zelf in de families de juiste linken kunnen maken. Hier ligt voor de RevitGG een aardige uitdaging!

Algemene conclusie: de export van IFC uit Revit is door het vrijgeven van de broncode kneedbaar en aanpasbaar, daar waar bij de meeste andere pakketten het geëxporteerde model strak omlijnd is doordat het native vanuit de software wordt geregeld. Dit maakt de IFC export vanuit Revit in potentie enorm krachtig. Maar tegelijkertijd is het voor veel gebruikers een beperking…
Hoe meer knoppen hoe meer mogelijkheden, maar ook hoe moeilijker het is om met het programma tot resultaten te komen.