BCF-Datei lässt sich nicht öffnen? Die häufigsten BCF-Probleme lösen
Kurze Antwort: Die meisten „kaputten BCFs“ sind gar nicht kaputt. Ein BCF kann auf fünf getrennten Ebenen scheitern – ZIP-Paket, Topic-Daten, Modell, Bauteilreferenzen und Viewpoint-Visualisierung – und jede hat ihr eigenes Symptom und ihre eigene Lösung. Prüfen Sie sie in dieser Reihenfolge. Lässt sich die Datei als ZIP öffnen und sind die Topics lesbar, ist mit dem Paket alles in Ordnung und das Problem liegt auf der Modellseite: falscher Modellstand geladen, referenzierte IFC-GUIDs existieren nicht mehr, oder das empfangende Tool interpretiert einen Teil des Viewpoints anders.
Zuerst: Auf welcher Ebene ist es gescheitert?
Die nützlichste Gewohnheit beim BCF-Troubleshooting ist der Wechsel der Frage. Nicht „warum ist das BCF kaputt?“, sondern „wie weit ist es gekommen?“
Arbeiten Sie sich von oben nach unten. Die erste Ebene, die sich auffällig verhält, ist das eigentliche Problem; alles darunter ist Folgeerscheinung.
Ebene 1: Die Datei öffnet sich überhaupt nicht
Die Anwendung weist das BCF ab, meldet eine ungültige Datei oder reagiert schlicht nicht.
Die Endung prüfen. Mit BCF 2.1 kam .bcf; beim Austausch mit BCF 1.0 und 2.0 war .bcfzip üblich. Manche Tools akzeptieren nur eine der beiden. Ein Umbenennen von der einen auf die andere Endung kostet nichts und löst die Sache erstaunlich oft – der Inhalt ist in beiden Fällen derselbe.
Prüfen, ob es wirklich ein ZIP ist. Ein BCF-Paket ist ein ganz gewöhnliches ZIP-Archiv mit einer anderen Endung – zum Hineinschauen genügen 7-Zip, WinRAR oder die Bordmittel von Windows und macOS.
Benennen Sie die Datei vorher um: aus issues.bcf von Hand issues.zip machen. Die meisten Archivprogramme rühren eine Endung nicht an, die sie nicht kennen – ohne das Umbenennen öffnet sich also gar nichts. (Windows blendet Dateiendungen standardmäßig aus. Schalten Sie sie im Explorer unter Ansicht → Anzeigen → Dateinamenerweiterungen ein, sonst machen Sie aus issues.bcf in Wahrheit issues.zip.bcf.)
Lässt sich das Archiv auch nach dem Umbenennen nicht öffnen, wurde die Datei beim Transport abgeschnitten oder von einem Mail-Gateway verändert. Lassen Sie sich die Datei erneut schicken – notfalls in ein weiteres Archiv verpackt, wenn das Mailsystem weiter dazwischenfunkt.
Öffnet sie sich, sehen Sie ungefähr das hier:
Das meiste davon ist optional – gut zu wissen, bevor Sie etwas für fehlend halten. Pflicht sind in beiden Versionen nur bcf.version und je Topic eine markup.bcf; Viewpoint, Snapshot und Bitmaps kann eine exportierende Anwendung schlicht weglassen. Zwei Einträge sind versionsabhängig: BCF 2.1 deklarierte die Projektwerte – Status, Typen, Prioritäten – in einem XSD-Schema namens extensions.xsd, auf das die optionale project.bcfp verweist. BCF 3.0 legt dieselben Werte als reine Daten in extensions.xml ab und verlangt diese Datei in jedem Paket. Eine 2.1-Datei kann also berechtigterweise keines von beiden enthalten, eine 3.0-Datei enthält immer extensions.xml und nie extensions.xsd. documents.xml und den davon verzeichneten Ordner Documents – im Paket mitgelieferte Anhänge, jeweils unter ihrer Dokument-GUID abgelegt und ohne Dateiendung, der echte Name steht in documents.xml – gibt es nur in BCF 3.0, und beide sind optional.
Die Version prüfen. Im Archiv deklariert bcf.version das Schema – 2.1 oder 3.0. Der Dateiname verrät das nie. Ist die Datei 3.0 und Ihr Tool älter, haben Sie die Antwort: Bitten Sie um einen Export als 2.1 oder konvertieren Sie die Datei. Unsere Anleitung zum Konvertieren zwischen BCF 2.1 und 3.0 zeigt einen Weg dorthin, und BCF 2.1 vs. BCF 3.0 erklärt, was sich zwischen den Versionen tatsächlich ändert.
Die Struktur prüfen. Ein gültiges Paket hat bcf.version auf oberster Ebene und je Topic einen Ordner mit mindestens markup.bcf. Wurde ein Paket von Hand neu gezippt, liegt oft alles eine Ebene zu tief – eine der zuverlässigsten Methoden, ein Archiv zu erzeugen, das kein BCF-Tool liest.
Ebene 2: Die Topics öffnen sich, mehr nicht
Die Liste der Issues erscheint, Titel und Kommentare sind lesbar, und damit endet es. Das ist kein Fehler, sondern normal: Ein BCF enthält keine Geometrie. Wenn Sie auch das Modell brauchen, geht es eine Ebene weiter.
Ebene 3: Es gibt kein 3D-Modell
Das BCF enthält Issue-Daten und Referenzen, nicht das Gebäude. Laden Sie das entsprechende IFC- oder native Modell und verknüpfen Sie es ausdrücklich mit dem BCF, falls das Tool danach fragt.
Manche Anwendungen erledigen diese Zuordnung selbst anhand der Dateiangaben im BCF-Header, andere fragen nach, welches Modell zu welchem Topic gehört. Die BCF-3.0-Dokumentation stellt klar, dass IFC-Dateien keinen eindeutigen Datei-Identifikator führen, der das Mapping zuverlässig macht. Die manuelle Zuordnung ist damit regulärer Bestandteil des Workflows und kein Notbehelf.
Wenn Ihnen zum IFC die passende Software fehlt: Wie man eine IFC-Datei ohne Revit öffnet.
Ebene 4: Das Modell ist geladen, die Bauteile lösen sich nicht auf
Symptom: Die Kamera landet ungefähr richtig, aber nichts ist selektiert – oder das halbe Modell verschwindet, sobald der Viewpoint aktiv wird.
Der Viewpoint referenziert Bauteile über IFC-GUIDs, und das empfangende Tool findet sie nicht. Das ist meist kein Fehler, sondern Drift:
Zwischen den beiden Ständen kann alles Mögliche passiert sein:
- Die Wand wurde gelöscht und neu modelliert und trägt jetzt eine andere GUID,
- die Geometrie ist verschoben,
- das Gebäude- oder Fachmodell wurde neu positioniert,
- die Zerlegung hat sich geändert – aus dem referenzierten Bauteil sind mehrere geworden,
- neue Bauteile verstellen der gespeicherten Kamera die Sicht,
- die Schnittebene schneidet nicht mehr dort, wo sie sollte.
Der erste Test ist immer derselbe: das BCF mit dem Modellstand öffnen, auf dem das Issue entstanden ist. Funktioniert es dort, ist am BCF nichts falsch – das Issue muss lediglich am aktuellen Modell neu aufgesetzt werden.
Passen die GUIDs auch auf dem ursprünglichen Stand nicht, vergleichen Sie sie direkt: Archiv entpacken, den Components-Block in der .bcfv-Datei lesen und diese GUIDs im IFC suchen. Damit trennen Sie „das Modell hat sich geändert“ von „das exportierende Tool schreibt Referenzen, die das importierende nicht verwerten kann“.
Ebene 5: Der Viewpoint greift, die Ansicht stimmt trotzdem nicht
Alles löst sich auf, und trotzdem sieht das Ergebnis nicht aus wie der Snapshot. Jetzt untersuchen Sie die Visualisierung selbst.
Das halbe Modell fehlt. Der Viewpoint setzt womöglich DefaultVisibility auf false und listet Ausnahmen – also „alles ausblenden, dann diese hier zeigen“. Lassen sich diese Ausnahmen nicht auflösen, bleibt eine fast leere Szene. Prüfen Sie den Visibility-Block und ob die gelisteten GUIDs existieren.
Die falschen Dinge sind sichtbar oder ausgeblendet. ViewSetupHints steuert, ob Räume, Raumbegrenzungen und Öffnungen dargestellt werden – und die Tools halten sich unterschiedlich streng daran. Zerlegte Bauteile sind die zweite typische Ursache: Wer ein übergeordnetes Bauteil ausblendet, blendet nicht in jedem Tool auch dessen Unterbauteile aus.
Der Schnitt sitzt an der falschen Stelle. BCF-Schnittebenen sind in Modellkoordinaten definiert. Wurde das Modell anders platziert – anderer Projektnullpunkt, verschobener Vermessungspunkt, andere Georeferenzierung –, bleibt die Ebene stehen, während das Gebäude darunter wegwandert. Prüfen Sie zuerst die Modellpositionierung, dann Position und Richtung der ClippingPlane in der .bcfv.
Der Bildausschnitt stimmt in einem Tool, im anderen nicht. Hier liegt ein echter Unterschied in der Spezifikation vor. In BCF 2.1 hat die perspektivische Kamera ein FieldOfView ohne AspectRatio, und die Dokumentation beschreibt dieses Sichtfeld als horizontal. In BCF 3.0 führt die Kamera ein AspectRatio, und FieldOfView ist als vertikales Sichtfeld definiert. Die Implementierungshinweise zu BCF 3.0 räumen ein, dass frühere Versionen von verschiedenen Herstellern unterschiedlich gelesen wurden, und geben Regeln für Legacy-Viewpoints vor. Ein alter Viewpoint, dessen Bildausschnitt in zwei Anwendungen unterschiedlich ausfällt, deutet also eher auf die Versionsinterpretation hin als auf eine beschädigte Datei.
Symptomtabelle
| Symptom | Wahrscheinliche Ebene | Was zu prüfen ist |
|---|---|---|
| Die Anwendung weist die Datei ab | 1 | Endung, ob sie sich als ZIP öffnet, bcf.version, und ob das Archiv eine Ebene zu tief gepackt wurde |
| Topics öffnen sich, nirgends 3D | 2–3 | Zugehöriges Modell laden und mit dem BCF verknüpfen, falls das Tool danach fragt |
| Snapshot sichtbar, Viewpoint bewirkt nichts | 1 oder 3 | Existiert die in markup.bcf referenzierte .bcfv? Danach das Modell-Mapping prüfen |
| Kamera stimmt, nichts ist selektiert | 4 | IFC-GUIDs vergleichen; sicherstellen, dass es der Modellstand der Issue-Erstellung ist |
| Der Großteil des Modells verschwindet | 4–5 | DefaultVisibility, Sichtbarkeitsausnahmen, Schnittebenen und ob die GUIDs auflösbar sind |
| Falsche Bauteile sichtbar oder ausgeblendet | 5 | ViewSetupHints, zerlegte Bauteile, Modellstand |
| Der Schnitt sitzt falsch | 5 | Modellpositionierung sowie Position und Richtung der ClippingPlane |
| Bildausschnitt im zweiten Tool anders | 5 | BCF-Version und ob die Datei als 2.1 oder 3.0 geschrieben wurde |
| Viewpoints öffnen sehr langsam | 5 | Umfang der Bauteillisten; buildingSMART nennt rund 1000 Bauteile als Richtwert, ab dem Clients warnen sollten |
| Dieselbe Datei verhält sich in zwei Anwendungen unterschiedlich | beliebig | Versionsunterstützung vergleichen, danach Kamera, Sichtbarkeit, Einfärbung, Clipping und Zuordnung einzeln testen |
Wenn ein BCF sich in zwei Tools unterschiedlich verhält
Das sollten Sie eingrenzen, statt darüber zu spekulieren – „in Solibri geht es, in Revit nicht“ beschreibt ein Dutzend verschiedener Ursachen.
Testen Sie am selben Modell jeweils eine Variable:
- Landet die Kamera an derselben Stelle?
- Sind dieselben Bauteile selektiert?
- Ist dieselbe Menge sichtbar?
- Wird die Einfärbung angewendet?
- Werden die Schnittebenen angewendet?
Der Punkt, an dem es auseinanderläuft, zeigt Ihnen, welchen Teil der Visualisierung das zweite Tool anders umsetzt – und ob die Lösung eine andere Exportversion, ein anderer Viewpoint oder eine akzeptierte Einschränkung ist, die Sie notieren und dann hinter sich lassen.
Langsame BCF-Dateien
Wenn das Öffnen von Viewpoints zäh wird, schauen Sie auf die Zahl der referenzierten Bauteile. Ein Viewpoint, der Selektion, Einfärbung oder Sichtbarkeit für Zehntausende Bauteile speichert, muss all das Bauteil für Bauteil im geladenen Modell auflösen.
buildingSMART rät von sehr großen Bauteillisten ab und nennt rund 1000 Bauteile als Schwelle, ab der Clients warnen sollten. Wer diesen Wert regelmäßig überschreitet, arbeitet meist nach dem Muster „alles ausblenden außer diesem“ – wobei für jedes verbleibende Objekt eine eigene Ausnahme geschrieben wird. Wer vor dem Speichern weniger isoliert, löst beides auf einmal: Dateigröße und Geschwindigkeit.
Wie Sie BCF-Issues erstellen, die auch in sechs Monaten noch funktionieren
Die meisten der beschriebenen Probleme entstehen beim Export, nicht beim Import. Ein paar Gewohnheiten verhindern nahezu alle:
- Den Modellstand in der Beschreibung nennen. Eine Zeile – „erstellt auf ARC_IFC4_rev04“ – macht aus einem nicht reproduzierbaren Viewpoint eine Fünf-Sekunden-Kontrolle.
- Die Version exportieren, die die Gegenseite lesen kann, nicht die neueste, die Ihr Tool anbietet.
- Bauteillisten klein halten. Isolieren Sie das, worum es geht, statt einen Viewpoint zu speichern, der die übrigen 40.000 Objekte einzeln ausblendet.
- Immer einen Snapshot mitgeben. Er ist der einzige Teil, der jede Modelländerung überlebt, und er trägt das Issue, wenn der Viewpoint scheitert.
- Eine Beschreibung schreiben, die für sich steht. Wenn der Topic-Text nur mit aktivem Viewpoint Sinn ergibt, wird das Issue unlesbar, sobald sich das Modell weiterentwickelt.
- BCF und Modell zusammen versenden, wenn die Gegenseite nicht auf der Projektplattform ist – und dazuschreiben, was was ist.
- Neu aufsetzen statt flicken. Hat sich das Modell weiterentwickelt, ist ein neuer Viewpoint auf dem aktuellen Stand mehr wert als die Diskussion darüber, wessen Tool den alten falsch interpretiert hat.
Wenn die Gegenseite gar keine BIM-Software hat, umgehen Sie das Rekonstruktionsproblem vollständig, indem Sie die Issues nach PDF oder nach Excel exportieren – um den Preis des 3D-Kontexts.