What is the difference between BCF 2.1 and BCF 3.0?

The content is largely the same — topics, comments, viewpoints with camera, selection, visibility and clipping planes. The structure differs: in 2.1 comments and viewpoint references are siblings of the Topic element in markup.bcf; in 3.0 they are nested inside the Topic, labels and other lists are wrapped in container elements, the perspective camera requires an AspectRatio, and project extensions describe the allowed values. Tools that parse one layout will often silently drop data from the other.

Why does a BCF viewpoint open in the wrong place?

Usually because the exporting tool wrote the camera in its own scene axes instead of IFC world coordinates. Web viewers built on three.js use a Y-up scene while IFC is Z-up; a camera exported without converting back arrives rotated by 90 degrees. The other common cause is a model offset applied for display that was not removed before export.

Which BCF version should I use?

Use the one every tool on the project reads correctly — test it, do not assume. BCF 2.1 remains the most widely supported; 3.0 is better specified. A tool that can write both lets you choose per recipient.

Back to the BIM & IFC blog

Delivery & ISO 19650 · 2026-10-01 · 10 min

BCF 2.1 vs 3.0: Why Your Issue Viewpoints Open in the Wrong Place

BCF is supposed to make an issue survive the trip between tools. In practice the camera lands underground, the section box vanishes and the labels are gone. The reasons are few, specific, and fixable — and knowing them tells you which tools to trust.

BCF 2.1 vs 3.0: Why Your Issue Viewpoints Open in the Wrong Place — IFC Viewer Online article cover

BCF — the BIM Collaboration Format — has one job: to let an issue leave one tool and arrive in another with its context intact. A comment, a camera position, a set of selected elements, maybe a section box. Open the issue anywhere and you are looking at exactly what its author was looking at.

Anyone who has exchanged BCF between three vendors knows how often that fails. The camera opens underground, or pointing at the sky. The section box is missing. The labels are gone. The comments are truncated at the first ampersand. None of these are mysteries, and all of them come from a handful of specific implementation mistakes.

What is actually in a .bcfzip

A BCF file is a zip. Inside it, one folder per topic, each holding a markup.bcf (the topic, its comments and its viewpoint list), one or more .bcfv viewpoint files (camera, selection, visibility, clipping planes) and optional PNG snapshots. Everything is plain XML. You can unzip one and read it, and when a tool misbehaves, you should.

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

2.1 versus 3.0: the differences that break imports

Side-by-side XML of markup.bcf in BCF 2.1 and BCF 3.0 showing where Comments, Viewpoints and Labels are nested — The same issue in BCF 2.1 and 3.0. Comments, viewpoints and labels move inside the Topic and into containers.

Aspect	BCF 2.1	BCF 3.0
Comments in markup.bcf	Siblings of <Topic>	Nested inside <Topic><Comments>
Viewpoint list	Siblings of <Topic>	Nested inside <Topic><Viewpoints>
Labels	Repeated <Labels> elements, one per label	One <Labels> container with <Label> children
Perspective camera	Position, direction, up vector, field of view	Same, plus a required AspectRatio
Allowed values	Implicit, agreed out of band	Declared in project extensions
Support in the wild	Near universal	Growing, uneven

The data model barely changed; the XML layout did. A parser written against one layout reads the other as a topic with no comments.

Read that table as a list of failure modes. A tool that looks for comments next to the Topic finds none in a 3.0 file. A tool that expects a Labels container reads a 2.1 file as having one label, or none. A 3.0 camera missing its AspectRatio is invalid against the schema and some importers reject the whole viewpoint.

Why the camera lands in the wrong place

Axes diagram: IFC world coordinates are Z-up and right-handed, a three.js scene is Y-up; BCF cameras must be converted back before export — IFC is Z-up; three.js is Y-up. Skip the conversion and the camera arrives rotated 90°; skip the offset and it arrives in the wrong place.

BCF cameras are stored in the IFC project's world coordinates: metres, Z pointing up. Most web viewers render with three.js, whose scene is Y-up, and many shift the model towards the origin so that large georeferenced coordinates do not wobble on the GPU. Both are sensible rendering choices. Both must be undone before a viewpoint is written.

Forget the axis conversion and the camera arrives rotated 90° — looking at the sky or straight down through the floor.
Forget the display offset and the camera arrives in the right orientation, hundreds of metres or kilometres away from the model.
Convert the camera but not the clipping planes and the view is right while the section box cuts somewhere else entirely.

The offset problem gets worse the better your georeferencing is, because real-world coordinates are large numbers. The background is in IFC coordinates and georeferencing.

A ten-minute test for any BCF tool

Create one issue with everything in it A perspective camera at an oblique angle, two selected elements, a section box, three labels, and a comment containing an ampersand, quotes and an accented character.
Export as 2.1 and as 3.0 If the tool only writes one version, note it — you will eventually meet a recipient who needs the other.
Import into a second tool Check the camera orientation, the distance to the model, the selection, the section box, the label count and the comment text character by character.
Round-trip it Export again from the second tool and import back into the first. Anything that survives one hop but not two will eventually cost you a meeting.

Our own BCF exporter was rewritten after exactly this test: viewpoints are now written in IFC world axes with the display offset removed, section planes travel with the viewpoint, 2.1 labels are written as repeated elements, and imported comments are read whole with XML entities decoded. It writes both 2.1 and 3.0 so you can match the recipient.

Conventions that make BCF files get acted on

One topic per cause, not per element. Four hundred walls missing a property set is one topic with a representative viewpoint.
Put the rule or requirement in the title. "Pset_WallCommon.FireRating missing — add to export template" is actionable; "missing data" is not.
Label by revision. A topic raised on revision 6 should say so, so a later comparison does not raise it twice.
Always include the snapshot. It is what the recipient sees in their inbox before they open any tool, and it is often the only part they look at.

Where BCF fits in the full delivery package — next to the validation report and the transmittal — is covered in what to hand over with an IFC model. Raising topics automatically from a revision comparison is in how to compare two IFC versions.

BCF 2.1 vs 3.0: Why Your Issue Viewpoints Open in the Wrong Place