Jump to content


  • Content count

  • Donations

    0.00 CAD 
  • Joined

  • Last visited

Community Reputation

0 Neutral

About syzygy

  • Rank

Personal Information

  • Name
  1. 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?
  2. 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?
  3. 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!