Por que a abertura descola da parede ao trocar de software?

Relação perdida: a porta esquece em que parede mora.

No software de autoria, a porta está na parede. A abertura recorta o vão, a folha preenche o buraco, e tudo se move junto. Mas quando o modelo vira IFC e troca de software, a porta descola: ela continua existindo como geometria, a parede também, mas o vínculo entre as duas sumiu. A abertura não subtrai mais o vão, a porta não sabe mais onde mora, e o modelo que parecia íntegro vira uma coleção de peças soltas.

No IFC (ISO 16739-1:2024, IFC4x3), essa conexão não é implícita — é uma relação explícita, codificada em entidades próprias. A subtração do vão na parede é feita por IfcRelVoidsElement: uma relação 1-para-1 que liga o elemento hospedeiro (tipicamente IfcWall) a uma IfcOpeningElement, declarando que a abertura é uma subtração booleana do sólido da parede. O preenchimento do vão pela porta é feito por IfcRelFillsElement: outra relação 1-para-1 que liga a IfcOpeningElement à IfcDoor (ou IfcWindow), declarando que a porta ocupa aquele vão. A cadeia completa é: IfcWall → IfcRelVoidsElement → IfcOpeningElement → IfcRelFillsElement → IfcDoor. Além dessas, IfcRelAggregates conecta elementos compostos aos seus componentes — uma cortina de vidro aos seus painéis, um lance de escada aos seus degraus.

Essas relações são o que transforma geometria justaposta em modelo semântico. Sem IfcRelVoidsElement, a parede não sabe que tem um buraco; sem IfcRelFillsElement, a porta não sabe que ocupa um vão; sem IfcRelAggregates, a escada não sabe que é feita de degraus. A geometria pode até parecer certa — mas a semântica está quebrada.

Isso é diferente da hierarquia espacial quebrada — quando falta um IfcBuildingStorey, o IfcSite sumiu ou a cadeia IfcProject → IfcSite → IfcBuilding está incompleta. Aqui o problema não é a árvore do edifício; é a relação entre os próprios elementos: composição, subtração e preenchimento. A árvore espacial pode estar perfeita e, ainda assim, cada porta estar desvinculada de sua parede.

A causa mais comum é a troca entre softwares. O exportador do software de autoria nem sempre gera as relações de voiding e filling corretamente — ou gera, mas o importador do software de destino não as interpreta. O resultado é um IFC onde a porta existe, a parede existe, a abertura pode até existir, mas nenhum IfcRelVoidsElement ou IfcRelFillsElement conecta as peças. A verificação da garantia da qualidade confere essas relações antes da troca (§5.6.3 da 19650-2). Relação perdida que passa despercebida degrada quantitativo, clash detection e qualquer operação que dependa de saber o que está dentro do quê.

1. 1

   Porta ou janela descola da parede ao mover · no viewer de destino, selecionar a parede não seleciona a porta junto. Mover a parede deixa a porta para trás — o vínculo de hosting sumiu.

2. 2

   Abertura não subtrai o vão · a parede aparece fechada onde deveria haver um vão. A IfcOpeningElement existe, mas não está ligada à parede por IfcRelVoidsElement — a subtração booleana não acontece.

3. 3

   Porta existe mas não preenche a abertura · a IfcDoor está no modelo, a IfcOpeningElement também, mas falta IfcRelFillsElement para declarar que a porta ocupa aquele vão. São duas peças soltas.

4. 4

   Quantitativo de aberturas por parede dá zero · a consulta conta quantas aberturas cada parede tem via IfcRelVoidsElement e o resultado volta vazio — as relações de voiding não foram exportadas.

5. 5

   Clash detection acusa interferência porta-parede · a porta e a parede ocupam o mesmo espaço geométrico sem que a relação de voiding declare a subtração. O clash é falso — mas o rule engine não sabe.

6. 6

   Elemento composto perde seus componentes · cortina de vidro sem painéis, escada sem degraus, laje sem camadas: o IfcRelAggregates que ligava o todo às partes sumiu na exportação.

1. 1

   Exportador não gera IfcRelVoidsElement · o software de autoria exporta parede e abertura como geometrias separadas, mas não cria a relação de voiding entre elas. Cada peça vai sozinha.

2. 2

   Importador descarta relações na leitura · o software de destino lê a geometria mas ignora IfcRelVoidsElement e IfcRelFillsElement. As relações existem no arquivo; são perdidas na importação.

3. 3

   Preset de exportação no modo simplificado · o exportador tem modos de fidelidade. O modo simplificado funde geometrias e omite relações semânticas para reduzir tamanho — voiding e filling são as primeiras vítimas.

4. 4

   Copiar-e-colar entre modelos quebra o vínculo · elementos copiados de outro arquivo perdem as relações com o hospedeiro original. A porta chega ao destino sem saber em que parede morava.

5. 5

   IfcOpeningElement ausente · sem a abertura intermediária, não há como criar IfcRelVoidsElement nem IfcRelFillsElement. A porta existe, a parede existe, mas o elo que as conecta não foi gerado.

6. 6

   Sem verificação de relações antes da troca · ninguém confere se IfcRelVoidsElement, IfcRelFillsElement e IfcRelAggregates estão presentes e corretos antes de o IFC subir ao CDE (§5.6.3 da 19650-2).

1. 1

   Geometria visualmente correta, semanticamente quebrada · o modelo parece certo na tela, mas qualquer operação que dependa de relações — quantitativo de aberturas por parede, scheduling de portas, análise térmica — falha silenciosamente.

2. 2

   Quantitativos de esquadrias inconsistentes · a contagem de portas por parede, por pavimento ou por tipo retorna resultado errado quando IfcRelFillsElement e IfcRelVoidsElement estão ausentes.

3. 3

   Clash detection com falsos positivos · porta e parede ocupam o mesmo espaço sem relação de voiding. O rule engine reporta interferência onde deveria haver subtração — poluindo o relatório com ruído.

4. 4

   Análise térmica e acústica comprometida · simuladores leem IfcRelVoidsElement para saber onde há aberturas na envoltória. Sem a relação, a parede é tratada como sólida e o cálculo erra.

5. 5

   FM que não sabe onde está a porta · o sistema de gestão de ativos importa a relação porta-parede-ambiente para montar o inventário. Sem IfcRelFillsElement, a porta não se associa ao ambiente correto.

6. 6

   Retrabalho de re-exportação em todas as disciplinas · descobrir relações perdidas tarde obriga re-export, re-verificação e re-upload de cada modelo afetado.

Curto prazo (30 dias):

1. Auditar as relações de voiding e filling do modelo. Listar todas as IfcWall com vãos, verificar se cada uma possui IfcRelVoidsElement, e se cada IfcOpeningElement possui IfcRelFillsElement apontando para a porta ou janela correta.

2. Verificar IfcRelAggregates para elementos compostos. Identificar cortinas de vidro, escadas e outros elementos compostos e confirmar que a agregação com seus componentes está declarada.

3. Corrigir o preset de exportação. Ajustar o exportador do software de autoria para gerar relações de voiding, filling e agregação com fidelidade total — desabilitar modos simplificados que omitem relações semânticas.

Médio prazo (60-90 dias):

4. Testar o roundtrip entre softwares. Exportar IFC, importar no software de destino e conferir se as relações chegam intactas. Documentar quais pares de software perdem vínculos e em quais condições.

5. Incluir relações no EIR e no IDS. Declarar formalmente que a entrega IFC deve conter IfcRelVoidsElement para cada abertura, IfcRelFillsElement para cada esquadria e IfcRelAggregates para elementos compostos. Criar regras IDS correspondentes.

6. Registrar verificação de relações no CDE. A transição de WIP para Shared exige que a auditoria de relações entre elementos esteja aprovada, com relatório arquivado.

1. 1

   Export com fidelidade semântica total · o preset de exportação é configurado para gerar todas as relações (voiding, filling, agregação), sem modo simplificado que as omita.

2. 2

   Roundtrip testado no kickoff · antes da produção, o time exporta um modelo-piloto, importa no software de destino e confirma que as relações sobrevivem à troca.

3. 3

   Sem copiar-e-colar entre arquivos sem reconexão · elementos copiados de outro modelo têm suas relações de hosting e agregação refeitas no destino antes de exportar.

4. 4

   Verificação de relações antes de compartilhar · a auditoria de IfcRelVoidsElement, IfcRelFillsElement e IfcRelAggregates é feita antes da troca (§5.6.3 da 19650-2), com registro no CDE.

5. 5

   EIR declara as relações exigidas · o documento de requisitos indica explicitamente quais relações entre elementos devem estar presentes no IFC entregue, e o IDS automatiza a verificação.

• ISO 16739-1:2024 (IFC4x3)Industry Foundation Classes (IFC). Define IfcRelVoidsElement como relacao 1-para-1 entre elemento hospedeiro e IfcOpeningElement (subtracao booleana), IfcRelFillsElement como relacao 1-para-1 entre abertura e elemento de preenchimento (porta ou janela), e IfcRelAggregates como relacao de composicao entre elemento-pai e componentes. Essas relacoes transformam geometria justaposta em modelo semantico interoperavel.
• ABNT NBR ISO 19650-2:2022Fase de entrega. A verificacao da garantia da qualidade (§5.6.3) confere a informacao antes da troca -- inclui verificar que as relacoes entre elementos (voiding, filling, agregacao) estao presentes e corretas.
• ABNT NBR ISO 19650-1:2022Conceitos e principios. Exige que a informacao trocada seja confiavel e verificavel -- modelo com relacoes perdidas entre elementos compromete a confiabilidade de quantitativos, clash detection e analise.
• buildingSMART IDS (ISO 29481-3)Information Delivery Specification. Permite definir regras que verificam a presenca de relacoes entre elementos, reprovando automaticamente modelos onde IfcRelVoidsElement, IfcRelFillsElement ou IfcRelAggregates estao ausentes.