Hello,

I was hoping someone might be able to comment if they think this is a bug,

or perhaps it's just because I don't have much experience with shaders.

In the following code I am not able to override the attribute/parameters that are commented out. Of course meaning if they were uncommented they don't work.

But the ones uncommented work fine.

The one thing I noticed is that the ones that don't work are the rbg floats:

seems to work if you cast them to vectors
didn't seem to do anything.

-b

Thank you very much bonsak.

Actually they all work if cast the way you show it. Just needed to adjust the other colors and settings so that the results would show up.

The thing is I originaly did something like:

@basecolor = set(0,1,0);
@emitcolor = set(0,1,0);
@emitcolor = set(0,1,0);
@opaccolor = set(0,1,0);

without the ‘cast’ of v. Assuming with the mouseover of those paramters it would automatically know they are vectors.

Say for basecolor. There is the main parameter label which gives basecolor, and then if you mousever the individual components you get the respective basecolorr, basecolorg, basecolob.

I don't understand why the cast with v is necessary.

It doesn't matter though, now I know how to access those paramters.

Thanks again for showing me this.

The bind attributes, the compiler needs to know the type. the ‘v@’ is a shortcut that tells the wrangle to make the correct function prototype for your attributes. There are a few built-in types that has predetermined types, such as Cd, id, P, etc. All others must be declared. The components you speak of don't exist. There is no basecolorr,g,b. That is simply the hscript name for component of the parm tuple. The actual vector type (in the shader call) is vector. You can see this by right clicking any shader and selecting show vex code.

The real way to bind attributes is with strict prototyping.

Instead of
use


Strict prototyping allows setting the default value of the attribute. This is the value that new geometry will get for the attribute downstream from the wrangle.

http://www.sidefx.com/docs/houdini/vex/snippets [sidefx.com]

There is no basecolorr,g,b. That is simply the hscript name for component of the parm tuple.

I sort of thought it might be something like this, and I guess the code is taking this parameter component and assigning it to what was created(attribute) in the shader; vex of the Shader is showing:

There are a few built-in types that has predetermined types, such as Cd, id, P, etc. All others must be declared. The components you speak of don't exist.

How could they not exist? when I have my material node preceding the wrangle node. And I can make changes to the attributes at the parameter control level of the Shader. Do some attributes ‘dissappear’ from ‘view’ of the wrangle that follows the material node while others do not?

In the wrangle I can apply a change to the IOR/Reflectivity attribute using:


yet I can't, for basecolor use:


instead, needing to do:


when in the Shader vex context, both appear to be ‘created’ the same way. eg:


Some added thoughts:

The ‘@’ sysmbol is no where to be seen in the Shaders Vex context, which I assume needs to be applied in order for it to become an ‘attribute’, rather than just a variable.

Of course the vex shown in the Shader is not displaying all the code as there are external files being referenced…I guess if I followed those ‘breadcrumbs’ I would find my answer; See the ‘@’ being applied?

Also, it seems even looking at the vex of the Shader it doesn't give a clear indication of what one would use for the desired attributes name itself. With the exception of ‘reading between the lines’ of knowing to ‘strip’ away the prefix ‘export_’ as from my above previous reference.

In one function in the vex of the Shader it only ‘strips’ away the ‘export’ leaving the preceding underscore, like in the code created by the (Metallic/Roughness) section:

…
vector _basecolor = { 0.90000000000000002, 0, 0 };
…
…
float _ior = 1.7;
…

The alternative is for me to go with what I originally was doing, as I discovered with Kai S.s' Master Class H15 on Shading, where he was simply doing mouseovers of the shaders parameter Label to get the attribute name.

Probably easiest way to learn at first, until I become familiar with the names, remembering the it's not always the case as you mentioned above; basecolorr, basecolorg, basecolorb.

Thanks for the tip on doing the prototyping ( for those attributes in which I would definitely know the name ).

Prior to this, I was putting down a material node before my wrangle so that these attributes would be created for me.

Thanks for the input and suggestion.

I think you are confusing your shader (material) with your cvex (wrangle.) They have no relation. Attributes that exist on the geometry will be bound to the inputs of the shader(material) automatically. The attribute wrangle (sops) doesn't know anything about your material shader, it only binds what you tell it to. If you bind without specifying type, it defaults to float.

Edit: ignore ‘export’ variables of your shader. Those are outputs, and are used to pass values to calling shaders or to the image planes.

I think you are confusing your shader (material) with your cvex (wrangle.) They have no relation

My concern was how to access the attribute created by the Shader and the method to do so.

And was puzzled by the results of the method.

Since I could use one method on a float attribute but not on a vector attribute ( I had to give the additional info specifying it was a vector ).

Thanks for clarifying why.

Attributes that exist on the geometry will be bound to the inputs of the shader(material) automatically.

Yes this appears to be the case as I can see the shader ‘bound’ with the geometry in the spreadsheet.

The attribute wrangle (sops) doesn't know anything about your material shader, it only binds what you tell it to. If you bind without specifying type, it defaults to float.

Hmm not meaning to split hairs on semantics;

But would it not more accurate to say the point/attribute wrangle does know about the attributes assigned to the geometry by way of their name( the attribues ), but just doesn't know enough about their type?

And if the attribute happens to be a float, I'm in ‘luck’ if I only use - @AttributeName = assignedvalue; ( without defining its' type).

Since that's the default behaviour of the wrangle when it is only given the attribute name.

But I'm not in ‘luck’ if I try the same way with an attribute that happens to be a vector.

Hmm…ok…looking at this a bit more.

Just as an example, looking at the ior parameter.

In the geometry spreadsheet I see the shader listed with all the primitives, when I select the material node.

If I follow that material node with a point/attribute wrangle and type in the code:

@ior = 1.2;

Then with the wrangle node selected I see it also listed (ior) in addition to the shader in the spreadsheet.

Does this mean at this point there exists two @ior attributes?

With say the mantra node deciding which one it will use when a render is done?

Or is it more that there is only one @ior attribute( the one I created in the wrangle),

and the mantra node or the code responsible for doing the rendering knows I want @ior to be of a certain value and searches in the shader for a defined variable named ior in order to replace that value?