i’am planing a modelling workflow for visual arq. The output of the process should be an ifc file of a structure with almost 100.000 beams + a bunch of metadata\tags.
I have modeled each bar\beam as a grasshopper style to control a pair of parameters since each bar is potentially different, but still, the representation is schematic, looking for performance optimization.
But plugins performance is being quite slow:
Updating a parameter of 400 bars takes 15 seconds.
More than 5-10 minutes (if not more) to update the value of a parameter for all beams (I’m doing tests with 20.000 bars model)
I expected a response time of various seconds, but almost 10 minutes is too much for me considerate this as valid workflow.
-File size is also huge for the 20.000 bars model 1.1gb. Seems that IFC representation is not very optimized. IFC viewer are struggling opening such a big file.
I would like to know if someone has any suggestion for optimize the response time. I tried to model with meshes the Grasshopper Style for the beam, but seems that meshes are not supported by VisualArq (?).
I would like to know if this is a normal behavior of the plugin (I’m aware that this, maybe, is quite an exotic use of the plugin) or to the contrary if I’m facing a performance related bug.
@aitorleceta 100.000 beams are a big amount of geometry and eventhough they are created using extrusions (not meshes though), the fact to handle this amount of data relies on Rhino and your PC capabilities rather than VisualARQ itself. VisualARQ adds more information to those objects and it slightly increases the file size, but in such a large file I don’t think you would notice any improvment if you had just Rhino extrusions instead. I mean, try to bake 100.000 pipes in Grasshopper to compare the performance results. In any case, if you send us the model to visualarq@asuni.com we will see if there’s anything we can do to improve the performance.
sure, the file is very big. It would be handy for those cases to have the possibility to write IFC files directly from grasshopper (without previewing geomety).
but the fact is that VA takes so long baking 20.000 GH style beams (the last attempt I forced rhino to close, after 10minutes or so). Baking 20.000 pipes from grasshopper takes about one second. I made the experiment with two different machines, but they are both rather capable workstations, plenty of ram, fast ssds and xeon/threadrippers processors.
If the profile of the geometry is the same it should be like block instances right?
Ie. geometry should just be ID (connecting it to the original profile geometry), start point, end point…
@aitorleceta we have just released VisualARQ 2.2 that improves considerabily the speed in baking a large number of beams from Grasshopper. VisualARQ 2 - Version 2.2 released
It will never be as fast as baking extrusions because there is much information to bake within the beams, (style, profile, properties, etc…). But now it runs at least 4 times faster than before.