When a new VA objected is inserted, it’s recomputed twice and recomputed again when the insertion is complted.
Recompute is done in every separate Pipeline component not related with the VA objects to be inserted.
I’ve tested with Elefront as well. Recompute is done once when the insertion is completed.
This bug leas to a significant lagging when inserting a new VA objects. Just clicking on the icon on the panel triggers recompute. It takes up to 20 seconds until a VA object panel pops up. Another 10 seconds takes until lagging disappear after the insertion is done because recompute is done when any modiication is done as well. Another weird thing is recompute is done in every separate pipeline. When a column is inserted, Pipeline for sections, slabs, walls, stairs and every other pipeline not related with columns at all is recomputed.
That component multiplies the number of referenced objects in the model since it reference them every time the definition runs. I guess that when you manage a big number of objects in your model, it starts lagging.
Can you test your definition without using the Data Recorder components? (deleting them or turning them off after “destroying the recorded data” with the X button inside the component).
Does it still lag? (in that case, please share the involved files so we can figure out what’s happening).
I’ll let you know when there are improvements on that issue.
Hi. Francesc.
Data Recorder component is not related with this issue, not at all. I just connected it to pipeline temporarily to show unnecessary multiple time recompute from pipeline component triggers the lagging. The number of objects are not related with this bug either. There is lagging for just small amount of VA objects (tens of beams and a few slabs).
Thanks
All right. Then please share the involved files so we can try to reproduce this slow performance in our machines and figure out what’s happening.
Thanks!
I’ve sent them over to you @visualarq.asuni.com
I’ve left only definitions directly related with issue so that you guys can focus on pipeline issue.
Thanks.
Hi @archist97, thanks for the file. We will investigate what’s happening and get back to you.
On the other hand, I’ve seen you are using a document with an Absolute tolerance of 0,001 mm, which may cause issues in your modeling experience. I’m not saying this setting is the cause of the issue reported here, but the smaller this tolerance is, the higher calculations Rhino and VisualARQ will need to do, so this may affect considerably the performance of your model.
We recommend using 1mm or a maximum of 0,1 mm of Absolute tolerance. Smaller values than that will affect the performance, and actually, they are not aimed at architectural scale project designs.
Checking the gh file, I can see there’s a Mesh component that absorbs most of the computing time of that definition. If you disable it, you will notice a better performance when inserting columns or other VisualARQ objects that are being referenced with the Pipeline in that GH file.
Sorry, but I created this GH definition to get correction section drawing through real-time bake. VA offers no feature to join beams and slabs at the moment. The mesh component must be always enabled
The issue here is problem with recompute method of VA pipeline component. It’s definitely weird it runs three times recompute until the modification is finished. I tried elefront component to extract breps from VA block, but there is no lagging because it runs just once recompute after every job is done. VA pipeline component runs recompute even before inserting an object. Just clicking on the icon triggers recompute and this leas to big lagging.
If you check out the attached full version of gh definition, you can realize the problem with VA Pipline quickly. The problem is not with the gh defintion. It’s with VA Pipeline. The Mesh component has nothing to do with the lagging.
Thanks.
When ‘VA Pipeline’ is used (15 seconds lagging total)
When ‘Elefront Reference by Layer’ is used (No Lagging)
Hi @archist97 thanks for sharing the full version of the GH file.
I don’t know if there’s a bug in the VA Pipeline component or not (developers will revise it), but I’ve tested your file and I don’t experience any difference when I select the Extraction method “by Elefront” or “by VA Objects Pipeline”. It actually takes a bit longer with the “by Elefront” method. (See gif below).
What makes the file run very slow (also when I run any VisualARQ object command) is actually a “Solid Union” component, that takes around 15 seconds to compute. This component runs slowly because it needs to compute a big number of boolean unions of Breps, coming from VA objects, regardless if you reference the VA objects through VA Pipeline or Elefront.
No… no. Francesc. Boolen Union is always disabled. It’s enabled manually only when I need it.
I’ve attached the filed having it disabled. Why did you have it enabled?
Because you enabled it, there is no difference between two options.
Again, mesh component, boolean union component has nothing to do with this issue.
Please test the file without changing anything.
I have enabled it because I didn’t experience any lag inserting a column with both “extraction” methods of your GH file. And I haven’t touched anything else (well, I’ve just enabled the VA Pipeline components).
You can see my test in the last gif above.
So I had to explore what is causing a lag in the performance, and the Boolean Union component is what I’ve found so far.
You’re right, there is a bug in the VisualARQ pipeline component. I’ve been able to reproduce the issue, and I have now fixed it for VisualARQ 2.13.
The issue was the the pipeline was listening to layer events, so if a layer name is changed, the pipeline output may change. The problem is that the developer that wrote this component was a little lazy, and just expired the solution on any layer event, without checking if the event affects the pipeline or not. If your example, executing a VisualARQ command like vaColumn, will change the active layer to the “Columns” layer, and this simple change will fire an event, that will reevaluate the solution.
At the end of the command, the previous layer is restored. So, it’s normal that you see the solution evaluated three times (two of them completely innecessary).
