Can't get attributes correctly using primattrib

[localstarlight]

I'm probably doing something really simple and stupid here, but I can't for the life of me figure it out.

I'm just trying to test out reading/writing attributes in vex, but it seems like I can't read a value out in the same node that I write it, which seems insane. Here is the test code I'm using:

i@test_value = 1;

int check_success = 0;
i@get_value = primattrib(0, "test_value", @primnum, check_success);
i@success = check_success;

After this code runs, here are the values:

@test_value = 1

@get_value = 0;

@success = 0;

So... even though I have literally just written the value into the 'test_value' attribute, I can't read it out. I noticed however that if I move the last three lines of code to another wrangle, then it works. For this tiny example, that would be fine, but for the larger piece of code I'm working with, I need to be able to write a value to an attribute in one part of the code, and then check what that value is in another part.

What's going on here? Is this a bug, or a limitation of VEX?

[StepbyStepVFX]

I confirm I already observed this « behaviour » in former versions of Houdini doing more complex stuff in VEX. This is not a bug.

It reads attribute from « upstream » and write attributes « downstream ». So it is like there are two objects, and that the code does not run « live » on one geometry object.

I am not expert, but my guess is that this is made to handle threading and parallel computation : your code is run through all points/prims at the same time, so they need to refer to one « reference » geometry upstream when reading attributes, because you cannot read the changes of geometry that happens on other threads during execution of the code. So in a way that is logical.

One workaround could be to « duplicate » your geo and its attributes with local variables and/or arrays of local variables (vector pos for P; etc. etc.), run your algo on this duplicated data, and then only transfer everything back on your geo...

Maybe another one can be to avoid threading and parallelism by running your wrangle on detail mode (execution once), and apply your algo through loops on your points/prims. And you can do that on a « local variable duplicate » of your geo (solution above) if you still have this read upstream / write downstream issue , and to avoid the memory overhead of duplicating the geo for each point or prim (if you need all the geo, but usually you need at most only the neighbours or some nearest points)... But you will lose the benefit of thread / parallelism in terms of speed.

Maybe someone from Sidefx could tell us more (like @old school) ?

Edited September 29, 2019 by StepbyStepVFX

[flcc]

Yes, I also notice this kind of behavior.
StepbyStepVFX explanation make sens.

+1 for a nice explanation.

[localstarlight]

Awesome, thanks so much for the explanation! Always helps to understand a little deeper how things are working under the hood. Thanks!