Was ist der Unterschied zwischen BCF 2.1 und BCF 3.0?

Der Inhalt ist weitgehend gleich – Themen, Kommentare, Viewpoints mit Kamera, Auswahl, Sichtbarkeit und Schnittebenen. Die Struktur unterscheidet sich: In 2.1 sind Kommentare und Viewpoint-Verweise Geschwister des Topic-Elements in markup.bcf; in 3.0 sind sie im Topic verschachtelt, Labels und andere Listen stecken in Container-Elementen, die perspektivische Kamera verlangt ein AspectRatio, und Projekterweiterungen beschreiben die zulässigen Werte. Werkzeuge, die ein Layout lesen, verwerfen oft stillschweigend Daten des anderen.

Warum geht ein BCF-Viewpoint an der falschen Stelle auf?

Meist, weil das exportierende Werkzeug die Kamera in den Achsen seiner eigenen Szene statt in IFC-Weltkoordinaten geschrieben hat. Web-Viewer auf Basis von three.js nutzen eine Szene mit Y nach oben, IFC dagegen Z nach oben; eine ohne Rückumrechnung exportierte Kamera kommt um 90 Grad gedreht an. Die andere häufige Ursache ist ein für die Darstellung angewandter Modellversatz, der vor dem Export nicht entfernt wurde.

Welche BCF-Version sollte ich verwenden?

Die, die jedes Werkzeug im Projekt korrekt liest – testen, nicht annehmen. BCF 2.1 ist nach wie vor am weitesten unterstützt; 3.0 ist präziser spezifiziert. Ein Werkzeug, das beide schreibt, lässt Sie je nach Empfänger wählen.

Zurück zum BIM- & IFC-Blog

Übergabe & ISO 19650 · 2026-10-01 · 10 Min.

BCF 2.1 vs. 3.0: Warum Ihre Issue-Ansichten an der falschen Stelle aufgehen

BCF soll dafür sorgen, dass ein Issue den Weg zwischen Werkzeugen übersteht. In der Praxis landet die Kamera unter der Erde, die Schnittbox verschwindet und die Labels sind weg. Die Ursachen sind wenige, konkret und behebbar – und wer sie kennt, weiß, welchen Werkzeugen er trauen kann.

BCF 2.1 vs. 3.0: Warum Ihre Issue-Ansichten an der falschen Stelle aufgehen — IFC Viewer Online article cover

BCF – das BIM Collaboration Format – hat eine einzige Aufgabe: Ein Issue soll ein Werkzeug verlassen und mit intaktem Kontext in einem anderen ankommen. Ein Kommentar, eine Kameraposition, eine Auswahl von Elementen, vielleicht eine Schnittbox. Öffnen Sie das Issue irgendwo, und Sie sehen genau das, was sein Autor gesehen hat.

Wer BCF zwischen drei Herstellern ausgetauscht hat, weiß, wie oft das scheitert. Die Kamera öffnet unter der Erde oder blickt in den Himmel. Die Schnittbox fehlt. Die Labels sind weg. Kommentare werden am ersten kaufmännischen Und abgeschnitten. Nichts davon ist ein Rätsel, und alles geht auf eine Handvoll konkreter Implementierungsfehler zurück.

Was wirklich in einer .bcfzip steckt

Eine BCF-Datei ist ein Zip. Darin liegt pro Thema ein Ordner mit einer markup.bcf (das Thema, seine Kommentare und seine Viewpoint-Liste), einer oder mehreren .bcfv-Viewpoint-Dateien (Kamera, Auswahl, Sichtbarkeit, Schnittebenen) und optionalen PNG-Snapshots. Alles ist schlichtes XML. Sie können eine entpacken und lesen – und wenn sich ein Werkzeug seltsam verhält, sollten Sie das tun.

issues.bcfzip
├── bcf.version
├── 1f2c…/
│   ├── markup.bcf        ← topic, comments, viewpoint references
│   ├── viewpoint.bcfv    ← camera, components, clipping planes
│   └── snapshot.png
└── 7a90…/
    └── …

2.1 gegen 3.0: die Unterschiede, an denen Importe scheitern

XML der markup.bcf in BCF 2.1 und BCF 3.0 nebeneinander, mit der Verschachtelung von Comments, Viewpoints und Labels — Dasselbe Issue in BCF 2.1 und 3.0. Kommentare, Viewpoints und Labels wandern ins Topic und in Container.

Aspekt	BCF 2.1	BCF 3.0
Kommentare in markup.bcf	Geschwister von <Topic>	Verschachtelt in <Topic><Comments>
Viewpoint-Liste	Geschwister von <Topic>	Verschachtelt in <Topic><Viewpoints>
Labels	Wiederholte <Labels>-Elemente, eines pro Label	Ein <Labels>-Container mit <Label>-Kindern
Perspektivische Kamera	Position, Richtung, Up-Vektor, Sichtfeld	Dasselbe plus ein verpflichtendes AspectRatio
Zulässige Werte	Implizit, außerhalb der Datei vereinbart	In Projekterweiterungen deklariert
Unterstützung in der Praxis	Nahezu universell	Wachsend, uneinheitlich

Das Datenmodell hat sich kaum geändert, das XML-Layout schon. Ein Parser für das eine Layout liest das andere als Thema ohne Kommentare.

Lesen Sie die Tabelle als Liste von Fehlerbildern. Ein Werkzeug, das Kommentare neben dem Topic sucht, findet in einer 3.0-Datei keine. Ein Werkzeug, das einen Labels-Container erwartet, liest eine 2.1-Datei so, als hätte sie ein Label – oder keines. Eine 3.0-Kamera ohne AspectRatio ist laut Schema ungültig, und manche Importer verwerfen den gesamten Viewpoint.

Warum die Kamera an der falschen Stelle landet

Achsendiagramm: IFC-Weltkoordinaten sind Z-oben und rechtshändig, eine three.js-Szene ist Y-oben; BCF-Kameras müssen vor dem Export zurückgerechnet werden — IFC ist Z-oben, three.js Y-oben. Ohne Umrechnung kommt die Kamera um 90° gedreht an; ohne Versatz an der falschen Stelle.

BCF-Kameras werden in den Weltkoordinaten des IFC-Projekts gespeichert: Meter, Z nach oben. Die meisten Web-Viewer rendern mit three.js, dessen Szene Y nach oben hat, und viele verschieben das Modell zum Ursprung, damit große georeferenzierte Koordinaten auf der GPU nicht zittern. Beides sind vernünftige Rendering-Entscheidungen. Beides muss rückgängig gemacht werden, bevor ein Viewpoint geschrieben wird.

Achsenumrechnung vergessen – und die Kamera kommt um 90° gedreht an, blickt in den Himmel oder durch den Boden.
Darstellungsversatz vergessen – und die Kamera kommt richtig ausgerichtet an, aber Hunderte Meter oder Kilometer vom Modell entfernt.
Kamera umgerechnet, Schnittebenen nicht – und die Ansicht stimmt, während die Schnittbox an einer ganz anderen Stelle schneidet.

Das Versatzproblem wird umso schlimmer, je besser Ihre Georeferenzierung ist, denn reale Koordinaten sind große Zahlen. Den Hintergrund liefert IFC-Koordinaten und Georeferenzierung.

Ein Zehn-Minuten-Test für jedes BCF-Werkzeug

Ein Issue mit allem anlegen Eine perspektivische Kamera in schrägem Winkel, zwei ausgewählte Elemente, eine Schnittbox, drei Labels und ein Kommentar mit kaufmännischem Und, Anführungszeichen und einem Umlaut.
Als 2.1 und als 3.0 exportieren Schreibt das Werkzeug nur eine Version, notieren Sie das – früher oder später treffen Sie einen Empfänger, der die andere braucht.
In ein zweites Werkzeug importieren Prüfen Sie Kameraausrichtung, Abstand zum Modell, Auswahl, Schnittbox, Anzahl der Labels und den Kommentartext Zeichen für Zeichen.
Hin und zurück Exportieren Sie erneut aus dem zweiten Werkzeug und importieren Sie zurück ins erste. Was einen Sprung übersteht, aber nicht zwei, kostet Sie irgendwann eine Besprechung.

Unser eigener BCF-Exporter wurde genau nach diesem Test neu geschrieben: Viewpoints werden jetzt in IFC-Weltachsen ohne Darstellungsversatz geschrieben, Schnittebenen reisen mit dem Viewpoint, 2.1-Labels werden als wiederholte Elemente geschrieben, und importierte Kommentare werden vollständig mit dekodierten XML-Entitäten gelesen. Er schreibt 2.1 und 3.0, damit Sie sich nach dem Empfänger richten können.

Konventionen, damit BCF-Themen bearbeitet werden

Ein Thema pro Ursache, nicht pro Element. Vierhundert Wände ohne Property Set sind ein Thema mit einem repräsentativen Viewpoint.
Regel oder Anforderung in den Titel. „Pset_WallCommon.FireRating fehlt – in Exportvorlage ergänzen“ ist umsetzbar; „Daten fehlen“ nicht.
Nach Revision labeln. Ein Thema aus Revision 6 sollte das sagen, damit ein späterer Vergleich es nicht doppelt anlegt.
Immer den Snapshot beilegen. Ihn sieht der Empfänger im Posteingang, bevor er irgendein Werkzeug öffnet – und oft ist er das Einzige, was er sich ansieht.

Wo BCF ins vollständige Lieferpaket gehört – neben Validierungsbericht und Übergabeschreiben –, behandelt was mit einem IFC-Modell übergeben werden sollte. Themen automatisch aus einem Revisionsvergleich anzulegen, zeigt zwei IFC-Versionen vergleichen.

BCF 2.1 vs. 3.0: Warum Ihre Issue-Ansichten an der falschen Stelle aufgehen