Hello,

I'm more comfortable dealing with VEX code/syntax but many tutorials and explanations in Houdini contain VOP examples.

So in order to become more familiar of the ‘mechanics/dataflow’ of VOPs to understand what the individual and combination of nodes are doing I'm setting up simple exercise examples to ‘teach’ myself.

Similar to vexs prinf function there is the vops print node that I am using.

In the attached file I have inside a point vop Example A and Example B.

Both examples do the same thing with the exception of swapping inputs.

In example A the nearpoint node easily ‘runs through’ all the points of the second input ‘P’

In example B the nearpoint node only runs through the first point. If I want to second point ( in this case there is only 2 points total as it represents the scatter node which I have set for 2 points only ); I have to go in the get attribute node that precedes the nearpoint node and select that second point.

But how can I get both points to be ‘run through’ like in Example A.

I know I could just use the Example A and go up one level in the network and switch the inputs there on the pointvop node, and this would give me what I want.

But, as I mentioned before, I'm trying to learn how to control and manipulate data in vops.

The only reason I used the get attribute node in Example B is because it was the only one I knew of which would change the salmon colored source output to a green colored output that I could connect to the the second input of the nearpoint node.

Comments and input are appreciated - thank you.

can;t look at the file right now, but you probably need to connect Point Number from globals to Point Or Primitive input of getattrib1, assuming your geometries have the same pointcount

alternatively just do Bind VOP
set type to Vector
and name to opinput1_P
which will be the equivalent of v@opinput1_P in wrangle, therefore corresponding P from second input

Yeah…they have different point counts, but I'm glad you pointed out that possibility. Wiring it as you say then if I select second input on the get attrib node…when I connect a print node to the output, it lists the position of both points, telling me the ‘data’ is streaming through - Great, another way to access data. I see the similarity of using @OpInputx in vex.

I thought bind might also be the answer but never really used that yet. So I'm going to go wrestle with that one and see what I can learn.

Thanks for the input.

The Bind seems to work…sort of.

The first input has a point count of 49 ( a grid numbered from 0-48 ).

The second input has point count of 2 and is a scatter node of the grid set to a 2 point output.

In the Bind node when I set it to opinput0_P, then it lists out (connected to print node) positions of all 49 points ( as expected ).

When I set it to opinput1_P, it too lists 49 points, but differently. The first two points in the list do correspond the the positions of the second input, but the rest of the listed ‘points’ don't even correspond to the first input as I might think because there is a total of 49 listed points; Instead the rest of the points are ‘zeroed’ out.

I guess this Bind node approach would work if I had some kind of filter to screen out the unwanted points.

sure that makes sense
as you are always iterating over elements of the first input
so from second it will find just index 0 and 1, the rest will not find any point

what are you trying to do?
you can always plenty of functions to access geometry of the other inputs, nearpoint(), pcfind(), ….. or just loop through them in for loop, do you need to be in Point mode for the first input?
I'm not clear about your use case, so difficult to give an answer

Hi tamte…thanks for your responses.

I don't really have any endpoint goal with this particular example. I'm mostly at the moment just working at getting a better understanding of working with vops.

But I guess from your last response, part of my curiosity asks the question - Can one iterate exclusively over the second input, ignoring the first input altogether.

I suspect we can't as this seems to mirror what goes on when working with nodes like point wrangles and vex, in regards to the first input is a bit different then the remaining inputs.

I don't know if I am phrasing this right, but it's like there's alot of ‘default’ behaviour tied to the first input when using vex functions- not complaining

Thanks again.

well, it needs to iterate over something, so it as well can be first input
if you want to iterate only over second, then connect second input geo to first input, etc

but is quite common to iterate over Detail, which means once, and constructing for loop that loops through all the points/prims of other inputs, You will loose SIMD speed benefits, but gain others like sequential execution etc.

as well you can keep iterating over points of the first input and then construct for loop to iterate over second from each point, but you have to know what you are doing in that case and when you can afford that and when it would just be too slow

“…well, it needs to iterate over something, so it as well can be first input
if you want to iterate only over second, then connect second input geo to first input, etc..”

Yeah I knew that, but was more interested in knowing if it could be done by some other method, like a function that could initialy switch the default interation input.

I don't have enough experience though to know whether a feature like that would be of any use let alone if it presented some difficult implemenation condiderations.

When I was doing some vex work I did do alot of Detail - only once coding. Like take total points of input 2 and with for loop iterated over them.

So I guess if I really needed to do something similar in vops, save like you say - just switch the inputs, my next thing is to learn using the for loop nodes; I see there's a few variations of them.

Thanks again tamte for helping me bounce my thoughts around…starting to come together making vops seem less foreign.

Thinking a bit more about this….yeah I guess have the ability to switch input defaults doesn't really serve any purpose, that couldn't be worked out differently.

Say I need to use both inputs…just set up two different vop/vex nodes with their inputs switched…once I'm done processing with both I can just merge the results and bring it into another vop/vex node for further processing, and so on.

I mean it could have been designed in many ways, but this is how VOP nets currently work
it's different in ICE or Fabric or other systems, some allow you to iterate over different geometries within single network (and even decide which operation will be done on all elements in parallel and which sequential), some don't

Yeah..thanks again for your input