Best way to create shader parms for vop based otl

[Solitude]

Hey guys,

 

I've set up some shader stuff in vops that I've connected into the mantra surface shader color input. It does some fancy stuff (not that fancy), and I'm wanting to convert this setup to an otl of it's own (that would plug into a surface shader as a color value). I've taken the entire set of nodes and created a subnet out of it, and made a otl out of that. The thing that gets me is that any parm node inside that otl automatically gets promoted to the top level material as parms. I don't want the parms promoted automatically, I want them to exist on the otl, and have the user decide what to promote to the top level material. I'm guessing I have to recreate all my parm nodes as subnet inputs on the input/output tab on the otl , but I'm wondering if there's an easier way to take the parm nodes I already have and convert them to inputs. It's not a huge deal, it's just that I would have built it this way in the first place if I had known I was going to make an otl out of it. It would more sense to have the parm nodes converted to inputs when I converted it to a digital asset.

 

Actually this question applies especially to ramps as well. If I created ramp parm nodes and want those to exist only on my otl, not the top level node, how do I recreate these? 

Edited November 4, 2014 by Solitude

[edward]

I think the easiest way is to NOT collapse those parm nodes (including ramp parms) into a subnet for making the otl in the first place. The fact that you want to make it into an OTL means that you want it to be generically useful. So the decisions for whether those inputs should be parameters (or ramp parameters) should be decided upon by the users of your OTL.

[Solitude]

Ok, fair enough for most of it, so I am actually recreating most of the parm nodes as inputs, but in the instance of ramp parameters, I am doing a pointcloud lookup inside the otl, I want the user to have a ramp (multiple ramps) for biasing a scale on the radius and some other attributes. I don't think they should have to bind their own attributes by piping it into a random and then a ramp, and then piping that result into this otl. I want this otl to have that capability built in, with all the relevant parms on the otl already, along with an interface that could be defined on the otl, and then promoted as needed.  Does that make sense?   On that note, I don't want to recreate the input value for the radius every time if I know I'm going to be making multiple randoms + multiple ramps, and I don't necessarily want those ramps promoted to the top level.  

 

So do I have to create a ramp parmeter on the otl (not via the ramp parameter node), and reference it with chramp with inline or snippet?

[Solitude]

Looking at the pyro color model, and it's got the basic problem I want to avoid, which is as soon as I put it down there is a ramp on my material node, not the pyroColorModel node.  It's ok if that just a limitiation / design choice, I'm just curious if what I want to do is possible. (I haven't tried the chramp thing yet).