IFC-Typen richtig einsetzen: hohe Detaillierung bei kleiner Dateigrösse

Hochdetaillierte Modelle sind im Building Information Modeling (BIM) längst Standard. Mit der Detaillierung wächst aber auch die Dateigrösse, und ab einem gewissen Punkt leidet die Arbeit darunter: Viewer laden langsam, der Austausch über die gemeinsame Datenumgebung (Common Data Environment, CDE) stockt, und auf Tablet oder Baustelle wird das Modell unbrauchbar. Die gute Nachricht: Detaillierung und Dateigrösse hängen weniger eng zusammen, als viele annehmen. Der Schlüssel liegt in der korrekten Nutzung von IFC-Typen.

Typ und Vorkommnis: das Grundprinzip in IFC

Die Industry Foundation Classes (IFC) trennen sauber zwischen zwei Ebenen:

• Der Typ beschreibt eine Produktart einmal zentral, zum Beispiel ein bestimmtes Türmodell, einen Stuhl aus dem Herstellerkatalog oder eine Schienenbefestigung. In IFC sind das Entitäten wie IfcDoorType, IfcFurnitureType oder IfcColumnType, abgeleitet von IfcElementType und IfcTypeObject.
• Das Vorkommnis ist das konkrete Bauteil im Modell, also die einzelne Tür an ihrer Position. Dafür stehen die Klassen IfcDoor, IfcFurniture, IfcColumn und weitere.

Verbunden werden beide Ebenen über die Beziehung IfcRelDefinesByType: ein Typ, beliebig viele Vorkommnisse. Genau diese Trennung ist die Grundlage für schlanke Modelle.

Wo die Dateneinsparung wirklich entsteht

Ein Typ definiert nicht nur Eigenschaften, sondern kann auch die Geometrie tragen. Dafür hält der Typ eine Geometrie-Vorlage über IfcRepresentationMap bereit. Jedes Vorkommnis verweist anschliessend nur noch auf diese Vorlage, und zwar über einen IfcMappedItem zusammen mit einer Transformation (IfcCartesianTransformationOperator), die Position, Drehung und gegebenenfalls Skalierung festlegt.

Das Prinzip kennen Fachpersonen aus anderen Werkzeugen: In AutoCAD entspricht es dem Block, in Revit der Familie. Die Geometrie wird einmal gespeichert und an vielen Stellen instanziert.

Vereinfacht sieht das im IFC-Datensatz so aus:

#100 = IFCREPRESENTATIONMAP(#101, #110);      /* Geometrie-Vorlage, einmal definiert */
#110 = IFCSHAPEREPRESENTATION(...);           /* die eigentliche Stuhl-Geometrie */
#200 = IFCFURNITURETYPE('...', ..., (#100));  /* der Typ verweist auf die Vorlage */

/* je Vorkommnis nur eine Referenz plus Transformation: */
#301 = IFCMAPPEDITEM(#100, #310);             /* Stuhl 1 */
#310 = IFCCARTESIANTRANSFORMATIONOPERATOR3D(..., 1.0);
#401 = IFCMAPPEDITEM(#100, #410);             /* Stuhl 2 */
#410 = IFCCARTESIANTRANSFORMATIONOPERATOR3D(..., 1.0);

Statt die vollständige, tessellierte Geometrie hundertfach zu wiederholen, steht sie genau einmal in der Datei. Jedes weitere Vorkommnis kostet nur noch eine Referenz und eine Transformationsmatrix, also wenige hundert Byte.

Der gleiche Mechanismus greift bei den Daten: Eigenschaften und Materialien lassen sich über den Typ einmal zuweisen (IfcRelDefinesByType für Eigenschaftssätze, IfcRelAssociatesMaterial für Materialien) statt sie in jedes Vorkommnis zu kopieren.

Ein Rechenbeispiel aus der Praxis

Angenommen, ein Modell enthält 800 identische, detailliert modellierte Stühle. Eine fein triangulierte Stuhlgeometrie umfasst je nach Auflösung schnell rund 150 Kilobyte im IFC-Text.

Die Zahlen sind Richtwerte, die Grössenordnung stimmt aber. Wichtig: Die Detaillierung der einzelnen Stühle bleibt in beiden Fällen identisch. Eingespart wird ausschliesslich die Wiederholung. Neben der Dateigrösse profitieren auch Ladezeiten und Darstellung, da viele Viewer instanzierte Geometrie über die Grafikkarte effizienter verarbeiten.

Zwei Vorteile, die man auseinanderhalten sollte

Typen bringen zwei unabhängige Vorteile, die in der Diskussion oft vermischt werden:

1. Zentrale Datenverwaltung. Eigenschaften, Klassifizierung und Materialien stehen einmal am Typ. Eine Änderung wirkt auf alle Vorkommnisse. Das schafft eine verlässliche, einzige Datenquelle.
2. Geometrie-Instanzierung. Identische Geometrie wird über IfcRepresentationMap und IfcMappedItem nur einmal gespeichert.

Die spürbare Reduktion der Dateigrösse stammt vor allem aus dem zweiten Punkt. Der erste Punkt zahlt auf Datenqualität und Pflegeaufwand ein, auch dann, wenn die Geometrie nicht geteilt wird.

Wann sich IFC-Typen lohnen, und wann nicht

Typen sind kein Selbstzweck. Sie entfalten ihren Nutzen bei wiederkehrenden, standardisierten Bauteilen.

Gut geeignet:

• Katalog- und Herstellerprodukte mit fester Geometrie: Türen, Fenster, Möbel, Sanitärobjekte, Leuchten, Befestigungsmittel.
• Repetitive Elemente im Infrastrukturbau: Schwellen, Schienenbefestigungen, Fahrleitungsmasten, Signale, Schächte, Leitplankenpfosten.
• Vorfabrizierte Bauteile, die mehrfach identisch verbaut werden.

Weniger geeignet:

• Einzigartige Geometrie ohne Wiederholung: Ortbeton, Geländemodelle, individuell geformte Wände, Trassen und Alignments. Hier entsteht durch eine erzwungene Geometrie-Vorlage kein Spareffekt, sondern nur zusätzlicher Verwaltungsaufwand.
• Vorkommnisse, die sich geometrisch unterscheiden. Eine geteilte Vorlage setzt identische Geometrie voraus. Nicht-uniforme Skalierung über die Transformation verzerrt das Bauteil und ist keine saubere Lösung. Für echte Varianten verwenden Sie besser je einen Typ oder eine parametrische Repräsentation.
• Übertypisierung. Ein eigener Typ je Einzelvorkommnis bringt den Datenvorteil, aber keine Geometrie-Einsparung, und erhöht die Anzahl der Entitäten unnötig.

Ein praktischer Hinweis zum Datenaustausch: Ob geteilte Geometrie tatsächlich als IfcMappedItem exportiert wird, hängt vom Autorenwerkzeug und seinen Exporteinstellungen ab. Nicht jede Software schreibt instanzierte Geometrie automatisch. Eine Kontrolle nach dem Export lohnt sich daher immer.

IFC-Typen in Blender mit Bonsai setzen

In Blender übernimmt das Bonsai-Addon (vormals BlenderBIM) die IFC-Autorenschaft. Für mehrere gleiche Objekte gehen Sie so vor:

1. Geometrie einmal modellieren. Erstellen Sie das Bauteil, zum Beispiel einen Stuhl, ein einziges Mal sauber.
2. Type Manager öffnen. Bonsai stellt im Properties-Editor einen Type Manager bereit, der die Element-Typen nach IFC-Klasse gruppiert.
3. Neuen Element-Typ anlegen. Wählen Sie die passende Typklasse, etwa IfcFurnitureType, vergeben Sie einen sprechenden Namen und ordnen Sie die modellierte Geometrie als Vorlage zu.
4. Vorkommnisse erzeugen. Platzieren Sie die Instanzen aus dem Typ heraus. Die neuen Objekte teilen sich die Geometrie des Typs. In Blender entspricht das verknüpften Duplikaten (Alt+D), die denselben Mesh-Datenblock nutzen, im Gegensatz zu vollständigen Kopien (Shift+D).
5. Bestehende Objekte zuordnen. Sind bereits gleiche Objekte vorhanden, markieren Sie diese, wählen den Zieltyp und weisen ihn über die Typ-Zuweisung zu. Damit die Geometrie wirklich geteilt wird, müssen die Vorkommnisse dieselbe Repräsentation referenzieren.
6. Exportieren. Beim Schreiben der IFC-Datei legt Bonsai die Geometrie einmal als IfcRepresentationMap ab, und jedes Vorkommnis erhält einen IfcMappedItem.

Wer den Vorgang automatisieren möchte, etwa für viele Bauteile aus einer Liste, nutzt die IfcOpenShell-Programmierschnittstelle direkt:

import ifcopenshell.api

# bestehende Objekte einem Typ zuordnen
ifcopenshell.api.run("type.assign_type", model,
    related_objects=[stuhl_1, stuhl_2, stuhl_3],
    relating_type=stuhl_typ)

Qualitätssicherung: Instanzen prüfen

Verlassen Sie sich nicht auf die Annahme, dass instanziert wurde, sondern prüfen Sie es. Mit IfcOpenShell zählen Sie Geometrie-Vorlagen und Instanzen mit wenigen Zeilen:

import ifcopenshell

model = ifcopenshell.open("modell.ifc")
maps = model.by_type("IfcRepresentationMap")
mapped = model.by_type("IfcMappedItem")
print(f"{len(maps)} Geometrie-Vorlagen, {len(mapped)} Instanzen")

Ein gutes Verhältnis zeigt sich an wenigen Vorlagen bei vielen Instanzen. Sehen Sie dagegen kaum IfcMappedItem, obwohl das Modell viele gleiche Bauteile enthält, wurde die Geometrie wahrscheinlich dupliziert statt referenziert. Ergänzend liefert ein Blick auf die Dateigrösse vor und nach der Umstellung den direkten Nachweis.

Aus der Praxis: Fahrbahnmarkierungen im Tiefbau

Ein aktuelles Projekt zeigt, wo die Theorie auf reale, aus Vermessungsdaten abgeleitete Geometrie trifft: rund 980 Fahrbahnmarkierungen einer Kantonsstrasse (Haifischzähne, Leitlinien, Fussgängerstreifen, Sperrflächen, Längslinien), modelliert nach Fachdatenkatalog Kanton Zürich als IfcSurfaceFeature mit PredefinedType PAVEMENTSURFACEMARKING.

Ein erster Stolperstein: IfcSurfaceFeature besitzt im Schema (Stand IFC4.3) gar kein eigenes Typ-Objekt wie IfcDoorType oder IfcFurnitureType. Für "gleiche Elemente" bleibt deshalb nur IfcGroup als fachliche Klammer, während die Geometrie-Einsparung weiterhin unabhängig davon über IfcRepresentationMap und IfcMappedItem läuft. Datenverwaltung (Gruppierung) und Geometrie-Instanzierung sind hier also entkoppelt, weil das Schema für diese Klasse keinen dedizierten Typ vorsieht. Ein guter Reminder, dass "Typisierung" im IFC-Sinn nicht zwingend ein IfcXxxType-Objekt braucht.

Von den rund 980 Markierungen liessen sich 874 Instanzen (vier Formgruppen: Leitlinie, Haifischzähne, Fussgängerstreifen, Sperrfläche) über nur vier IfcRepresentationMap-Vorlagen abbilden. Die restlichen rund 110 Instanzen (Längslinien, Sonderformen) hatten von Bauteil zu Bauteil zu grosse Formvarianz, weil ihre Länge und Kontur dem jeweiligen Strassenverlauf folgt, und bekamen bewusst je eigene volle Geometrie. Genau die Abwägung aus dem Abschnitt "Wann sich IFC-Typen lohnen, und wann nicht" oben, angewendet auf einen realen Datensatz statt auf ein Lehrbuchbeispiel.

Eine Einschränkung gehört ehrlich dazu: Auch innerhalb der vier geteilten Formgruppen sind die Instanzen nicht wirklich identisch. Ein Haifischzahn ist 66.8 cm lang, der nächste 65.1 cm. Um trotzdem eine gemeinsame Vorlage nutzen zu können, kam pro Instanz eine nicht-uniforme Skalierung über IfcCartesianTransformationOperator3DnonUniform zum Einsatz. Das widerspricht direkt der oben genannten Regel, dass nicht-uniforme Skalierung das Bauteil verzerrt und keine saubere Lösung ist. In diesem Fall ist es ein bewusster, offen kommunizierter Kompromiss: Die Formabweichungen liegen im Bereich weniger Prozent und sind für eine Fahrbahnmarkierung im Massstab einer ganzen Strasse irrelevant. Bei Bauteilen, deren Massgenauigkeit zählt, etwa Türen, Fenstern oder Befestigungsmitteln, wäre dasselbe Vorgehen falsch, und es gilt tatsächlich die Regel aus dem Abschnitt oben: für echte Varianten je einen eigenen Typ verwenden.

Zwei konkrete Fallstricke tauchen typischerweise auf, sobald die geteilte Geometrie nicht aus sauber modellierten Katalogobjekten stammt, sondern aus Vermessungs- oder CAD-Rohdaten abgeleitet wird:

• Rotations-Instabilität. Wird die Ausrichtung jeder Instanz aus einer Bounding-Box abgeleitet (zum Beispiel "längste Kante = Richtung"), kippt diese Berechnung bei Formen mit annähernd quadratischem Seitenverhältnis um, sobald sich die Kontur zwischen Instanzen nur minimal unterscheidet. Ergebnis: zufällig verdrehte Instanzen trotz korrekt geteilter Vorlage. Abhilfe schafft eine geometrisch stabilere Referenz, etwa bei dreieckigen Formen der Vektor vom Schwerpunkt zum am weitesten entfernten Eckpunkt, statt der Bounding-Box-Kante.
• Selbstüberschneidende Konturen. Aus DXF oder anderem CAD übernommene Polylinien sind nicht garantiert einfach (simple). Eine sich selbst schneidende Kontur liefert bei der Flächenvermaschung, egal ob per Ear-Clipping, Blenders Fill-Operator oder anderer Triangulierung, unvorhersehbare bis invertierte Dreiecke. Eine explizite Prüfung vor dem Bau der Vorlage (zum Beispiel shapely.Polygon.is_simple) und eine automatische Reparatur (Polygon.buffer(0)) fangen das zuverlässig ab. In diesem Projekt betraf das 9 von rund 980 Instanzen.

Die im Artikel empfohlene Verifikation zahlt sich aus: Am Ende standen 4 IfcRepresentationMap für 874 IfcMappedItem plus rund 110 individuelle IfcPolygonalFaceSet für die Instanzen, bei denen sich Teilen fachlich nicht gerechtfertigt hätte.

Fazit

Eine grosse IFC-Datei ist selten eine Folge hoher Detaillierung, sondern meist eine Folge wiederholter Geometrie. Wer Typen korrekt einsetzt, speichert identische Bauteile einmal und referenziert sie beliebig oft. Das Ergebnis: schlanke Modelle bei voller Detailtiefe, schnellere Viewer und ein reibungsloser Austausch über die gemeinsame Datenumgebung. Entscheidend ist die richtige Anwendung. Typen gehören zu repetitiven, standardisierten Bauteilen, nicht zu einzigartiger Geometrie, und sie ersetzen keine saubere Modellstruktur.

Bimatic unterstützt Sie dabei, von der sauberen Modellierungsgrundlage bis zur automatisierten Verarbeitung ganzer Bauteilkataloge. Von der Basis zur Automation. Kontaktieren Sie uns, wenn Sie Ihre IFC-Modelle schlank und prüfbar halten möchten.