Recently i had the pleasure of combining IFC files into a federated model.
For workflow these models needed to be of a .RVT type ie: import IFC
When binding all the files together i encountered conflicts with Directshape elements being duplicates and thus keep new / delete old or cancel import or something like that.
Where i run into problems are;
Not all the directshapes from the IFC imports can be collected as Mesh, Some are Surfaces / Linework only.
My thought was that i would instead turn all the elements in the model into Mass Category direct shapes. The workflow as it stood was put simply, collect Meshe’s from objects, merge them based on an already named parameters into groups and then turn them into direct shapes. Where meshes could not be found, instead get the faces of the elements, and then turn those into meshes to combine with the rest.
Computationally this is a huge lift, once the mesh is collected before it is merged it goes above a few million in number and a single run which on a few of the models just ends in a crash after about 16 hours of run time.
i’m pretty certain i’m going to encounter errors where families are linework only (Such as mesh fences) which will not translate correctly.
As far as i can see the workflow is flawed, but i thought this might be the time to ask options of the gurus on here.
My questions are;
start writing some python with try / except statements to Collect the Mesh / Surfaces / Lines and handle them in different avenues but in one block.
computationally could this workflow be viable if i don’t merge the meshes into groups by the shown below ifcPresentaiton layer with a bit of string manip to avoid duplicate names.
Is there some sort of Hack for Directshape to Directshape where i can rename the new shape and thereby bypassing the duplicate type mess?
Or
Am i handling this just completly in the wrong direction that will never work.
The end goal is to convert an entire IFC import (ie: direct shapes) to Mass objects or at least objects that are goemetrtically identical but will not have overlap conflicts between other imported IFC objects.
This below is the current workflow, i am interested to hear your thoughts.
This workflow (merging IFCs) sucks. IFC wasn’t really intended as an authoring or interoperability format so when we have to cross such bridges we have some headaches… sorry you’re in this mess.
For this task, why not open each IFC directly (creating the file.ifc.rvt), saving each as a new file. Then link those into one file, and bind the links.
Single combined RVT managed (though I am not sure why you want that- subsets of data are lost this way).
If duplicate names are an issue you can take each family in the linked document and prefix the family name with the file name before the family prior to binding.
This is the workflow i used initially and i tried to rename the directshapes that the convertion process had using element.setname but it doesnt actually change the name and i end up i the same issue.
This is purely down to client requirement of a federated revit model
Can you post a sample model? Hard to review options otherwise. You can make an IFC from one of the Revit sample models or delete 90% of the entities in your ifc files of sharing is an issue.
Absolutely Here is the .RVT file. It is worth mentioning that the project is in 2022 because it is a legacy project, it has being ongoing for many years.
I have tested a fair number of the differing components in this workflow (There arn’t too many that are differing in type in the example file), there is agoing to be an approximate of 3.5million meshes created from the import total
Basically, the individual components work so i guess the issue i am facing is the sheer amount of computational stress i am placing on Revit / Dynamo.
This said, i guess my issue might be able to be resolved with some streamlining of the computation in the workflow itself any thoughts?
How many points in total are there? List.Count(mesh.VertexPositions); will do the trick about as efficiently as possible. (Asking as there is an upper limit on the number of points you can have in a mesh).
On Test, it seems as there as nearly as many VertexPositions as there are mesh objects created.
Thereby meaning that as a rough approximate there would be something like 616,000 vertex positions in each of the nearly created mass families / merged mesh entities.
Hmmm… think I was missing an @L2 inside the List.Count function as that count would mean each mesh has no faces just a single point… Doing some quick math, if we assume each object has 8 vertices (minimum for a cuboid) you would have 4,928,000 million vertices. I believe you are capped at 4,294,967,296 so at 8 verticies you’re good. In fact I think you can go to 6972 vertices per object, so you’re likely good unless the LOD is absurd.
I would exceed the 6972 vertices per object, instead of grouping the items i will need to instead name them with a bumber suffix and push them through individually. I’ll touch base when i’ve given it a run.
If you are pushing 7k verticies per mesh (~14k faces if we compare cube geometry) you are likely looking at meshes with too much resolution to be of any real use. A single model may not be an option without reducing the meshes or remodeling to gain some efficiency.
Ok so with the information of the maximum Mesh verticies i have modified the script as follows;
Count the number of verticies collected from each directshape and if >6000 then Exclude it, Log it as an elements ID for later review / punishment.
Do not group the Directshapes into similar masses and instead Suffix the Mark Name with an integer.
Meaning the number of Directshape families made is greater in number but each simpler in complexity.
On a testset it worked, so i’m going to run full monty tonight and see how we go.
This isn’t a perfect solution but i am trying to achieve a broad sweeping brush to take out as many errors as i can from this process as a working solutions and then improve it from there.
As far as i can see i am loosing a heap of efficiency with the spring package workflow ie: Element.MeshGeometry returns a TK Mesh and the Mesh.ByGeometry from MeshToolKit also returns a TK Mesh which i convert to Mesh for use in the Directshape.ByMesh node BUT absolouty thank you so much to @Dimitar_Venkov for even making this possible so quickly for me. I will need to explore more down this road to learn about how i can optimize this.
For anyone else wondering, this is essentally what i am trying to convert from directshapes imported from an IFC to a Directshape
That 6972 was for every direct shape. If the total count of all verticies is less than 4,294,967,296 you’re good to go. A few or even 4000 at 7k but all the rest under 200 you’re good.
Ok So basically after approximatly 14 hours of runtime this locked up my PC
The only tell being that the time got frozen on the taskbar but other than that my PC was a brick.
