Qual MVD escolher ao exportar o IFC?

Exportar IFC sem escolher a vista é mandar tudo e nada.

O IFC não é um PDF — não existe "exportar tudo" que funcione. O schema IFC (ISO 16739-1:2024, IFC4x3) tem centenas de entidades e milhares de propriedades. Nenhum uso consome tudo. A MVD — Model View Definition — é o recorte que diz qual subconjunto do schema serve a um propósito: coordenação, quantitativo, handover, simulação. Quando o projetista exporta sem escolher a MVD, o software faz uma de duas coisas: aplica o default genérico (e omite o que importa) ou tenta mandar tudo (e gera um arquivo pesado, cheio de ruído, que nenhum receptor consegue processar com eficiência).

O resultado é o mesmo: o IFC não serve ao uso pretendido. O coordenador recebe um modelo com entidades que não precisava e sem propriedades que exigia. O auditor roda a verificação e falha porque o subconjunto exportado não carrega os Property Sets necessários. O gestor de obra tenta extrair quantitativo e encontra geometria detalhada demais para o propósito, inflando arquivo e tempo de processamento.

MVD não é detalhe de configuração. É decisão de projeto — define o que sai e o que fica, para cada troca, para cada disciplina.

1. 1

   IFC pesado sem razão aparente · o arquivo tem dezenas ou centenas de MB para um modelo simples — sinal de que o exportador está mandando tudo sem filtro de vista.

2. 2

   Viewer demora para abrir o modelo · o arquivo carrega geometria de detalhe e propriedades que o receptor não pediu, inflando o tempo de leitura e renderização.

3. 3

   Propriedades que faltam no receptor · o IFC não carrega os Property Sets exigidos para o uso (coordenação, orçamento, operação) porque a MVD default não os inclui.

4. 4

   Clash detection com falsos positivos em massa · entidades de detalhe construtivo (parafusos, arremates, subcamadas) que não deveriam estar na troca geram milhares de interferências irrelevantes.

5. 5

   Verificação IDS reprova sistematicamente · as regras esperam entidades e propriedades de uma MVD específica, mas o IFC foi exportado sob outra — os requisitos não batem.

6. 6

   Cada disciplina exporta com MVD diferente · o federador recebe arquivos IFC que não combinam — um usa Coordination View, outro Reference View, outro nem sabe qual.

1. 1

   MVD nunca definida no BEP · o plano de execução BIM não especifica qual MVD cada disciplina deve usar em cada troca, e cada autor escolhe (ou não escolhe) por conta própria.

2. 2

   Confusão entre MVD e versão do IFC · a equipe confunde IFC 2x3, IFC4, IFC4x3 (versões do schema) com Coordination View, Reference View (MVDs) — e trata a escolha como irrelevante.

3. 3

   Exportador no modo default · o software de autoria tem uma MVD padrão de fábrica que ninguém alterou — o projetista clica em exportar e aceita o que vier.

4. 4

   Sem requisitos de troca documentados · o EIR não declara qual informação cada troca deve carregar. Sem requisito, qualquer MVD parece servir.

5. 5

   Desconhecimento do conceito de MVD · a equipe trata a exportação IFC como operação de "Salvar como" — sem entender que MVD filtra o que vai e o que não vai.

6. 6

   Ausência de verificação pós-export · ninguém confere se o IFC gerado atende ao propósito da troca antes de publicar no CDE.

1. 1

   Coordenação sobre modelo inútil · o IFC traz entidades demais ou propriedades de menos — a coordenação trabalha sobre um modelo que não reflete o escopo da troca.

2. 2

   Falsos positivos que enterram interferências reais · detalhes que não deveriam estar na troca geram milhares de clashs irrelevantes, e as interferências que importam se perdem no ruído.

3. 3

   Auditoria que reprova por escopo errado · a verificação IDS espera uma MVD, o IFC entrega outra — a entrega falha não por erro de modelagem, mas por export mal configurado.

4. 4

   Retrabalho de re-exportação em cada ciclo · descobrir na coordenação que a MVD está errada obriga re-export, re-upload e re-verificação — prazo e custo que se repetem a cada entrega.

5. 5

   Arquivo pesado que trava infraestrutura · o IFC sem filtro de vista sobrecarrega CDE, viewer e ferramentas de verificação. O que deveria ter 20 MB chega com 200 MB.

6. 6

   Perda de confiança no processo BIM · a equipe associa IFC a "arquivo pesado que não funciona direito" e passa a trocar modelos nativos ou planilhas — o openBIM vira discurso.

Curto prazo (30 dias):

1. Definir a MVD por troca. Para cada fluxo de troca do projeto, registrar no BEP qual MVD será usada e qual informação (entidades, Property Sets, classificação) o IFC deve carregar.

2. Configurar o exportador de cada disciplina. Ajustar o software de autoria para exportar sob a MVD definida, não no default de fábrica. Testar com um modelo piloto e comparar o resultado com os requisitos.

3. Verificar os IFCs já entregues. Conferir se os arquivos que já estão no CDE foram exportados com MVD compatível. Sinalizar os que precisam de re-exportação.

Médio prazo (60-90 dias):

4. Padronizar preset de exportação. Criar um preset por disciplina que aplica a MVD definida, mapeia categorias e propriedades, e é distribuído como artefato do projeto sob controle de versão.

5. Incluir verificação de MVD na rotina de aceite. Antes de publicar no estado Shared, conferir que o cabeçalho IFC referencia a MVD correta e que os Property Sets exigidos estão presentes.

6. Documentar a lógica de escolha de MVD. Registrar no BEP a justificativa de cada MVD por troca — para que novos membros não exportem no default por desconhecimento.

1. 1

   MVD definida antes da primeira exportação · a escolha da MVD entra no kickoff de cada disciplina, junto com o preset de exportação — não se descobre na véspera da entrega.

2. 2

   BEP com tabela de trocas e MVDs · cada fluxo de troca tem MVD declarada, com lista de entidades e Property Sets esperados. O receptor sabe o que cobrar.

3. 3

   Preset de exportação versionado · o arquivo de configuração do exportador é artefato do projeto, sob controle de versão, e todas as disciplinas usam o mesmo para o mesmo propósito.

4. 4

   Conferência de cabeçalho antes de publicar · o autor confere o FILE_DESCRIPTION do IFC gerado e valida que a MVD referenciada bate com o propósito da troca.

5. 5

   IDS alinhado à MVD · as regras de verificação IDS são escritas para a MVD definida — assim a validação automática reprova o que realmente foge do escopo.

• ISO 16739-1:2024 (IFC4x3)Industry Foundation Classes (IFC). Define o schema completo de dados — a MVD recorta qual subconjunto de entidades, propriedades e relações deve ser usado em cada propósito de troca.
• buildingSMART · MVD (Model View Definition)Conceito que define o subconjunto do schema IFC necessário para um propósito específico. Coordination View e Reference View são as MVDs mais usadas para coordenação entre disciplinas.
• ABNT NBR ISO 19650-2:2022Fase de entrega. §5.6.3 exige verificação da garantia da qualidade antes da troca de informação — inclui conferir que o IFC foi exportado sob a MVD adequada ao propósito.
• buildingSMART IDS (ISO 29481-3)Information Delivery Specification — regras verificáveis sobre o IFC. Permite declarar quais entidades e Property Sets devem estar presentes, alinhando a verificação à MVD definida.
• ABNT NBR ISO 19650-1:2022Conceitos e princípios. Estabelece que o propósito de cada troca de informação deve ser acordado antes da produção — a escolha da MVD é consequência direta desse acordo.