pcopen and pciterate in sop wrangle nodes

[mrWolf]

I am struggling a bit trying to get this simple thing working (I am on H13):

 

I want to examine the 3 closest points surrounding each point in a point cloud, and simply print some debug message.

 

This is the code I use in an Attrib Wrangle sop node:

int handle=pcopen(@OpInput2,"P",@P,10,3);

printf("ptnum %d\n",@ptnum);
int iteration=0;
while (pciterate(handle))
{
    iteration++;
    printf("iteration %d\n",iteration);
}
pcclose(handle);

I have 10 points scattered and I use them as input 1 and 2 for the Attrib Wrangle node.

So I am trying to loop through the points in the input 1, and for each one of them open a pc based on the input 2.

 

I expect a feed back like this :

ptnum 0
iteration 1
iteration 2
iteration 3
ptnum 1
iteration 1
iteration 2
iteration 3
...
ptnum 9
iteration 1
iteration 2
iteration 3

But I receive this feedback instead:

ptnum 0
ptnum 1
ptnum 2
ptnum 3
ptnum 4
ptnum 5
ptnum 6
ptnum 7
ptnum 8
ptnum 9
iteration 1
iteration 2
iteration 3

I must clearly be doing something conceptually wrong.

I thought that the content of a Attrib Wrangle node set to "point" was looping through all the points in the first input. So the code should be executed on all the points , is that correct ?

 

(scene file included)

pciterate_test.hipnc

Edited January 22, 2014 by mrWolf

[mrWolf]

more confusion:

 

if I simply change the printf statement inside the loop to

printf("pt %d - iter %d\n",@ptnum,iteration);

Then the feedback is as follows:

ptnum 0
ptnum 1
ptnum 2
ptnum 3
ptnum 4
ptnum 5
ptnum 6
ptnum 7
ptnum 8
ptnum 9
pt 0 - iter 1
pt 1 - iter 1
pt 2 - iter 1
pt 3 - iter 1
pt 4 - iter 1
pt 5 - iter 1
pt 6 - iter 1
pt 7 - iter 1
pt 8 - iter 1
pt 9 - iter 1
pt 0 - iter 2
pt 1 - iter 2
pt 2 - iter 2
pt 3 - iter 2
pt 4 - iter 2
pt 5 - iter 2
pt 6 - iter 2
pt 7 - iter 2
pt 8 - iter 2
pt 9 - iter 2
pt 0 - iter 3
pt 1 - iter 3
pt 2 - iter 3
pt 3 - iter 3
pt 4 - iter 3
pt 5 - iter 3
pt 6 - iter 3
pt 7 - iter 3
pt 8 - iter 3
pt 9 - iter 3

I really need some clarification here, helpp

 

[anim]

it just looks like that if the print result is the same for all points it prints it just once, otherwise per each point

but even if it print's it once it will compute the values per each point so don't worry, your code is correct

 

PS:if you need the iteration number you can directly use for loop instead of while loop as you would get that for free

[mrWolf]

yes it's weird, I just realized the code works as you say.

The fact the print vex command doesn't work properly is a bit of a bummer cause it's really useful to have that kind of debug feedback but I guess SIMD architecture is not precisely printf friendly.

 

it just looks like that if the print result is the same for all points it prints it just once, otherwise per each point

but even if it print's it once it will compute the values per each point so don't worry, your code is correct

 

PS:if you need the iteration number you can directly use for loop instead of while loop as you would get that for free

[mrWolf]

I did some additional test. I was curious to see the difference in performance between

 

Point Wrangle

Attrib Wrangle

VOP SOP

 

So I scattered 2 million points and for each point I calculated the number of neightbors (max 100) in a radius of .2 units (scene included).

 

 

It seems there is a significant difference in speed : VOP SOP is still way faster.

Kinda disappointing cause I really was looking forward dropping VOPs in favour of VEX code.

 

EDIT

I was totally wrong:

i was calculating the vop sop on 20 points instead of 100. That's why it was faster ! eheh

apologies.

Edited January 22, 2014 by mrWolf

[anim]

whether it is Point Wrangle, Attrib Wrangle, VOP SOP or AttribVOP SOP, they all result in compiled VEX code so it shouldn't really matter which one you use performance wise

 

of course there may be little differences between (Point Wrangle/VOP SOP) vs (Attrib Wrangle/AttribVOP SOP) as the later 2 are CVEX based, but that may be as well irrelevant

 

the difference in your scene is simply based on the fact that for Point and Attrib Wrangle you use 100 point lookup and for VOP SOP only 20

 

and remember that Point Wrangle is in essence just an nicely wrapped VOP SOP so it wouldn't make sense for VOP SOP to be faster than VOP SOP especially if you know that even VOP network is at the end just a VEX code

 

so now you can happily use Wrangle nodes

 

EDIT: and that print thing I wouldn't be seeing as a bad thing as it's pretty clever optimization, simply if you want to force different output per point, include ptnum as a part of the print output, because otherwise you wouldn't know which point produced that output anyway, you will just end up with millions of prints of the same value or something, not useful at all in my opinion

Edited January 22, 2014 by anim

[mrWolf]

Yes you're right, It all makes sense, even the printf matter actually.

Very much appreciated Thomas.

 

whether it is Point Wrangle, Attrib Wrangle, VOP SOP or AttribVOP SOP, they all result in compiled VEX code so it shouldn't really matter which one you use performance wise

 

of course there may be little differences between (Point Wrangle/VOP SOP) vs (Attrib Wrangle/AttribVOP SOP) as the later 2 are CVEX based, but that may be as well irrelevant

 

the difference in your scene is simply based on the fact that for Point and Attrib Wrangle you use 100 point lookup and for VOP SOP only 20

 

and remember that Point Wrangle is in essence just an nicely wrapped VOP SOP so it wouldn't make sense for VOP SOP to be faster than VOP SOP especially if you know that even VOP network is at the end just a VEX code

 

so now you can happily use Wrangle nodes

 

EDIT: and that print thing I wouldn't be seeing as a bad thing as it's pretty clever optimization, simply if you want to force different output per point, include ptnum as a part of the print output, because otherwise you wouldn't know which point produced that output anyway, you will just end up with millions of prints of the same value or something, not useful at all in my opinion

[magneto]

I think printf behaves that way because the order of execution is not determined. So you have no control over which point executes first, or second, etc.

[mrWolf]

Yeah , the non sequential order must be related to the simd architecture. What I don't quite understand is why it prints out all the steps (even though not in a sequential order) only when the content of the string differs from a previous string (regardless of the semantic of the code, which is just an example of course). It would be interesting to know how this internally works, just for the sake of curiosity.

 

I think printf behaves that way because the order of execution is not determined. So you have no control over which point executes first, or second, etc.

[Green-Man]

Try to execute this example with multithreading turned off ("Use Max Processors" on the Mantra ROP). Would the output be more predictable?

 

[mrWolf]

I am not sure I know how to use a Mantra Rop to force the execution of a sop node.

Can you elaborate ?

 

Try to execute this example with multithreading turned off ("Use Max Processors" on the Mantra ROP). Would the output be more predictable?

[anim]

yes, the order of printf is related to SIMD fashion which means that each instruction is executed for all points before next one

so the first print for all points, then the next one for all points etc

 

it doesn't need to be running on multiple CPUs so you'll always get this behaviour

 

multithreading works on batches per 256(or so) elements so with lower point count is one CPU anyway

 

so in conclusion to my understanding

with multithreading off: all points are executed in order one instruction at a time

with multithreading on: individual batches of 256 points are executed one instruction at a time with no predictable order in which each batch finishes 

 

if you wanted one point at a time with all instructions just run Attrib VOP /Attrib Wrangle in Detail mode and loop for all points

so after knowing all this there should be no surprise in order of printf outputs, except for that unexpected optimisation when all points return the same value as one entry