Esta semana, conclui mais uma revisão daquele programa bacana pra caramba, o SOLIDOS (https://tbn2net.com/SOLIDOS)
O desafio desta vez foi otimizar o modelo, aproveitando os recursos de modelagem do IFC.
A princípio, isso parecia fácil, até a implementação começar.
Contextualizando:
No SOLIDOS, os modelos de dispositivos são criados parametricamente, no modelador do plugin, que lembra o Autodesk Subassembly Composer:
Basicamente o dispositivo é modelado ao executar o fluxograma. Assim, ele cria pontos, em função das propriedades criadas para largura, altura, espessura de parede, etc.. Com estes pontos são criadas figuras planas tais como círculos, polígonos etc. e estes são extrudados para criar sólido em 3D. Estes por sua vez podem ser cortados, espelhados, subtraídos, etc.
Olhe para o fluxograma como um "cadista" e fará todo o sentido.
Após rodar o fluxograma, temos o dispositivo em 3D, agora é exportar para o IFC.
Podemos pensar:
Point3d, gera IfcCartezianPoint
Vetor3d, gera IfcDirection
Com uma lista de Point3d, crio uma curva, que gera uma IfcCurve
Desta curva, gero uma Region, que se transforma numa IfcProfileDef
Com uma Region, um vetor e uma altura, crio uma Extrusão, que se traduz numa IfcExtrudeAreaSolid
E para uma Revolução, é possível converter para IfcRevolvedAreaSolid
Ah, só mais um, com um Subtract do extrude de dois círculos podemos ter um tubo. No IFC, criaria duas IfcExtrudeAreaSolid e faríamos uma operação booleana, a IfcBooleanResult.
Deu para perceber que o fluxograma do SOLIDOS vai ser bem útil para modelar o IFC, certo?
E é exatamente este ponto desta atualização.
O ganho em termos de velocidade para exportar é gigantesco. Se considerar a solução "padrão" dos "exportadores de ifc", tal como o comando nativo do Civil 3D (IFCEXPORT) ou mesmo a nova extensão (Autodesk, plugin?? sério mesmo???) para gerar IFC dos elementos do Civil 3D, todos geram uma malha triangulada do sólido, o que cria arquivos enormes e demorados para exportar.
Um exemplo, considere esta rede simples de drenagem:
Se exportarmos o IFC com malhas de triângulo, teremos:
O arquivo IFC estará cheio de coisas assim:
Note o uso da classe IFC IfcClosedShell. Neste exemplo, o arquivo gerado tem 4.2 MB. Cada componente do dispositivo será discretizado por uma malha de pontos, formando faces triangulares. O problema disso é o tamanho do arquivo. Tende a crescer enormemente. E a precisão, pode deixar a desejar. Coisas que seriam curvas, são discretizadas com segmentos retos. Bom, o ponto é outro.
Dispositivos de drenagem, água ou esgoto em geral são prismas retangulares, cones algumas modificações disso, tal como Subtract, Union, Intersection.
Se fizermos as devidas associações das geometrias criadas pelo SOLIDOS com as classes correspondentes do IFC, teremos um arquivo com cerca de 445 KB para este exemplo.
Isso mesmo. Uma redução de quase 10x no tamanho!
E olha que, mesmo exportando como IfcClosedShell, o SOLIDOS "economiza" geometrias semelhantes, tal como se fosse um bloco. Se uma geometria se repete, ele apenas cria um IfcMappedItem, que mapeia uma nova inserção deste IfcClosedShell.
Ah, o Civil 3D com o comando nativo ou a extensão nova não fazem esta economia. Guarde esta informação.
Se observarmos o arquivo IFC otimizado:
Observaremos o uso do IfcExtrudedAreaSolid entre outros.
Mas, e sempre tem um mas.
Ainda estamos reféns do visualizador que utilizaremos.
Considere o modelo do início do post. É uma conexão em "T" direcionada. Olhando como cadista, é fácil perceber que são alguns "extrudes" e "revolves" de círculos.
No AutoCAD (e em qualquer clone dele) é lindo, funciona maravilhosamente. No SOLIDOS, idem, veja:
O arquivo IFC gerado para esta peça não chega a 5KB com as classes corretas. Já a versão com triangulada, algo em torno de 65 KB, em geral 10x maior para os parâmetros de triangulação padrão.
Só que....... dependendo do visualizador, a peça degenera:
Outro exemplo:
Curiosamente, para corrigir este problema, bastou fazer a revolução do tubo curvo não ser exatamente 90º. Em outros dispositivos igualmente simples, os mesmo problemas de "precisão" foram observados. As deformações parecem ser causadas pelo motor gráfico usado pelo visualizador, nos dois exemplos, o motor da OpenCascade.
Pelo que li na internet, esse motor tem bugs deste tipo. Enfim.
A solução é "forçar" a triangulação quando ocorrerem essas degenerações. o SOLIDOS permite esta opção.
Bom, resolvido a questão do visualizador, temos a questão da versão do IFC. O Autodesk NavisWorks é meio xarope neste sentido:
- Navisworks 2023: O formato IFC 4x3 não é suportado, portanto use a versão 4x1
- Navisworks 2024: O formato IFC 4x3 é suportado, mas não "IFC 4x3_ADD2"
- Navisworks 2025: O formato IFC 4x3_ADD2 é suportado
Então observe qual versão usar. Recebi alguns comentários não muito educados por que o "Navis" não abriu ou deformou o dispositivo.
Aí resolvidas estas questões, podemos continuar com a implementação, certo?
É, outros bugs aparecem. no SOLIDOS, dá para mapear as classes no IFC 4.0, 4.1 e 4.3:
- IfcExtrudedAreaSolid - extrusão de perfil
- IfcSphere - esfera simples
- IfcRevolvedAreaSolid - revolução de perfil
- IfcFacetedBrep - sólido modelado por Boundary Representation, com triangulação de faces
- IfcBooleanResult - Operações booleanes: UNION, DIFERENCE E INTERSECTION
- IfcMappedItem - clonagem de itens com transformação espacial
As classes abaixo, poderiam ser mapeadas, mas alguns visualizadores simplesmente não implementam a classe IFC no motor gráfico:
- IfcBlock - prisma retangular (alguns visualizadores não suportam)
- IfcSurfaceCurveSweptAreaSolid algum visualizador suporta?
- IfcSweptDiskSolid - um círculo extrudado ao longo de um eixo, é raro de aparecer nos dispositivos do SOLIDOS
- IfcSectionedSpine - seções distribuídas ao longo de um eixo, não funcionou na maioria dos visualizadores testados
Assim, algumas ferramentas do SOLIDOS precisam ser adaptadas. Exemplos:
- Array 3D, vira Join, que é mapeado para uma lista de IfcBooleanResult
- Varredura, vira uma IfcBooleanResult com vários IfcExtrudedAreaSolid, IfcRevolvedAreaSolid ou IfcFacetedBrep
Não é bonito, mas enfim, funciona, quase sempre. O Array deveria ser convertido em IfcMappedItem (o correspondente ao BlockReference do AutoCAD), as o IfcMappedItem não pode user usado em IfcBooleanResult. O que é patético ao meu ver, mas...
Todos os dispositivos longitudinais do SOLIDOS funcionam como um Corridor do Civil 3D, ou seja, uma seção "varrida" ao longo de um eixo.
Até aí, OK. Mas os eixos do SOLIDOS podem ter: SPLINE, ARC, LINE, POLYLINE, POLYLINE3D, HELIX, ELLIPSE, CIRCLE.
- ARC, CIRCLE, fácil ajustar o IfcRevolvedAreaSolid no segmento
- LINE, ajusta uma IfcExtrudedAreaSolid
- SPLINE, deveria ajustar uma IfcSectionedSpine, mas esta classe os visualizadores testados ignoram ou degeneram
- HELIX, não tem uma classe para isso no IFC, aí poderia usar IfcSectionedSolidHorizontal, mas só tem no 4.3 e não testei se os visualizadores conseguem renderizar. Talvez não, já que falham com IfcSectionedSpine
Aliás, até a SPLINE é complicado no IFC. Diversos testes frustrados me obrigaram a converter em POLYLINE, composta de arcos. Não que o Civil 3D não converta suas espirais em segmentos de arco, então me senti confortável em fazer isso também.
Lembra da extensão do Civil 3D para exportar IFC? A Autodesk deu tanta importância para ele, que é só um plugin (você disse pipoca, digo, plugin?), que nem vem instalado por padrão.
Tem aquele JSON maroto para configurar e no fim, ele ainda gera um IFC por triangulação para o corredor, quando claramente deveria criar a IfcSectionedSolidHorizontal.
Mas não usa.
Aí vem o IFC 5.
E você percebe que manter o IFC 4.0/4.1/4.3 é um desperdício de tempo, na minha opinião.
De qualquer forma, ainda lidaremos com eles por um bom tempo. Teste esta atualização do SOLIDOS em seus projetos, conte para nós os resultados!!!
Saiba mais sobre o SOLIDOS aqui: https://tbn2net.com/help/SOLIDOS/