I have two texture branches connecting at mix vop.

If both branches have their shading layer vop's looking at the same uv layer attribute, the preview ball turns white :shock:

Why does this occur?

Hmmm - playing with VOPs eh Warren? How come?

Shouldn't particularly happen…it's likely caused by something else - I can have two different noises using the same ShadingLayer VOP, pump them into a mix, and get what would be expected - no white ball. Try doing just that with two AANoise VOPs with different settings and hopefully should work. Can you post how you built your basic net? Could be a problem with domains(you may be adding some things that exceed 0-1 and thus are burning out the result).

Cheers,

J.C.

Hey Warren,

It sounds like you are using two shading layer vops with both attrib layers set to 1 (which will cause it to error).

Like J.C. said in his example, use one shading layer vop set to 1 and pipe it to both of the shaders you are mixing..

hth,
dave

See here is the important part.


I am layering an image on top of another one.


So I have two shading layer vops. One for each texture branch.(Now I know you are asking “why not just use one if they are going to be looking at the same uv attributes.” The reason is I want to give the shop the option to choose which uv layers each texture can pull from.)

The problem is if both shading layer vops look for uv1 it will turn white.
:roll:

lol you caught me while I was typing my response…… so why does it pose a problem?

Does vex have a problem with redundancy? (ie to nodes making the same request?)

so why does it pose a problem?

i'm gonna take a wack at this but can't promise i am right.. :wink:

having two of the same nodes is fine in vops (i.e. you would if you needed to set different layers for your shaders). but because vops is just a gui for vex which is used to create operators (all kinds of operators.. shops, sops, pops, etc), those operators need to have parameters and attributes defining certain values, positions, scripts, etc…

so why this is causing a problem is because you are defining the same attribute to two different parameters within in your operator (in this case uv attributes being pulled from your geometry and assigned to position coordinates in your different chains of shaders).. so it creates a problem because if you were needing to reference that attribute somehow somewhere, then how would houdini/vex know where to link that to if it's associated with multiple things…

for instance, say you were to create two texture vops..and in each of their map inputs, you create parameters. well if you were to name both of those parameters ‘map’, this would create a problem because now your operator (your shader) has one attribute pointing to two different parameters. so one of them would probably drop out..

The reason is I want to give the shop the option to choose which uv layers each texture can pull from.

as far as how to set up a shader so you can allow the shop to decide which uv attribute to set it to, i have no idea.. 8) i would love to see how it could be done though.. you might be able to figure it out if you right click on the vex layered surface shop and go to type properties.. you could look at the code used and maybe parse out how it was done in there..

i hope that kinda clears things up and that i'm actually right.. :roll: if not, im sure someone will stop by this thread and be able to correct me..

Alright but my understanding is that the shading layer vop askes houdini a question.(I think they call it echo)


Shading layer1 “where is my apple” or “what colour is my apple”

Shadding layer2 “where is my apple” or “what colour is my apple”

Two different parameters asking for the same information not two identically named nodes.

Ok, right. It is asking questions like you said. It “checks if the geometry attribute is bound and, if so, assigns its value to the new parameter.”

So if you are using the shading layer vop set to the uv attribute, it calls houdini to say ‘where is my apple’ or if its set to the RGB attribute it asks ‘what color is my apple’ and takes those values and uses them as the values for the parameter.

This is where it is different from the parameter vop. Instead of creating a user customizable parameter with its own value, it is pulling specific values based on geometry attributes (and is the reason it is hidden in you shops). And instead of creating user specific names, labels and types of parameters, it is creating a specific name, label and type based on your attribute choice and assigned layer.

And that is how it is still similar to the parameter vop. It is still generating an attribute name based on the attribute type and assigned layer.

So in essence it is doing two things: asking a question and assigning a command. The question is ‘is this geometry attribute bound and, if so, what is it’s value(s)? After that question is answered ‘yes it is bound, and this is where it is, what it’s color is, how transparent it is,'' it then gives a command to create a name (uv8, Cd3, Alpha5, etc)..

So yes, two things. asking a question and assigning a name. So having two set to the same layer asking the same question is fine, but becomes a problem when it wants to create the names to assign to your shader (much like creating two parameter vops with the same name attached).


hope that clears it up.. don't know how well my explanations are coming through.

Just to be perfectly clear: the reason there is a problem when you have two shading layer VOPs both set to output layer 1 is that there is a bug in the shading layer VOP. It will be fixed in the next major release. For now you'll have to get by using a single shading layer VOP and piping its output to multiple locations. Thanks for finding this one,

Mark

Well that solves that one… Thanks guys! :wink:


ps. will the bug fix wrap the identical named parms into subgroups to avoid the conflict? or is it not an issue and just a bug?

that is pretty damn funny.. after all that, it was a bug..

like warren said, i'm wondering if the fix avoids the conflict (that I was under the impression there was) or if it really is just a bug and there is no conflict.

still funny none the less..