Voltar ao blog de BIM e IFC
Entrega e ISO 19650 · 2026-10-01 · 10 min
BCF 2.1 vs 3.0: por que seus viewpoints de issues abrem no lugar errado
O BCF deveria fazer uma issue sobreviver à viagem entre ferramentas. Na prática, a câmera cai debaixo da terra, a caixa de corte some e as etiquetas se perdem. As causas são poucas, específicas e corrigíveis — e conhecê-las diz em quais ferramentas confiar.
BCF 2.1 vs 3.0: por que seus viewpoints de issues abrem no lugar errado — IFC Viewer Online article cover
O BCF — BIM Collaboration Format — tem um único trabalho: deixar uma issue sair de uma ferramenta e chegar a outra com o contexto intacto. Um comentário, uma posição de câmera, um conjunto de elementos selecionados, talvez uma caixa de corte. Abra a issue em qualquer lugar e você vê exatamente o que o autor via.
Quem já trocou BCF entre três fornecedores sabe com que frequência isso falha. A câmera abre debaixo da terra, ou apontando para o céu. A caixa de corte sumiu. As etiquetas se foram. Os comentários são cortados no primeiro "e comercial". Nada disso é mistério, e tudo vem de um punhado de erros de implementação específicos.
O que realmente há dentro de um .bcfzip
Um arquivo BCF é um zip. Dentro dele, uma pasta por tópico, cada uma com um markup.bcf (o tópico, seus comentários e sua lista de viewpoints), um ou mais arquivos de viewpoint .bcfv (câmera, seleção, visibilidade, planos de corte) e snapshots PNG opcionais. Tudo é XML simples. Dá para descompactar e ler, e quando uma ferramenta se comporta mal, você deveria fazer isso.
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: as diferenças que quebram importações
A mesma issue em BCF 2.1 e 3.0. Comentários, viewpoints e etiquetas passam para dentro do Topic e para contêineres.
| Aspecto | BCF 2.1 | BCF 3.0 |
|---|
| Comentários no markup.bcf | Irmãos de <Topic> | Aninhados em <Topic><Comments> |
| Lista de viewpoints | Irmãos de <Topic> | Aninhados em <Topic><Viewpoints> |
| Etiquetas | Elementos <Labels> repetidos, um por etiqueta | Um contêiner <Labels> com filhos <Label> |
| Câmera em perspectiva | Posição, direção, vetor up, campo de visão | O mesmo, mais um AspectRatio obrigatório |
| Valores permitidos | Implícitos, combinados fora do arquivo | Declarados nas extensões do projeto |
| Suporte na prática | Quase universal | Crescente, desigual |
O modelo de dados quase não mudou; o layout XML, sim. Um parser escrito para um layout lê o outro como um tópico sem comentários.Leia essa tabela como uma lista de modos de falha. Uma ferramenta que procura comentários ao lado do Topic não encontra nenhum num arquivo 3.0. Uma ferramenta que espera um contêiner Labels lê um arquivo 2.1 como se tivesse uma etiqueta, ou nenhuma. Uma câmera 3.0 sem AspectRatio é inválida pelo schema, e alguns importadores rejeitam o viewpoint inteiro.
Por que a câmera cai no lugar errado
O IFC tem Z para cima; o three.js, Y. Sem a conversão a câmera chega girada 90°; sem o deslocamento, chega no lugar errado.
As câmeras BCF são gravadas nas coordenadas de mundo do projeto IFC: metros, com Z para cima. A maioria dos visualizadores web renderiza com three.js, cuja cena tem Y para cima, e muitos deslocam o modelo para perto da origem para que coordenadas georreferenciadas grandes não tremam na GPU. As duas são escolhas de renderização sensatas. As duas precisam ser desfeitas antes de gravar um viewpoint.
- Esqueça a conversão de eixos e a câmera chega girada 90° — olhando para o céu ou atravessando o piso.
- Esqueça o deslocamento de exibição e a câmera chega na orientação certa, a centenas de metros ou quilômetros do modelo.
- Converta a câmera mas não os planos de corte, e a vista fica certa enquanto a caixa de corte corta em outro lugar completamente diferente.
O problema do deslocamento piora quanto melhor for sua georreferência, porque coordenadas reais são números grandes. O contexto está em coordenadas e georreferenciamento IFC.
Um teste de dez minutos para qualquer ferramenta BCF
- Crie uma issue com tudo dentro Uma câmera em perspectiva num ângulo oblíquo, dois elementos selecionados, uma caixa de corte, três etiquetas e um comentário com um "e comercial", aspas e um caractere acentuado.
- Exporte como 2.1 e como 3.0 Se a ferramenta só grava uma versão, anote — cedo ou tarde você vai encontrar um destinatário que precisa da outra.
- Importe numa segunda ferramenta Confira a orientação da câmera, a distância ao modelo, a seleção, a caixa de corte, o número de etiquetas e o texto do comentário caractere a caractere.
- Faça a ida e volta Exporte de novo pela segunda ferramenta e importe de volta na primeira. O que sobrevive a um salto mas não a dois vai acabar custando uma reunião.
Nosso próprio exportador BCF foi reescrito depois exatamente deste teste: os viewpoints agora são gravados nos eixos de mundo do IFC sem o deslocamento de exibição, os planos de corte viajam com o viewpoint, as etiquetas 2.1 são gravadas como elementos repetidos e os comentários importados são lidos inteiros, com as entidades XML decodificadas. Ele grava 2.1 e 3.0 para você se adaptar ao destinatário.
Convenções para que os BCFs sejam resolvidos
- Um tópico por causa, não por elemento. Quatrocentas paredes sem um property set são um tópico com um viewpoint representativo.
- Coloque a regra ou o requisito no título. "Pset_WallCommon.FireRating ausente — adicionar ao template de exportação" é acionável; "dados faltando" não é.
- Etiquete por revisão. Um tópico aberto na revisão 6 deve dizer isso, para que uma comparação posterior não o abra duas vezes.
- Inclua sempre o snapshot. É o que o destinatário vê na caixa de entrada antes de abrir qualquer ferramenta, e muitas vezes é a única parte que ele olha.
Onde o BCF se encaixa no pacote de entrega completo — ao lado do relatório de validação e da carta de transmissão — está em o que entregar junto com um modelo IFC. Abrir tópicos automaticamente a partir de uma comparação de revisões está em como comparar duas versões IFC.
BCF 2.1 vs 3.0: por que seus viewpoints de issues abrem no lugar errado