AttribWrangle vs. PointWrangle

[michaelb-01]

I'm a bit confused as to which VEX functions these two nodes have access to? Is this noted in the documentation anywhere?

 

For example I can create geometry in an attribWrangle node using addPoint(), addPrim() and addVertex(), however these functions don't seem to work in the pointWrangle.

And I can create groups using the addgroup() function in a pointWrangle node but this is not recognised in the attribWrangle node....

[dszs]

I am not too sure about attribute wrangle but point wrangle iterates through every points, thus you can think of it as VOPSOP. If I recall correctly, attribute wrangle affects the primitive. Thus functions such as addpoint() , addPrim() will not work on a point wrangle but will work on an attribute wrangle

[anim]

it's difficult to tell, usually mostly from experience

 

in help, on any vex function's page there is hint which contexts it runs in "Contexts:"

if it says pop, sop - then it'll most probably not run in Attrib Wrangle as that is cvex context, so those functions are only for Point Wrangle (as help is not always in sync with functions, this may not be 100%)

on the other hand if it says All, it doesn't really mean all, but those functions would most probably work with Attrib Wrangle, not necessarily with Point Wrangle though

 

in general, VEX/VOP nodes based on CVEX are more generic and the trend seems to be steering away from sop/pop specific nodes like Point Wrangle/Vop Sop in favor of Attrib Wrangle/VOP, so while there are still some functions that are unique to Point Wrangle, in the future this gap should be closed and you should have all this power and much more in Attrib Wrangle (and other CVEX nodes like Geometry Wrangle DOP, POP Wrangle DOP, Volume Wrangle...) and their VOP equivalents

[fxrod]

I agree that this is confusing and that the docs don't help clarify the issue anymore. Thanks Tom, for that explanation.

[fathom]

yeah, the attrib wrangle is a wrapper around the more generic "attribvop" sop (whose help does explain the whole cvex context bit).  the pointwrangle wraps around a vopsop which provides a bit more data to vex in order to qualify it as "vop" context.

[michaelb-01]

Thanks for the help Tom and Miles!

[MatDuf]

Very helpful!

 

Thanks guys!

 

edit: I wish SideFX would hire a team to completely review their doc and make it accurate and helpful... It is quite hard for newcomers to hit so many walls of incomplete / inaccurate infos..

Edited March 24, 2015 by MatDuf

[Guest tar]

 

edit: I wish SideFX would hire a team to completely review their doc and make it accurate and helpful... It is quite hard for newcomers to hit so many walls of incomplete / inaccurate infos..

 

If only the docs were a wiki... 

[pbarua]

From Houdini 14.0 there is only one AttribWrangle. So there's no confusion.

[fathom]

From Houdini 14.0 there is only one AttribWrangle. So there's no confusion.

 

horrible, horrible, horrible decision.

 

there's no confusion... now EVERYTHING has to use the generic cvex context.  all the useful methods you've grown to learn are out the window.  P, v, N, id, ptnum.... now you have to make sure you declare them properly since there are no more globals.  i absolutely hate this direction.  9 out of 10 times people are going to be operating on points, why not make it easy for them?  this extends to the VOPSOP as well -- it is also going away in favor of the context-free variation.  that makes little difference to vops that are all nodes, but for vops that utilize inline code -- particularly inline code that uses global variables -- it's a huge step backwards.

 

suffice to say, i do not like it.

[bunker]

@Fathom: not sure what you mean by "no more globals". Everything is there in the attribute wrangle node: @P @v @N @id @ptnum @Frame @Timeinc ...

 

 

horrible, horrible, horrible decision.

 

there's no confusion... now EVERYTHING has to use the generic cvex context.  all the useful methods you've grown to learn are out the window.  P, v, N, id, ptnum.... now you have to make sure you declare them properly since there are no more globals.  i absolutely hate this direction.  9 out of 10 times people are going to be operating on points, why not make it easy for them?  this extends to the VOPSOP as well -- it is also going away in favor of the context-free variation.  that makes little difference to vops that are all nodes, but for vops that utilize inline code -- particularly inline code that uses global variables -- it's a huge step backwards.

 

suffice to say, i do not like it.

[rayman]

@Fathom: not sure what you mean by "no more globals". Everything is there in the attribute wrangle node: @P @v @N @id @ptnum @Frame @Timeinc ...

He is probably talking about the lazy synthax, where you can use globals without @.

[fathom]

yes, i'm talking about not having to throw @'s all over the place.  i find them to be a really ugly syntax, frankly.

[acey195]

you'll get used to it, you will be thankful later for stricter types for your attributes

[fathom]

you'll get used to it, you will be thankful later for stricter types for your attributes

 

honestly, i'm not sure it's any stricter.  all it is is more symbols for no real gain.  "P = P + v * TimeInc;"  is pretty simple.  now i have to make sure i cast everything as the right type and if i don't i get silent failures.  "@P = @P + @v * @TimeInc;" will run fine, but not do what i want it to.  i figure if people are going to be coding in vex, trust them to know what they're doing.

 

edit: i stand corrected and vindicated at the same time.  "@P" in a point wrangle is automatically assumed to be "v@P" which makes me wonder how this is at all strict?  it's still a lazy cast.

 

 

for my money, the point wrangle node should automatically promote spare channels to parameters so you can reference them directly (with some mechanism to identify those that are exported) and it should also promote incoming attribtues to exportable parameters.

Edited March 25, 2015 by fathom

[acey195]

well you can still cast certain Attribs to types that they normally are not this way,

and it makes it more visible which values are actually saved to/taken from (point/prim/vertex/detail)attributes and which are just local attributes.

 

I usually type the full v@P, myself just to make sure the result is what I expect, especially when you assign floats/ints as vectors, v@Cd especially, I find that useful.

 

Also, the @ its a safer, more generic approach, since it matches the actual attribute names,

If I have a custom attribute name, "test" and want to access it via a wrangle, I like the syntax, you know its an attribute, you know its type if you added that. makes debugging easier I find.

This also goes for writing attributes, if I want to write a local variable to an attribute, I also want to have a say in which ones get written and which do not.