Este post não pretende ser uma solução. São algumas considerações sobre o tema que expus em um grupo de Whatsapp. Estou transcrevendo aqui, para que o tema não se perca.
Dito isto, vamos ao que interessa:
Certas empresas estão pedindo informações extras nos solidos dos corredores.
Exemplo: área do pavimento, espessura da camada, largura
Sabidamente, o comando de exportar sólidos do c3d, não fornece essas informações.
No entanto, ele fornece 3 categorias de informações no PSET destes sólidos:
Com essas propriedades, é possível recuperar a informação original do corredor do Civil 3D:
Vocês já viram isso?
Tentaram usar essas informações ? Seja pelo Dynamo, seja por PSETs com script…
Tem ali o HANDLE do corredor, o GUID da baseline, da região , do assembly… Com DOTNET é possível usar essa informação, mas com o script , não. Ele usa a API ActiveX que não tem funções para recuperar sequer o nome da baseline… é bem frustrante…. O Dynamo me parece que consegue, a API dele gira em torno do DOTNET.
Imaginei o seguinte para obter a área de pavimento de uma região:
- com o HANDLE do corredor, obtenho ele
- com o GUID da Baseline e da BaselineRegion, obtenho a BaselineRegion
- desta, obtenho o Appliedassembly de cada estaca modelada , que é a seção gabaritada
- desta, obtenho o AppliedSubassembly que gerou o shape, que gerou o sólido do pavimento
- esta shape, é formada por uma lista de links, que por sua vez, tem códigos
- um desses códigos é o “Pave”, por exemplo
- esse “Pave” é modelado em todas as estacas daquela região
- fazendo uma função que acumula a area entre dois links consecutivos do codigo “Pave”, obtenho a área
- “inputo” essa área no PSET que o contratante determinou para a área do pavimento
Parece factível.
Alguns desafios:
Desafio 1
Estabelecer a lista de AppliedSubassembly por estaca, código da shape que gerou o sólido, código do link na shape
Desafio 2
Uma interface onde o usuário informa esses códigos
Desafio 3
Esse contratante quer a largura do pavimento. Essa BaselineRegion está numa transição de superlargura. O que vc colocaria? Máximo, mínimo, valor médio?
Desafio 4
A empresa B, tem exigências semelhantes, porem os PSETs dela tem nomes diferentes.
A interface tem de ser capaz de lidar com isso.
Desafio 5
O projetista pode ou não usar um country kit, então “Pave” pode ser “Pavimento” , ou “Pave1”
Desafio 6
Eles tem uma tabela de PSET, com uma categoria , digamos “Geometria” que cabe para o pavimento. na disciplina de drenagem, também tem uma categoria “Geometria” como você separaria as disciplinas a fim de não ter uma propriedade “Diametro” na categoria “Geometria” do pavimento?
O PSET no IFC permite que existam categorias de mesmo nome, com propriedades diferentes. quem não permite isso é o PSET do c3d. o que alias, é um tanto confuso.
No PSET do Civil, a categoria pode ter Name, GlobalName, AlternateName.
Se o sólido não está no mesmo arquivo, e eu espero que não esteja mesmo, basta apontar o caminho do arquivo no código, ler sua base de dados na memoria e recuperar as informações usando o HANDLE, da mesma forma que faria se o sólido estivesse no mesmo DB do corredor original.
Acredito que o mais “complexo” mesmo, é criar uma interface que possa gerenciar essas questões e que seja “userfriendly” pro afegão médio.
De resto, certas propriedades que o contratante pedir, podem ter fluxos um pouco diferentes exemplo: espessura do pavimento: Handle corredor, Guid Baseline/Baselineregion, AppliedSubassembly, Shape, Link, nome da propriedade que armazena a tal espessura