Elefront 5+ Vs. Legacy Reference By Layer Always Firing

Plug Ins Elefront
, , ,
1

Hello Elefront team!

Firstly, Thank you so much for working on Elefront. Truly could not imagine our workflows without it!

Thank you!

I have upgraded to 5+ and so far most everything has been a smooth transition with some very welcomed features and additions! I am having strange behavior with the “Reference By Layer” (RBL) component.

In Legacy Elefront, when I have “Disable auto update reference objects” unchecked, the node performs as I would expect, it remains dormant unless a change is detected in the Rhino doc and then it proceeds to push said change downstream. So if I have 5 points on a layer, RBL returns 5 points, when I then add a point to that layer, it immediately updates to return 6 points and then goes dormant again until a new change is detected.

In 5+ on the updated Reference By Layer node, when I have the same button unchecked, the node continually fires, regardless of whether or not a change was made in the Rhino doc. This means that any logic downstream of this node is constantly firing as well which, even on a very small definition, can lead to severe performance degradation and on larger definitions will freeze GH and Rhino completely as it’s always trying to catch up with the next/last iteration that was fired.

Is this expected behavior and I am using it incorrectly? Is there a setting I can change somewhere to have it perform like the legacy version?

I noticed that the new node wants the full layer path and the legacy node accepted any layer name OR the full path. Not sure if that is relevant to the behavior?

For now, I have all Elefront components upgraded to 5+ but am utilizing the legacy Reference By Layer node until I can figure out a solution.

The reference by layer is a HUGE part of the workflows I use and the ability for the node to detect changes without a manual refresh button is critical.

Thank you again for your awesome plugin and support!

Any help is greatly appreciated,

Cheers!

2

Hi Michael,
Can you share your definition? I did test for this and I am unable to recreate the problem. Is your script making any modifications to the Rhino document, like updating layers or baking? That would create a loop of change-update-change-update…

Regarding the full path vs layer name, it was a deliberate choice for it to work this way. Two layers can have the same name if they are not at the same level of the Layer tree, so allowing the user to put in just the simple name of the Layer could create confusion. Requiring the full path means the user has to be more specific.

Now, that said, you can use * wildcards in the Reference component, so if you put that in front of your layer name, it will get all the sublayers that match the query:

image
image1920×973 91.3 KB

I hope that helps. If you can send me your script, I’ll happily take a look.

3

Thanks for your response Keyan,

Unfortunately the definition is 6000+ components (but it is organized :slight_smile: )

I can isolate a specific function and share that for the issue to be reproduced.

Yes I am both modifying layers and baking.
In legacy I was doing the same thing and all that has changed are the nodes have been updated.

Regarding full paths for layers, totally makes sense and I prefer the full layer name. Upon further testing I don’t think that is what was causing the issue anyways.

I’ll try and get you a definition to take a look at before the weekend.

Thanks for your help!

4

Hi Keyan,

I have prepared a simple script excerpt from my larger script to illustrate the issue I am having.

Please note that this worked perfectly fine in Legacy Elefront and I built out a 7000+ component definition that referenced and baked everything dynamically in real-time without a hitch.

Interestingly, the new Rhino 8 ‘Bake Content’ node seems to perform similarly to the updated Elefront baker and performance severely degrades/freezes when referencing geometry in real time and then also baking said geometry real-time.

Please note also I am referencing from one layer and baking to a different layer so I don’t think it is a layer conflict? Unless they are both trying to pull data from the Layer Table at the same time?

Any advice is greatly appreciated!

I have attached the simple GH definition and you can toggle between Rhino 8 & Elefront baking method to illustrate the difference; again the Rhino 8 bake node is also an issue and while it performs faster in this definition it completely bottlenecks when more complexity in logic is fed in between the reference node and the baker node.

The workflow I used to use and what I expect the result to be is that I can reference geometry from the Rhino doc, perform GH operations based off of those geometry (treating the geometry as a sort of control guide reference), and then bake the resulting GH operations to the Rhino doc.

So as an example this script simply takes the boundaries of “floors” and tags them as such, when you move a sub curve or the overall floor curve, it should update those tag positions in real-time and then be done and not firing anymore logic unless a change is again detected in the reference geometry.

Thank you for your help!

baking_infinite_loop_01a.gh (17.1 KB)
baking_infinite_loop_01a.3dm (199.1 KB)

5

Hi, @krahimzadeh. I’m experiencing this problem too. It doesn’t update immediately

6

Can you provide additional detail & a small example if possible? Thanks