Voltar ao blog de BIM e IFC
Ferramentas e comparativos · 2026-10-02 · 11 min
O que há dentro de um arquivo IFC? O formato explicado com diagramas
Um arquivo .ifc é texto puro que você pode abrir num editor de código — e quando aprende a lê-lo, metade dos mistérios do IFC desaparece. O cabeçalho, as instâncias numeradas, o GlobalId, as relações que carregam as propriedades: aqui está o formato, desenhado.
O que há dentro de um arquivo IFC? O formato explicado com diagramas — IFC Viewer Online article cover
A maioria das pessoas só vê um arquivo IFC através de um visualizador. É uma pena, porque um arquivo .ifc é texto puro, e dez minutos lendo um explicam coisas que, de outra forma, continuam misteriosas: por que os GUIDs importam, por que uma propriedade pode "faltar" mesmo que você a veja, por que os arquivos ficam tão grandes, por que uma configuração errada na exportação quebra tudo adiante.
Este guia abre o arquivo e desenha o que há dentro.
Um arquivo IFC no formato STEP (ISO 10303-21): um cabeçalho que indica o schema e, depois, uma instância numerada por linha.
O essencial
- Um arquivo IFC é uma lista de instâncias numeradas. Os números são locais ao arquivo e mudam a cada exportação.
- O GlobalId — a string de 22 caracteres dentro de cada instância — é a identidade feita para durar.
- Quase tudo o que interessa, incluindo propriedades e contenção espacial, é ligado por entidades de relação em vez de ficar gravado no elemento.
O cabeçalho: qual schema, qual view
O arquivo começa com ISO-10303-21; e uma seção HEADER curta. Três linhas importam:
- FILE_DESCRIPTION indica a model view definition — Coordination View, Reference View, Design Transfer View —, que define o subconjunto do IFC que o exportador pretendia usar.
- FILE_NAME registra o nome do arquivo, a data, o autor e a aplicação de autoria.
- FILE_SCHEMA indica o schema: IFC2X3, IFC4 ou IFC4X3. Cada linha abaixo é lida segundo esse schema; a mesma entidade pode ter atributos diferentes em versões diferentes.
Escolher entre versões do schema é um assunto à parte: IFC2x3 vs IFC4.
Os dados: uma instância por linha
Depois de DATA; toda linha tem a mesma forma: um número, um nome de entidade e uma lista de atributos na ordem definida pelo schema.
#245= IFCWALL('1kTvXnbbzCWw8lcMd1dR4o',#2,'Basic Wall:Ext 300',$,$,#210,#240,$,.STANDARD.);
| Trecho | Significado |
|---|
| #245 | Número da instância (express ID) — local a este arquivo |
| '1kTvXnbbz…' | GlobalId — um GUID compactado de 22 caracteres |
| #2 | Referência a outra instância (aqui, o histórico do proprietário) |
| $ | Atributo não definido |
| .STANDARD. | Um valor de enumeração (o tipo predefinido) |
| #210, #240 | Posicionamento e representação geométrica, definidos em outras linhas |
Quando o próprio GlobalId muda a cada exportação, todos os processos adiante quebram ao mesmo tempo. A causa e a correção por ferramenta de autoria estão em por que os GUIDs do IFC mudam a cada exportação.
As entidades herdam umas das outras
O IFC é um modelo de objetos. Um IfcWall é um IfcBuiltElement, que é um IfcElement, um IfcProduct, um IfcObject e, por fim, um IfcRoot — e carrega os atributos de todos eles. É por isso que toda parede, porta e espaço tem GlobalId e Name: eles vêm do IfcRoot.
Cada entidade herda os atributos dos seus supertipos. Uma verificação escrita para IfcElement vale para toda parede, porta e pilar abaixo dela.
Os nomes mudam entre versões: o que o IFC4.3 chama de IfcBuiltElement era IfcBuildingElement no IFC2x3 e no IFC4. Uma ferramenta que fixa um nome no código perde o outro — um dos motivos pelos quais o mesmo modelo pode passar numa verificação numa ferramenta e reprovar em outra.
Relações também são entidades
A decisão de projeto que torna o IFC difícil de ler no começo é também o que o torna poderoso: relações são objetos por si sós. Uma parede não tem uma lista de propriedades. Em vez disso, uma instância IfcRelDefinesByProperties aponta para a parede e para um property set. Contenção espacial, materiais, tipos, aberturas e grupos funcionam do mesmo jeito.
As propriedades vivem em property sets, ligados ao elemento ou ao seu tipo. Um property set no tipo vale para todas as ocorrências.
Esta é a raiz do falso alarme mais comum nas verificações de qualidade IFC: uma propriedade definida no tipo parece faltar para uma ferramenta que só lê a ocorrência. Propriedades IFC faltando após a exportação cobre as causas reais; ler property sets em Python mostra como seguir essas relações em código.
Por que os arquivos IFC ficam tão grandes
- A geometria domina. Uma fachada triangulada ou uma peça de instalações detalhada pode ocupar milhares de linhas; extrusões e geometria mapeada (instanciada) são bem menores.
- Dados repetidos se repetem. Exportadores que não compartilham property sets ou representações escrevem as mesmas linhas uma vez por elemento.
- Nada é compactado no STEP puro. O ifcZIP costuma reduzir um arquivo várias vezes e é um formato de entrega sensato quando as ferramentas do destinatário o aceitam.
As formas seguras de reduzir arquivos estão em como reduzir o tamanho de um arquivo IFC. E quando um arquivo é grande a ponto de travar o navegador, veja arquivos IFC grandes que travam o navegador.
Lendo um arquivo por conta própria
- Abra num editor de texto Qualquer editor que aguente arquivos grandes. Olhe o cabeçalho primeiro: schema e model view dizem o que esperar.
- Procure a entidade que interessa IFCWALL(, IFCSPACE(, IFCBUILDINGSTOREY(. Só a contagem já é uma checagem rápida.
- Siga as referências de um elemento A partir de uma parede, procure o número # dela para achar as relações que apontam para ela — contenção, propriedades, tipo.
- Depois, passe para um visualizador A mesma informação, navegável: a árvore espacial, o painel de propriedades e uma validação que confere essas relações por você.
Como os elementos se organizam em pavimentos e espaços é o tema de a estrutura espacial do IFC explicada.
O que há dentro de um arquivo IFC? O formato explicado com diagramas