Por que o IFC exportado não bate com o modelo nativo?

O modelo tinha a informação; a exportação perdeu no caminho.

O projetista modela no software nativo — Revit, ArchiCAD, Tekla, Allplan — e as propriedades estão lá: material, classificação, resistência ao fogo, carga. Ao exportar para IFC, parte disso desaparece ou chega distorcida: um parâmetro que existia vira campo vazio, uma categoria que tinha nome próprio sai como entidade genérica, uma camada construtiva que estava detalhada perde a decomposição. O IFC recebido não bate com o modelo que o gerou.

A causa quase nunca é o formato. O IFC (ISO 16739-1:2024, IFC4x3) tem entidades e Property Sets para representar tudo que o modelo nativo contém. O que falha é o mapeamento de exportação — a ponte entre o modelo do autor e o schema IFC. Cada software tem um tradutor, e esse tradutor precisa saber para qual entidade cada categoria vai, para qual IfcPropertySet cada parâmetro vai, e sob qual Model View Definition (MVD) a troca opera. Quando o mapeamento não é configurado, o exportador aplica valores padrão genéricos — e o que sai é um IFC empobrecido que não reflete o que foi modelado.

A consequência propaga: se a informação nasce errada na exportação, todo uso posterior — coordenação, quantitativo, auditoria, operação — herda o erro. A raiz de "o IFC perde informação" não é o IFC; é o export não configurado.

1. 1

   Propriedade que existia sumiu · o parâmetro está no modelo nativo, mas o IfcPropertySet correspondente chega vazio ou ausente no IFC exportado.

2. 2

   Categoria virou proxy · o elemento tinha tipo definido no nativo (parede, laje, viga) e saiu como IfcBuildingElementProxy no IFC — sem semântica.

3. 3

   Material genérico ou ausente · a parede tem camadas no nativo (alvenaria + reboco + isolante), mas o IFC chega com IfcMaterial genérico ou sem material nenhum.

4. 4

   Geometria degradada · o sólido paramétrico do nativo vira malha triangulada no IFC — IfcTriangulatedFaceSet em vez de IfcExtrudedAreaSolid.

5. 5

   Classificação que não embarcou · o código de classificação atribuído no nativo não aparece como IfcClassificationReference no IFC.

6. 6

   Quantitativo diverge entre nativo e IFC · a área ou o volume no viewer IFC não bate com o que o software de autoria reporta para o mesmo elemento.

7. 7

   Tipo compartilhado que virou instância solta · o IfcWallType (ou equivalente) não foi exportado, e cada ocorrência carrega propriedades repetidas sem vínculo de tipo.

1. 1

   Mapeamento de exportação no default · o tradutor IFC do software usa a configuração padrão de fábrica, que ignora parâmetros customizados e categorias fora do template.

2. 2

   MVD não escolhida ou errada · a exportação sem MVD (ou com MVD inadequada ao propósito) manda tudo que o default cobre e omite o que importa.

3. 3

   Parâmetros nativos sem mapeamento para Pset · o autor criou parâmetros com nomes livres no nativo, mas não mapeou cada um a um IfcPropertySet ou IfcProperty correspondente.

4. 4

   Categoria do nativo sem correspondência IFC · o software não encontra entidade IFC para a categoria customizada e despeja o elemento em IfcBuildingElementProxy.

5. 5

   Template de exportação não versionado · a equipe não mantém um arquivo de mapeamento (.txt, .json ou preset do exportador) sob controle, e cada export usa configuração diferente.

6. 6

   Sem verificação pós-export · ninguém abre o IFC gerado para conferir se a informação sobreviveu à tradução — a entrega vai direto ao CDE.

1. 1

   Coordenação sobre dado incompleto · a equipe de coordenação filtra por entidade ou propriedade e não encontra o que deveria estar lá. Interferências reais passam despercebidas.

2. 2

   Quantitativo que nasce errado · se geometria degrada ou Pset some, a extração de quantidade do IFC diverge do modelo original — orçamento herda.

3. 3

   Auditoria que reprova por causa do mapeamento · o IDS exige IfcPropertySet ou entidade tipada; o IFC exportado no default não atende, e a entrega é recusada.

4. 4

   Retrabalho de re-exportação · descobrir na coordenação que a informação sumiu obriga re-export, re-upload, re-verificação — ciclo que consome prazo.

5. 5

   Percepção de que o IFC perde informação · a equipe conclui que o formato é limitado e adota workarounds (planilhas paralelas, PDFs). O problema era o mapeamento, mas a confiança no formato já foi.

6. 6

   Handover empobrecido · se o IFC chega sem material, classificação ou propriedades operacionais, o modelo que devia alimentar FM e operação não serve.

Curto prazo (30 dias):

1. Mapear as perdas atuais. Comparar 5-10 elementos representativos entre o nativo e o IFC: propriedades, entidades, geometria, material, classificação. Registrar cada divergência.

2. Configurar o mapeamento de exportação. Ajustar o tradutor IFC do software para que cada categoria e cada parâmetro customizado tenha correspondência explícita no schema IFC.

3. Escolher a MVD adequada. Definir qual Model View Definition atende ao propósito da troca (Coordination View, Reference View etc.) e documentar no BEP.

Médio prazo (60-90 dias):

4. Versionar o preset de exportação. Colocar o arquivo de mapeamento sob controle de versão, com changelog, para que cada disciplina use o mesmo preset ao longo do projeto.

5. Automatizar a verificação pós-export. Implementar IDS ou script de checagem que compara o IFC gerado contra os requisitos do BEP/EIR antes de o arquivo subir ao CDE.

6. Incluir a verificação de fidelidade na rotina de aceite. Toda publicação no estado Shared passa por conferência de propriedades, entidades e geometria, com registro no CDE.

1. 1

   Mapeamento de exportação no kickoff · o preset de exportação IFC de cada disciplina é configurado e testado antes da modelagem avançar, não na véspera da entrega.

2. 2

   MVD definida no BEP · a Model View Definition da troca é declarada no BEP, com justificativa do propósito e do que deve ou não sair no IFC.

3. 3

   Preset versionado e compartilhado · o arquivo de mapeamento é artefato do projeto, sob controle de versão, usado por todas as disciplinas.

4. 4

   Conferência nativo vs IFC · antes de publicar, o autor abre o IFC em viewer neutro e compara campos-chave com o modelo de origem.

5. 5

   IDS de fidelidade no repositório · regras IDS verificam automaticamente a presença de propriedades, entidades e classificação exigidas pelo BEP/EIR.

• ISO 16739-1:2024 (IFC4x3)Industry Foundation Classes (IFC). Define o schema de dados — entidades tipadas (IfcWall, IfcSlab etc.), IfcPropertySet, IfcClassificationReference, representações geométricas (IfcExtrudedAreaSolid vs IfcTriangulatedFaceSet), IfcMaterialLayerSet. A perda de informação na exportação é falha do mapeamento, não do formato.
• ABNT NBR ISO 19650-2:2022Fase de entrega. §5.6.3 exige verificação da garantia da qualidade antes da troca — inclui conferir que o IFC exportado preserva a informação exigida.
• buildingSMART · MVD (Model View Definition)Subconjunto do schema IFC para um propósito de troca. Coordination View e Reference View definem o que deve sair no export para coordenação entre disciplinas.
• buildingSMART IDS (ISO 29481-3)Information Delivery Specification — regras verificáveis sobre o IFC. Permite declarar que propriedades, entidades e classificação devem existir no arquivo exportado.
• ABNT NBR ISO 19650-1:2022Conceitos e princípios. Exige aprovação documentada e acordada antes de qualquer troca de informação, o que inclui a fidelidade do IFC ao modelo de origem.