I think they are built-ins, we don’t have to do anything about them. They should work right out of the box.
Best regards,
Vlado
Yes, they are implemented by the OSL project and they should work, but you have keep in mind that Gabor is known to be buggy up to OSL version of 1.6.1 (V-Ray uses 1.3.3).
Quote from the OSL change log:
* The “gabor” varieties of noise were found to have a serious mathematical
bug, which after fixing results in a change to the pattern. We are hoping
that they were rarely used, but beware a change in appearance. (1.6.1)
Cellnoise should work fine, though.
Vlado, I see you implemented the thin film shader on the docs page. That’s awesome! 
In the recent nightlies I’ve modified the translator and now it is possible to detect in a shader if a texture has a connection or not.
If you have access to the nightlies you can try it right away, if not it will be available in the next SP - 3.1.
Cool. What is the OSL code to call this functionality?
So I’m messing around with angle blends and seem to have re-created the different interpolation types of a Maya ramp in OSL (i.e. a ramp with the facing ratio of a sampler info connected to its V coord). Here’s what I came up with:
**Linear**
float facingRatio = 1 - abs(dot(I, N));
**Exponential up** (not an exact match, but has less clipping, so actually nicer IMHO):
facingRatio = sqrt (facingRatio);
**Exponential Down**
facingRatio *= facingRatio;
**Smooth:**
facingRatio = smoothstep(0, 1, facingRatio);
I was wondering if anyone knows what the formula would be for the angle blends in the VrayVR Mat shader? (Normal Distribution**, Sigmoid****, Gompertz****, Cube Root****, Cubic****, Cubic Polynominal**) I get cubic and cubic root which I think would be
Cubic
facingRatio = pow(facingRatio, 3 );
Cubic root
facingRatio = pow(facingRatio, 0.33 );
Also I think Normal Distribution might be the same as a smoothstep (Hermite) above. Is that right?
But the others (Sigmoid, Gompertz, Polynomial) are making smoke come out of my ears
The same as in the cook_torrance.osl shader - calling gettextureinfo to get the number of channels.
Now it works as expected out of the box.
Our implementation of the Ramp texture is included in the \samples\vray_plugins\textures\tex_Ramp.cpp file in the V-Ray SDK. However I don’t think we’ve coded all the different types that Maya has. You should generally ask Autodesk about more info.
Best regards,
Vlado
Thanks Vlado. I’m more interested in the interpolations used in the VrayVR Mat shader (Sigmoid, Gompertz, Polynomial, etc), rather than the Maya ones. Where would I find the code for that? is it also in the V-Ray SDK samples?
Great, thanks.
No, it’s not in the public SDK. I’m attaching the code here - let me know if you need something else.
Best regards,
Vlado
vray_mtlangleblend.zip (4.57 KB)
Awesome, thanks!
These are issues I brought up in another thread but after exploring OSL for a couple of days, the two big limitations I have found are:
-Inability to output arbitrary values from the shader as render elements. All the closure outputs work but it’s often desirable to output arbitrary values.
-Inability of the VRayMtlOSL to accept filename (or “string”) parameters. My whole interest in OSL is that I am looking for a way to avoid Maya’s dreadful hypershade node connecting mess and want to do everything in the shader. In order to do that, I need to be able to feed texture file names directly into the shader. In fact, in the current implementation (VRay3.0 for Maya), it’s unclear what the “file” node passes to the shader: the hypershade indicates that the “outColor” is passed in, but since the shader parameter is a string, that doesn’t make sense.
Can you tell us what kind of data you want to store in Render Elements from OSL you could not do at the moment?
The problem with the string parameters no allowing you to read files directly might be lifted in a future version.
Just a quick question. Would there be any performance hit using an OSL implementation of the vraymtl compared with the native vraymtl?
It depends. OSL shaders have some overhead, but how much that will affect a render is difficult to say.
Best regards,
Vlado
I’ll second this idea! Basically anything one might put in an OSL closure could be good to have as a render element.
For example my OSL Fabric shader has a sheen component which is written as a closure:
closure color sheen_component = SheenMix * diffuse(bumped_normal, "roughness", Diffuse_roughness);
it would be great to be able to output the sheen as a render element.
To me this gets into the larger idea of being able to use custom AOVs as render elements.
I am mostly thinking about raw maps and procedural patterns. Maybe there is already a way of doing this that I am not aware of but I am currently working on a shader that is using tons of black and white maps that I am combining and multiplying against the final shading components. I would like to be able to output these control maps on their own in their original form to have further control in the comp.
A concrete example would be a face skin shader that would include black and white isolation maps for nose, lips and ears, and procedural noise for blotchiness. If I could output these controls as basic black and white alphas, I could easily tweak these aspects of my render in the comp.
Also, another issue: Is there a way to group subsets of shader parameters under their own gui elements like you have setup the VRayMtl attribute window. I anticipate needing a whole bunch of parameters and I want to be able to organise how they get laid out in the attribute window.
Lastly (and this is probably not specifically an OSL issue): I would like to be able to pass the name of the current shape name to the shader so it could procedurally pull in a specific texture with a name based on the shape name. I often want to use the same material on multiple shapes names. I understand that the UDMI workflow provides a solution but’s unwieldy, particularly on large models. Also, it can complicate larger production workflows quite a bit, because you have to know during modeling and texture painting exactly how you plan to look dev the asset. If different artists are doing these various tasks (often weeks if not months apart), there is no way to anticipate what the needs will be. It’s much simpler to just model everything with UV’s going from 0 to 1, make sure your maps are named according to the shape they belong to and have the shader somehow read the shape name as a per shape attribute that allows it to pull in the correct map.
You can put any custom user tags in file names, and then define them in the V-Ray user attributes of a particular shape. You don’t have to rely on UDIM tags for that purpose.
Best regards,
Vlado
OSL has “page” metatata that I believe is intended for this purpose. I don’t think metadata has been implemented for OSL in Vray yet, but once it is this would be very useful for organizing a shader’s parameters into subsections like all the Vray materials are.