AttribVOP VS VOPSOP

[MatDuf]

Hello!

 

So I have just spent the last few hours trying to understand why I wasn`t able to have my point cloud nodes (pcOpen, pcImport, pcIterate, etc.) running normally. It turns out that my problem had nothing to do with the pc[...] nodes but rather about the fact that I was within a VOPSOP node rather than in an AttribVOP.

 

In the end, what I noticed is that whatever was sent into my "while" loop to be processed with pcIterate would end up going nowhere. my while loop wasn't able to return anything else than null data.

 

When I rebuilt my loop structure within a AttribVOP instead of a VOPSOP, everything started to magically work.

 

It seems to me the problem is similar to another problem I've seen about PointWrangle VS AttribWrangle where some functionality works in one but not the other. From this thread it seems that it's all about context.

 

In the end, I did find a workaround by using the AttribVOP instead but I have to admit that I really don't have a clue about why I should use one or the other... Is AttribVOP always better? Is it just a more generally usable node; VOPSOP being more specific or something?

 

PS: I think I've heard that these nodes changed in H14 but we are using H13 because of production requirements.

[pbarua]

AttribWrangle and AttribVOP run in CVEX context while PointWrangle and VOPSOP in VEX context.

The major difference is that you can create geometry in CVEX context while VEX can only modify existing data.

So get used to AttribWrangle and AttribVOP. In Houdini 13 there are some nodes like AddAttrib VOP not available so you use bind VOP or setattrib if attribute already exists.

In Houdini 14 all the VOPSOP's equivalent nodes have been ported to AttribVOP. 

[MatDuf]

I see! Thanks Pradeep!

 

I'll have to push my understanding of the difference between VEX and CVEX.

[fathom]

Hello!

 

So I have just spent the last few hours trying to understand why I wasn`t able to have my point cloud nodes (pcOpen, pcImport, pcIterate, etc.) running normally. It turns out that my problem had nothing to do with the pc[...] nodes but rather about the fact that I was within a VOPSOP node rather than in an AttribVOP.

 

In the end, what I noticed is that whatever was sent into my "while" loop to be processed with pcIterate would end up going nowhere. my while loop wasn't able to return anything else than null data.

 

When I rebuilt my loop structure within a AttribVOP instead of a VOPSOP, everything started to magically work.

 

It seems to me the problem is similar to another problem I've seen about PointWrangle VS AttribWrangle where some functionality works in one but not the other. From this thread it seems that it's all about context.

 

In the end, I did find a workaround by using the AttribVOP instead but I have to admit that I really don't have a clue about why I should use one or the other... Is AttribVOP always better? Is it just a more generally usable node; VOPSOP being more specific or something?

 

PS: I think I've heard that these nodes changed in H14 but we are using H13 because of production requirements.

 

that's odd because pc functions work fine in the "sop" context (ie, vopsop/pointwrangle in h13).  you sure the problem wasn't in how you were specifying your geometry to the pcopen function?

[MatDuf]

 Hi fathom!

 

I just redid the whole thing just to be sure I wasn't imagining things and I end up with the same results. Very simple setup. It is a VOP SOP containing a pcOpen node and a while loop. The only thing in the while loop is the pcIterate node so that I don't get in an infinite loop. Here's an image of my graph below. As soon as I plug my integer const in the while node's "condition" input, my VOP SOP dies. (i.e: the VOPSOP node turns red and all attribs disappear from the details view.)

 

The exact same setup works in an attribVOP with the only exception that I use "input1" from the globals to assign my point cloud texture.

 

 

[MatDuf]

Actually, I just tested and the AttribVOP also works if I don't use the Input from the globals but rather op:/obj/ [...remainingPath...]

 

So the mystery still lingers...!