Declaring variables in VOPs

[Stremik]

I'm trying to converte an .vfl file in to a VOP network and as soon as I

started I was stuck trying to understand the way variables are being

declared in VOPs.

Does VOP contest somehow separates variables declared in header

of the Shader from the ones declared in it's body? Does it care for

the order in which variables are declared or are they all declared at the same time?

Thanks!

Vladimir

[mark]

hi stremick i had the same question, how can you restrict only some parameters to appear in the SHOP - i do not need all the parameters to be adjustable

as far as i know there is no problems with order.

[deecue]

stremik:

sorry, cant help you on this one...

mark:

are you just wanting to get rid of parameters that are adjustable in your shop? if so then: if you're in vops, its the parameter vop.. if youre checking out the code, you should be looking at the #pragma label commands. getting rid of either of those will be gettting rid of the parameter accessible in your shader..

[Mario Marengo]

Hi guys,

There's no "variable declaration" or "declaration and initialization" in VOPs. That is, there is no direct equivalent to

float myFloatVar;
vector myBlue = {0,0,1};

In VOPs, everything is a value -- you output values, and you input values; you don't pass around symbols that stand for values (i.e: variables).

The reason for declaring and using local variables when writing VEX directly, is so that you can hold some value temporarily, in order to, for example, use it multiple times, or pass it to one or more functions, etc. The value that gets "held" by a variable in straight VEX code is almost always the result of some operation (the exceptions are constants, but those are supported directly). In VOPs, the things that hold these temporary values are the outputs of the different OPs.

Internally, the OPs may (and often do) declare and use their own temporary variables, but this is all transparent by the time you get to the VOP level -- here, the only items that represent values are parameters, constants, and the outputs exposed by each OP. That's it.... and that's all you need, really.

This means that when you go straight from vfl to VOPs, you have to rethink things a little.

For example; here's a "straight vex" fragment:

vector Nf = normalize(frontface(N,I));
Cf = diffuse(Nf) + MyFunkyBRDF(Nf);

Here, the temporary variable Nf holds a value that gets used in two different function calls. In VOPs, the declaration and definition of Nf disappears. Instead, you have the globals N and I which get piped to the frontface vop, whose output becomes the input of a normalize vop. The output of this normalize vop then goes into two places: the input to a lighting model vop (for the lambertian diffuse()), and the input to a custom vop called "MyFunkyBRDF" -- in other words: the output of the normalize vop is the functional equivalent to Nf in the vex code (but I never had to "declare" it).

I know it's a trivial example, but hopefully it clarifies things a little....

Cheers!