Jump to content
Sign in to follow this  
michaelb-01

AttribWrangle vs. PointWrangle

Recommended Posts

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....

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 by MatDuf

Share this post


Link to post
Share on other sites
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...  :)

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

@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.

Share this post


Link to post
Share on other sites

@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 @.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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 by fathom

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×