Loading...Loading...
11

Escrevendo um IFC do absoluto zero

By Tiago Ricotta

Last update 5 days ago8 Min.

Com base na grande audiência do texto ‘O futuro é Open’ me animei a evoluir o entendimento do IFC de uma maneira pouca ortodoxa: escrevendo um arquivo do absoluto zero. Eis os resultados até o momento.

Notepad + xBIM (1/7)

Uma forma que gosto muito de fazer para entender um conceito é ir para prática e a imagem acima é resultado desta curiosidade, sim pequeno leitor, tudo o que você vê na imagem foi escrito em um notepad do zero, inclusive a geometria.
Na esteira do curso do Carlos Dias (alô! ainda tem vagas na turma da próxima semana) resolvi partir para um desafio pessoal que estou achando bem interessante e já está ajudando horrores no dia a dia de trabalho: escrever um IFC do absoluto zero em um notepad.
Rapaz.. por quê Notepad? Eu sei que minimamente um Notepad++ já ajudaria horrores, mas assim como na vida, um perrengue ajuda no dia a dia do aprendizado e até o momento tenho atingido o meu objetivo.
Com uma ideia na cabeça de reconstruir a casa dos meus pais no IFC, a forma ajuda porque meu pai era engenheiro e só tem linha reta por lá (malz awe CREA), consigo aplicar todos os conceitos de estruturação e construção que queria fazer.
Como começar? Essa é muito fácil, você precisa disso:
  • Notepad;
  • Obstinação de entender algo do zero;
Com isso em mente a primeira porrada vem logo ao abrir o Notepad, afinal, qual é a primeira linha que preciso escrever? Existe uma ordem? Preciso declarar variáveis e chamar classes como em outras linguagens de programação?
Talvez o segundo melhor professor deste tema, atrás do Carlos claro, seja o xBIM, e por qual razão? Basicamente você pode ir criando o seu arquivo e compilando ele no progama e através do log de erros ir aprendendo com o adubo orgânico que se estava preparando.
O xBIM até o momento tem sido um bom auxiliar pelo simples fato dele já ter todo o schema compilado dentro dele, pode até existir uma coisa ou outra que não funciona direito, mas ainda não me deparei com este tipo de problema.
Por motivos óbvios vou comparando o que estava desenvolvendo no Trimble Connect para saber se uma solução de mercado conseguiria entender o meu pensamento e fiquei bem feliz de saber que tudo correu bem até o momento.
Bom, no Notepad basicamente o que você precisa é de um cabeçalho e declarar o seu projeto, algumas soluções nem colocam o IfcProject de cara, fazem uma série de declarações primeiro para tentar deixar o código mais organizado e isso no desenvolvimento das coisas você vai aprendendo que faz bastante sentido, com toda a certeza já seria uma melhor prática de programação.
Como minha melhor prática era nula comecei pelo IfcProject mesmo, afinal era o que fazia sentido pra mim, logo, a criança nasceu assim:
Yeap... GUID gerado na mão não é legal, mas funcionou. (existem código de geração de GUID automático).
E na sequência?

IfcOwnerHistory (2/7)

Acessando a documentação do IfcProject a segunda informação que precisaria declarar era o IfcOwnerhistory, só nisso, puxando um pelo veio um urso, só nessa brincadeira já da para entender muito bem o conceito de orientação a objeto, vamos ver.
A documentação fala o seguinte do IfcOwnerHistory:
IfcOwnerHistory define todas as informações de histórico e identificação relacionadas. A fim de fornecer acesso rápido, ele é anexado diretamente a todos os objetos, relacionamentos e propriedades independentes.
Fonte: BuildingSMART
IfcOwnerHistory é usado para identificar o aplicativo de criação e proprietário e o usuário para o objeto associado, bem como capturar o último aplicativo de modificação e usuário.
Da para fazer muita coisa porque a quarta informação do IfcOwnerHistory é o IfcChangeActionEnum que tem as seguintes opções: .NOCHANGE. / .MODIFIED. / . ADDED. /  .DELETED. / .NOTDEFINED., desta forma havendo uma gestão legal da modelagem a cada exportação os elementos conseguiriam ter o seu status controlado de maneira bem eficiente, ou seja, saber o que foi alterado / acrescentado / deletado do projeto seria bem tranquilo.
Com esse Inisght em mente, que em algum momento devo utilizar em um exemplo prático, evoluímos o código de uma linha para mais oito linhas, fiz questão de preencher as informações do maluco e da empresa que estão trabalhando neste projeto, ficando assim (dados fictícios):
Ok... mas o que mais?

IfcUnitAssigment (3/7)

Por vias tortas acabei fazendo algo útil, ao escrever na primeira linha o IfcProject ele já me pediu várias informações e uma das mais importantes é a questão da declaração das unidades do projeto e isto é feito pelo IfcUnitAssigment e é a última informação que o IfcProject acaba pedindo.
A documentação fala o seguinte:
IfcUnitAssignment indica um conjunto de unidades que podem ser atribuídas. Dentro de um IfcUnitAssigment, cada definição de unidade deve ser única; ou seja, não deve haver definições de unidade redundantes para o mesmo tipo de unidade, como unidade de comprimento ou unidade de área. Para moedas, deve haver apenas um único IfcMonetaryUnit dentro de um IfcUnitAssignment.
Fonte: BuildingSMART
Sinceramente uma dica para entender melhor isto é ir atrás do próprio exemplo que a BuildingSMART dá para declaração das unidades e verificar os comentários que lá estão, foi copiando o código de declaração de variáveis e entendendo como ele faz conversões que a coisa foi para frente.
No fim, a coisa ficou assim simplificando:
What is next?

IfcRelAggregates (4/7)

Tudo no final do dia é uma questão de relacionamento ou ‘REL’, se você criou um objeto e quer que ele se relacione com o pavimento vai ter um ‘REL’ te esperando no caminho. Isso pode ser HELL também dependendo da complexidade do que você quer fazer.
Dito isto, ao escrever o IfcSite tive que aprender a fazer o meu primeiro relacionamento não romântico do projeto e utilizando o IfcRelAggregates coloquei o Site para conversar com o Projeto, bem como a imagem da BuildingSMART mostra
O que mais gostei da imagem da BuildingSMART foi o conceito de que o terreno é o IfcGeographicElement, classe que nem imaginava que existia até umas semanas atrás uma turma de Design de Interiores questionou sobre como classificar alguns itens de paisagismo, mas disto falamos depois.
Um ponto importante para ir acompanhando o raciocínio é verificar que até o momento estamos construindo algo no éter da Helena Blavatsky, ou traduzindo, no meio do nada e hospedado na luz astral.
E justamente ao me deparar com o IfcObjectPlacement, que vem a ser a sexta informação a ser informada no IfcSite, que percebi isso.
Vamos a ela então.

IfcLocalPlacement (5/7)

Como pequeno padawan escrevendo as coisas eu não me atrevi a desvendar a questão de coordenadas geográficas e conceitos mais profundos de GIS (mesmo que até tenha colocado as infos de latitude e longitude no IfcSite), eu só queria mesmo ter um 0,0,0 para trabalhar e isso me foi entregue pelo IfcLocalPlacement.
Existe uma questão bem profunda sobre este tema que o Carlos explica bem a fundo no curso dele que é a relação de posicionamento dos objetos entre si, não vou entrar nesse detalhe, mas a imagem abaixo detalha um pouco o conceito:
Com toda a certeza, na evolução do projeto e construção das coisas, o problema de entendimento não fica no posicionamento das coordenadas, mas sim em que direção elas precisam ir para construir os objetos em três dimensões e coloca-las em contexto com outros objetos relacionados.
Para rotacionar uma simples porta acho que investi umas duas horas de massa encefálica trabalhando na máxima capacidade para executar a tarefa, é algo que ainda não é tão natural de identificar de cara qual a informação e em qual IfcDirection (aonde as coisas são rotacionadas no eixo X, Y e Z), mas uma hora a gente acerta.
Evoluindo então, e a geometria?

IfcGeometricRepresentationContext (6/7)

Confesso que o momento mais legal do exercício foi o de escrever uma geometria no bloco de notas, só de fazer isso parece que deu um estalo no cérebro e tudo se tornou mais claro.
Novamente, no curso do Carlos ele vai bem a fundo em todos os tipos e possibilidades de construção de geometrias, o que faz você até questionar porque determinadas soluções escolhem um tipo de construção em detrimento de outras (aqui não é uma crítica, é simplesmente uma curiosidade mesmo).
Uma belíssima forma de conseguir entender tudo o que tem na documentação da BuildingSMART em relação a geometria é abrir os arquivos de exemplos de extrusão e ler os comentários do Thomas Liebich explicando pacientemente o que cada linha de código faz.
Obviamente ir pelo caminho do extrusion me pareceu bem mais simples do que outros caminhos e segui a vida com ele para elementos simples como as lajes (fazer a primeira porta escolhi o caminho da polyline).
Se você copiar o código abaixo em um Notepad simples e renomear o arquivo para qualquer coisa com extensão final .ifc deve conseguir um resultado como o da próxima imagem:

Aprendizado (7/7)

Atualmente o projeto que estou escrevendo já tem mais de trezentas linhas de conseguimos criar aberturas nas paredes, selecionar a cor do RGB que vai dentro da forma que esta sendo criada, separar as camadas das paredes, imputar dados de layer e por aí vai.
Este conteúdo vai virar uma série e vamos escrevendo mais sobre os relacionamentos e o imput de informações, foi um exercício muito legal de fazer.
Se gostaram do conteúdo peço um call to action aqui, o primeiro para nos seguir:
O segundo para compartilhar o conteúdo:
Nos vemos na próxima,
Obrigado,
Abs.
Tiago Ricotta