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?

Link to comment
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
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...