Drive Attribute with Chops

[Justin K]

Hey all, doing some chops studies here.  I would like to use a channel I have created in chops (jitter) to drive the scale parameter within a jitter node.  (See attached--red backdrop). I believe I have everything set up correctly, but apparently I cannot just plug in the attribute jitter, or its channel name, to get the desired affect?  And this is despite the fact tha I can see the jitter float attribute in the geo spreadsheet behaving the way I want it to.  

What gives?  Looking through some stuff on Tokeru (love that site!), I noticed that when chops are used to drive attributes, it is often to drive ones that exists already, say a channel called zscale being applied to zscale in an extrude later downstream.   Is this the way you have to do this? Or maybe I am missing something very simple.

 

Thanks!

chop_studies.hipnc

[mestela]

Cheers!

I think I understand what you're trying to do, you might have to alter your approach.

Generally speaking, chops are designed to work on parameters of top level objects (eg lights, cameras, geo containers), and their parameters (translateX, scaleY etc). The naming follows from when parameters are keyframed, they make channels, chops are channel operators.

Most of the chops notes on the wiki are using chops to manipulate attributes on geometry rather than parameters. This is not their natural use case, hence the awkward dance of attributes-> into chops->geometry chop-> (now its channels) ->process-> back to sops ->channel sop->attributes.

The other thing that's confusing is the way attributes and parameters can interact. To state it clearly, parameters are the things in the parameter pane, they're the knobs and dials on each sop, on materials, on objects, while attributes are data on geometry.

Some sops are designed to accept attribute overrides, eg the polyextrude sop. So if you have a zscale attribute on your prims, you can enable that toggle on the polyextrude, and it will affect the poly extrude distance per face.

This is more the exception than the rule! It'll usually be stated very clearly in the docs when you can do this trick. Most sops, and most parameters of most sops, don't support this.

So.

Getting back to your example, the scale attribute of the jitter sop doesn't support this. Lucky for you though, there's a toggle on the jitter sop that says 'use pscale', this is one of those exceptions. If you have a @pscale attribute, then the jitter will be multiplied per point by the scale. As such, you could do a trick here of copying @jitter to @pscale, enable that toggle, and you should be good to go.

In practice there's a bit of juggling required; the default scales aren't quite right, and using @pscale here will then affect copy-to-point sops further downstream (they're another sop that looks for that particular attribute to uniformly scale the copies). I've hacked your setup as cleanly as I can, so I copy your chops jitter attribute to @pscale and set the range to something appropriate, removed the channel calls on the jitter sop, and aftewards restore pscale to what you originally had (0.15 per sphere). 

 

Hope that makes sense!

 

-matt

 

 

chop_studies_me.hipnc

[Justin K]

7 hours ago, mestela said:

Cheers!

I think I understand what you're trying to do, you might have to alter your approach.

Generally speaking, chops are designed to work on parameters of top level objects (eg lights, cameras, geo containers), and their parameters (translateX, scaleY etc). The naming follows from when parameters are keyframed, they make channels, chops are channel operators.

Most of the chops notes on the wiki are using chops to manipulate attributes on geometry rather than parameters. This is not their natural use case, hence the awkward dance of attributes-> into chops->geometry chop-> (now its channels) ->process-> back to sops ->channel sop->attributes.

The other thing that's confusing is the way attributes and parameters can interact. To state it clearly, parameters are the things in the parameter pane, they're the knobs and dials on each sop, on materials, on objects, while attributes are data on geometry.

Some sops are designed to accept attribute overrides, eg the polyextrude sop. So if you have a zscale attribute on your prims, you can enable that toggle on the polyextrude, and it will affect the poly extrude distance per face.

This is more the exception than the rule! It'll usually be stated very clearly in the docs when you can do this trick. Most sops, and most parameters of most sops, don't support this.

So.

Getting back to your example, the scale attribute of the jitter sop doesn't support this. Lucky for you though, there's a toggle on the jitter sop that says 'use pscale', this is one of those exceptions. If you have a @pscale attribute, then the jitter will be multiplied per point by the scale. As such, you could do a trick here of copying @jitter to @pscale, enable that toggle, and you should be good to go.

In practice there's a bit of juggling required; the default scales aren't quite right, and using @pscale here will then affect copy-to-point sops further downstream (they're another sop that looks for that particular attribute to uniformly scale the copies). I've hacked your setup as cleanly as I can, so I copy your chops jitter attribute to @pscale and set the range to something appropriate, removed the channel calls on the jitter sop, and aftewards restore pscale to what you originally had (0.15 per sphere). 

 

Hope that makes sense!

 

-matt

 

 

chop_studies_me.hipnc

Matt it makes perfect sense!  Thanks for the excellent and detailed explanation--il be saving this post for later reference.  

Onward!