Jump to content

Can't get attributes correctly using primattrib

Recommended Posts

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?

Share this post

Link to post
Share on other sites

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 by StepbyStepVFX
  • Like 1

Share this post

Link to post
Share on other sites

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

+1 for a nice explanation.

Share this post

Link to post
Share on other sites

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

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now