I haven’t had much time to dig into OSL and what the capabilities / limitations are… but I’m reading that the next Renderman (19) will have support for it and Blender’s Cycles already has it. If I’m not wrong V-Ray 3 will also have some support for OSL: Chaos Docs
So, let’s play with the idea that you would want to create a generic shader (such as the VrayMtl) in OSL, to be used in all of these OSL capable renderers… is that even a realistic idea?
I’m talking a versatile material which could be used to create glass, metals, plastics etc. Or would it be better to create a series of very specific OSL shaders, rather than going for a generic one?
Would it even be possible to make the same shader work the same way / look the same in multiple renderers?
What are the biggest hurdles and problems to overcome if this is what you’re trying to do?
And what possible drawbacks are you going to face (especially interesting to know with V-Ray+OSL)?
Yes, we already have our initial OSL support included for the next beta.
So, let’s play with the idea that you would want to create a generic shader (such as the VrayMtl) in OSL, to be used in all of these OSL capable renderers… is that even a realistic idea? I’m talking a versatile material which could be used to create glass, metals, plastics etc.You can get quite far with this; in fact one of our developers posted an OSL shader that implements a large part of the functionality of the VRayMtl material.
Or would it be better to create a series of very specific OSL shaders, rather than going for a generic one?This I don’t know… you’ll have to try and see how it goes.
Would it even be possible to make the same shader work the same way / look the same in multiple renderers?To some extent it is possible, especially for texture shaders. However most renderers define their own extensions which are generally not portable. I suppose it is currently a bit like Alembic in the beginning where everyone does their own thing. F.e. many OSL shaders for Blender will run in Blender only.
This is awesome!
I downloaded the latest v3 nightly, gave it a go and emailed support because I stumbled upon an include error
You can get quite far with this; in fact one of our developers posted an OSL shader that implements a large part of the functionality of the VRayMtl material.
So basically, the black magic VrayMtl secret shading sauce math is exposed in it?
Where was it posted?
I would be interested in taking a look to learn and understand OSL in V-Ray better.
If OSL catches on, I think it would be very nice if you would consider keeping a github repo with official V-Ray OSL shaders, and possibly accept user submissions (although not supported or endorsed by Chaosgroup). It would be much better than bundling a couple of example shaders with the installation.
To some extent it is possible, especially for texture shaders. However most renderers define their own extensions which are generally not portable. I suppose it is currently a bit like Alembic in the beginning where everyone does their own thing. F.e. many OSL shaders for Blender will run in Blender only.
That is understandable. What extensions may that be in the case of V-Ray?
In the OSL example in your 3dsmax help, I found this example OSL shader:
surface vray_glass
(
float eta = 1.44
)
{
Ci = reflection(N, eta) + refraction(N, eta, "auto", 1);
}
In the refraction closure statement, what is “auto” and what is 1?
This is not mentioned under “Supported OSL Closures”. Here it just says: closure color reflection(normal N, float eta)
…as if there were no other supported attributes.
Are the closures following any standard where I should be looking up these things?`
When I searched the Open Language Specification PDF I did not find anything that would explain what “auto” and 1 would correspond to.
OSL closures provide a keyword extension mechanism that allows OSL implementations to stick to the specification and yet provide custom control.
However, these additional parameters are not guaranteed to be portable across other OSL hosts.
Yes the closures are following a standard and it is the Open Shading Language specification.
The OSL help section states what we support and additionally define: Supported OSL Closures
You can find a description of the additional keyword arguments for the supported closures in the next section of the help index: Additional Closure Arguments
You can find what keyword arguments each closure supports and a short description of what they do. Again these are V-Ray specific.
In this particular case the refraction closure supports:
float glossiness;
int subdivs;
int auto;
Description of “auto”:
Use a value of 1 to allow V-Ray to take care of back face hits of refractive surfaces. Exit eta corrections and total internal reflections are done automatically. Default value is 0.
This means we can call a refraction closure in V-Ray like so: refraction(N, eta, "auto", 1)
or why not even refraction(N, eta, "auto", 1, "glossiness", 0.76)
I tried this shader in Maya and noticed that the functionality to use a default color when the texture map is not present does not work and instead returns a black color. Is this working in Max?
Yes, it works in Max.
This functionality doesn’t make too much sense in Maya, because
the exporter will always connect something to the texture inputs.
There is no mechanism to detect that nothing is connected to some parameter.
There is a plan to revisit the texture handling in the near future (hopefully 3.2),
because the current implementation is a bit awkward. In the future it should be
possible to connect a texture node to a color/float parameter and it should work
auto-magically.
From what I can see the code uses gettextureinfo to determine whether to use a texture or a color:
float getTextureFloat(string texture_name, float no_texture_default_value, float value_scale, float value_center_offset)
{
int channels = -1;
if (gettextureinfo(texture_name, "channels", channels))
{
color texture_sample = texture(texture_name, u, v);
float sample_value = dot(vector(texture_sample), vector(0.3333333));
float result = value_scale * sample_value + value_center_offset;
return result;
}
However in Maya this produces two parameters rather than one, so it has two opacity nodes for instance rather than one.
The larger issue however is that the current implementation of OSL in Maya defaults to black for a string (which needs to be used for texture maps rather than color) when it does not find a texture file. For something like opacity that means the shader is transparent by default. So I was hopeful the above code might be a way to get around that and supply default colors when it does not find a texture map.
What would really be ideal is if a float returned a slider (rather than a numeric input), and a color could have an input connection (from a texture or any other node in Maya) as you said.
It is not implemented at the moment, but even if it has been it will return true all the time for this case.
In the future you’ll be able to connect textures directly to the color inputs, so this won’t be a problem.
I’m not sure if it is possible to modify the current version of the parameter translator. I’ll take a look and I’ll tell you later.
About the slider issue - it is in the TODO, so we’ll fix it at some point.
The popup and all the other widgets are in the ToDo.
Slightly offtopic:
Just keep in mind that the mapper widget would be the better option of the two (popup and mapper), because it deals with int attributes and not strings.
Strings are generally slow types, so they should be avoided as much as possible.
In OSL it is not that bad if they are constants, but you should keep this in mind.
