Jump to content
Sign in to follow this  
syzygy

Reading detail attributes in a point wrangle SOP

Recommended Posts

I have an attribute wrangle SOP running over points, in which I need to read the value of a detail attribute for every point. This seems fairly straightforward using the supplied attribute functions, but I can't get the behavior I need.

Below is a simplified version of my VEX code, with calls to printf for testing. The geometry it's running over has an integer detail attribute called "last_clean."

printf( "last_clean=%d\n", int(detail( 0, "last_clean")));
printf( "ptnum=%d\n", @ptnum );
if( detail( 0, "last_clean" ) == @ptnum ){
    printf( "test\n");
    //do stuff in this loop
}

and here's the output:

last_clean=0
ptnum=1
ptnum=2
ptnum=3
ptnum=4
ptnum=5
ptnum=6
ptnum=7
ptnum=8
ptnum=9
ptnum=10

Note the lack of "ptnum=0" or "test." The only rationale I can imagine for this is that the call to detail() turns the wrangle into a detail one for that iteration, thus making all references to @ptnnum basically meaningless (which still doesn't exactly explain why it only reads the detail attribute once). But I can't find anything in the documentation about this behavior of those functions or wrangles (what else is new...). Can this behavior be changed? Is there a stupid error I'm missing? The wrangle is in an orange for loop block if that's relevant.

Thanks for your help!

 

 

Share this post


Link to post
Share on other sites

Hey syzygy 

It seems that point 0 is skipped. Are you using any groups ordo you have any value in the group parameter of the wrangle node by any change.

Otherwise first test if it runs over all point by removing everything except

printf( "ptnum=%d\n", @ptnum );

This should print out every point number.

 

Share this post


Link to post
Share on other sites

Hi Maurits: yes, it does. Not sure what params I tweaked in the course of debugging to have fixed that, but it does hit @ptnum 0 now. But there's still the issue of only evaluating the call to detail() once per the whole of the loop (at the beginning—and strangely it doesn't enter the if block until after all the points). Here's an updated look at my output:

last_clean=0
ptnum=0
ptnum=1
ptnum=2
ptnum=3
ptnum=4
ptnum=5
ptnum=6
ptnum=7
ptnum=8
ptnum=9
ptnum=10
test

Maybe this comes down to trying to force an unworkable design pattern at this point, but: I need this detail attribute, and I need to check it against @ptnum every time the snippet runs. I can't use a group because I need to know not just if a point is "dirty," but also if it is the first dirty point (hence "last_clean"). I suppose I could check if @ptnum -1 is in the group, but this seems like a workaround for what ought to be an obvious application of detail attributes. Is there something I'm still not getting?

Share this post


Link to post
Share on other sites

that's how VEX evaluates since it's based on SIMD architecture

so each instruction computes in parallel for all elements before it goes to next instruction, hence all the prints before the for loop

the single print of last_clean=0 may be due to the fact that it is the same for all the points cause it doesn't contain any varying variables

 

 

if you don't want to process your points in parallel, you can always loop through them in detail mode sequentially, even though I don't think it's necessary in your case. but really depends on what you are trying to achieve 

 

Share this post


Link to post
Share on other sites

Hey

If I remember correctly the order of text in the console does not always match up with the order of processing.

An easy check I always do it to use removepoint(0, @ptnum);
In your case I would place this inside the If block, so it should only remove the last clean point, then by changing the last_clean to a different value you can check if everything works.

If it works only the point matching the last_clean should disappear.

printf( "last_clean=%d\n", int(detail( 0, "last_clean")));
printf( "ptnum=%d\n", @ptnum );
if( detail( 0, "last_clean" ) == @ptnum ){
    printf( "test\n");
    removepoint(0, @ptnum);
}

Share this post


Link to post
Share on other sites

Thanks to both of you for your help. I decided to go with anim's solution of iterating over points in a run-once (detail) wrangle to avoid having to deal with parallelism all together. Unfortunately, I still can't get any calls to set/detailattrib() to fire more than once. Here's my new loop:

for( int p = 0; p < @numpt ; p++ ){
    int test;
    int last_clean = getattrib( 0, "detail", "last_clean", 0, test);
    printf( "last_clean: %d\n getattrib() succes flag: %d\n", last_clean, test );
    
    if( getattrib( 0, "detail", "last_clean", 0, 0) == p) {
    	//do stuff
    
        printf( "setting last_clean to: %d\n", p+1 );
        int flag = setdetailattrib( 0, "last_clean",  p+1);
        printf( "setdetailattrib() returned: %d\n", flag );
        printf( "last_clean after set: %d\n", int(getattrib( 0, "detail", "last_clean", 0, 0)));
    }
}

and here's my output:

last_clean: 0
getattrib() succes flag: 1
setting last_clean to: 1
setdetailattrib() returned: 0
last_clean after set: 0
last_clean: 0
getattrib() succes flag: 1
last_clean: 0
getattrib() succes flag: 1
last_clean: 0
getattrib() succes flag: 1
[etc, etc]

As you can see, it's as if the value I successfully update last_clean with is instantly forgotten. Or as I now suspect, having looked into the parallel nature of vex a little more: the compiler is "optimizing" each detail call as a single instruction (or something like that—I'm no expert on parallelization). I've tried turning off multithreading and compiling with the --no-optimize flag, but nothing seems to make a difference. Is this just SideFX telling me to use python because what I'm trying to do isn't shader-y enough for vex?

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
Sign in to follow this  

×