Hi, I am using wrangle SOP and I am wondering how I can get the values from a ramp into the code in order to use it?

I assume you have the ramp added to the Wrangle operator (Point Wrangle in my case) added to the node's interface. Good.

Here's a basic method to get it to work for an example where you want to drive pscale along a curve by using a ramp. Just add two ramps, one a float and one a colour called “ramp” and “rampclr” then try this out:


float pct = @ptnum/(@Npt-1.0); // get percentage weight along curve

float rampval = chramp(“ramp”, pct);
f@pscale = rampval;

vector rampclr = chramp(“ramp”, pct);
@Cd = rampclr;



Some notes:

@ptnum/(@Npt-1.0)
That “- 1.0” is critical as both ptnum and Npt are integers. Dividing an integer by an integer gives you an integer. Not what you want: 0 or 1 with nothing in-between. You “could” cast one of the variables to a float but a subtle method is to add or subract a float to one of the integers and you will return a float.

chramp() has several different variadic forms. The one above is the simplest form where the assumption is that you will fetch the first component of the ramp parameter.

float chramp( string; float )

There is a second form that takes an additional argument, 0, 1 or 2 that allows you to access an individual component from a vector colour ramp.
And a third form that allows you to return a

float chramp( string; float; float )

Then there are the two forms that return a vector from a ramp intended to work with colour type ramps.
vector chramp( string; float )
vector chramp( string; float; float )

Hope this helps.

Thanks Jeff, it works like a charm.

Why you are using @ for global variables as ptnum and Npt read their value while it works with out this? Is this just a good habit?

i9089303
..

Why you are using @ for global variables as ptnum and Npt read their value while it works with out this? Is this just a good habit?

from help :

The VEX sop context provides several global variables you can access, such as P, that correspond to attributes. While you can access these directly, we recommend you use the @ prefix for clarity.

.cheers

Yep for clarity and to avoid ambiguity.


There is one exception that I have and one that I use quite often…
For the new POPs that have “VEXpressions” wranglers, the local parameters that are provided for you, like amp, freq, etc are internally wired in to the Snippet VOP buried inside these assets. The convention is that the name of the parameter (not the “Label”) that you get when you hover over that parm, IS the name that you use WITHOUT the @.

Example would be the POP Force DOP with the top “force” parameter and it's associated VEXpression wrangler, you can write:


force *= noise(@nage);


and that works just fine. I almost always use “*=” as this allows you to continue to use the Force <force> vector parameter to control the overall amplitude.

Everywhere else for global variables and variables I wish to export as persistent geometry attributes, I use the @. Well for the files that I create for public consumption…

hi Jeff ,

i just jumped today from H11 to H13 and the first thing i wanted to try was PointWrangle_SOP .

a very interesting approach in terms of workflow too .

with just a single line ( code below ) i reshaped a line on y-axis

, easily controlling that with two ui controls : a ramp and a float ..
@P += rampval * ch( “po” );

and just by adding an @ in front of an value assignment , we get an attrib . cool !

ha-ha !


@cheers

VEXpression wrangling is highly addictive. And rewards you with performance over the old parameter expressions. You end up using less SOPs too.

Thanks you both for your replies.

I am using more and more point wrangler since H12.5 but I was surprised today when I start using H13 for a new shot and I found that by default velocity transfer from FLIP points to mesh instead of point wrangler, attribute transfer SOP is used. Why is that Jeff ?

Christos

I don't know off-hand but please submit an RFE for this.

The reason we used point wrangle was because Attrib Transfer was embarrassingly slow in that case. In 13.0, it is now fast, so we can use the right tool for the job.

jlait
because Attrib Transfer was embarrassingly slow in that case. In 13.0, it is now fast

Without any intension of being annoying, I made a test comparing the same file in H12.5.562 and H13.0.198.21 (it was made in H12 and uses Attribute Transfer).

The whole setup of this file seemed slow to me, so I did the test hoping for speed gain.

The time needed for the Attribute Transfer to cook is only 4% less ..
I am missing something? Should I rebuild from scratch my network in H13 to see a real difference in speed?

Sorry for the confusion.

http://www.sidefx.com/index.php?option=com_journal&Itemid=213&page=index&journal=default&view=FULL&logfile=ALL&icon=ALL&version=ALL&buildstart=&buildend=&perpage=20&search=attribtransfer&find=Find [sidefx.com]

The speed improvement was backported to 12.5.341 and 12.5.342, so you already have it in that file saved in 12.5.562. (Note the parallel cooking doesn't show up in the perf monitor for esoteric reasons)

Thanks Jeff for clarifying this!

So would you say that now, the improvment in speed of the Attribute Transfer node makes it as fast as any VEX/VOP/Wrangler solution would be?
Or is it just faster in comparison with Point Cloud functions in specific?

Attrib Transfer can do a lot of different things, of which only a few common paths were optimized.

For the specific case of just copying the closest attribute value over, it is about twice as fast as the equivalent VEX code.