An assortment of OSL shaders for your perusal

[Rens]

Cheers guys!

Sharktacos, I think you can search for *OSL* or “OSL”, that should work.

Here’s the mixNormalMaps shader updated to match the others, with a page and everything:

MixNormalMaps
A shader for mixing or blending together normal maps as outlined on this page:

Blending in Detail

This gives much better results than simply blending or using overlay mode on two normal maps. It uses Reoriented Normal Mapping as described in the article as well as the idea from the second comment, by “jarkko” in that article. The modes are fairly similar in results.

Links
Page:

OSL – MixNormalMaps – Rens Heeren

Download link:
http://www.rensheeren.com/osl/mixNormalMaps\_tex\_v003.osl
http://www.rensheeren.com/osl/rhfunctions.h
Right-click and save both in the same folder, both are needed for the shader to work. Overwrite rhfunctions.h if asked.

Features
- Blends two normal maps.
- Two algorithms available.
- With mix amount to define the second map blend strength.

How to use
- Create a VRay OSL Texture map.
- Load in the downloaded OSL shader.
- Plug in two normal maps.
- You can then set the mode and mix amount.

[Rens]

ChannelSwitcher
An OSL shader for switching channels. You input two textures and then you can shuffle the RGBA channels around to make a new output. So for example you could have the red and green channels of texture A, green as a black output, and the alpha from texture B. Or, as good example, you could switch all the channels to use the red channel, so you’d have a monochrome output.
Or shuffle the alpha into RGB and adjust it, then shuffle it back.

Links
Page:

OSL – ChannelSwitcher – Rens Heeren

Download link:
http://www.rensheeren.com/osl/channelSwitcher\_tex\_v002.osl
Right-click and save.

Features
- Switch or shuffle the channels from two inputs around.
- You also choose fill white or black for a channel.
- Or invert the channel.

How to use
- Create a VRay OSL Texture map.
- Load in the downloaded OSL shader.
- Plug in two maps, and set the switch modes.

Modes:
1 - red1
2 - green1
3 - blue1
4 - alpha1
5 - red2
6 - green2
7 - blue2
8 - alpha2
9 - one
10 - zero

[sharktacos]

Awesome stuff Rens!

[sharktacos]

Hey Rens, do you know of a way to make OSL attributes greyed out? For example, on the VrayMtl the “highlight glossiness” is greyed out as long as the “lock” is on. I’m wondering if it possible to do something similar in OSL?

[Rens]

Hey! No I don’t think OSL specifies anything like that, unfortunately.

[sharktacos]

@gregvfx

Hey! No I don’t think OSL specifies anything like that, unfortunately.

I was afraid of that :roll:. On a related note, I see you have #ifdef __VRAY_OSL__ calls on many of your OSL shaders. Do you know if there is a way to specify with a similar call whether one is using OSL for Vray with Max as opposed to OSL for Vray with Maya? The syntax of how one needs to write OSL stuff for Maya and Max differs so it would be useful to specify.

p.s. Where did you learn about the #ifdef __VRAY_OSL__ call? I don’t recall seeing it in the docs.

[Rens]

@Nicinus

I was afraid of that :roll:. On a related note, I see you have #ifdef __VRAY_OSL__ calls on many of your OSL shaders. Do you know if there is a way to specify with a similar call whether one is using OSL for Vray with Max as opposed to OSL for Vray with Maya? The syntax of how one needs to write OSL stuff for Maya and Max differs so it would be useful to specify.

p.s. Where did you learn about the #ifdef __VRAY_OSL__ call? I don’t recall seeing it in the docs.

I found it here:

Chaos Docs

And there’s a bit in the OSL docs saying they support the standard C preproc calls.

The #ifdef preprocessor just checks if __VRAY_OSL__ is defined, which it would be when rendering with VRay.
I haven’t tested these shaders with maya, but does it use colour inputs instead of texture inputs? Or how exactly does the code differ for max and maya?
Basically that is what the preprocessor bit is for, it will rewrite the code to fit the renderer, it preprocesses the code/script before it gets compiled. So for VRay it would use texture inputs (UVs yay!) instead of colour inputs. Unfortunately I don’t think you can see if it’s maya or max. And yes that would be very useful!

Vlado / Chaosgroup, is there a definition to distinguish between the VRay platform used?

[_Lele]

holy moly, Rens, you’ve been busy!
Fantastic stuff!

[Rens]

@arquitecto

holy moly, Rens, you’ve been busy!
Fantastic stuff!

It’s true!
Thanks Lele! You’re keeping yourself busy as well I see!

[vlado]

@Kr0no

Vlado / Chaosgroup, is there a definition to distinguish between the VRay platform used?

Unfortunately, no. What are the differences that you find between the Max and Maya implementations?

Best regards,
Vlado

[Dave_Wortley]

@Vlado, is there any way of creating a scripted interface so we can use maxscript to control properties of an OSL map that are generate from the OSL file? The camera map one for instance is a brilliant map but to build it into some camera mapping tools we have I’d need to be able to set the width/height via maxscript. Any thoughts?

Great stuff Rens! Carry on!

[Dave_Wortley]

I wanted to try and make a scripted plugin for the VRayOSLTex so I could build nice interfaces for the camMapScaleTex with buttons to get the aspect automatically etc…but can’t do this without some kind of maxscript support.

[Rens]

@flino2004

Unfortunately, no. What are the differences that you find between the Max and Maya implementations?

OK. I haven’t tested it yet in Maya, sharktacos mentioned he had to adjust the code for Max/Maya, I’m guessing it’s the difference in how strings get interpreted.
For example in other programs, the OSL string gets interpreted as a text input, and color as a texture mappable input… which is then not callable with the texture command. It’s all a bit confusing.

@Art48

I wanted to try and make a scripted plugin for the VRayOSLTex so I could build nice interfaces for the camMapScaleTex with buttons to get the aspect automatically etc…but can’t do this without some kind of maxscript support.

One thing I can think of that might help of is object user properties, and then a VRayUserColor. This is then per object, but at least you can set the render size pretty easily. I can adjust the shader to accept maps if that would be helpful.

[Rens]

And speaking if what’s possible with the texture call in OSL instead of just a straight color input. ; )

UVTransform
An OSL shader to transform your textures! Tile, rotate, offset, and flip!

I’ll make a variation on this with randomisation options… random transforms per object for example.
I’ll also post a distortion version, but if you can’t wait, you can try playing with the replacement UV map, generate using VRaySamplerInfoTex map set to UVW, mix it with a noise, and plug it in.

Links
Page:

OSL – UVTransform – Rens Heeren

Download link:
http://www.rensheeren.com/osl/UVTransform\_tex\_v002.osl
Right-click and save.

Features
– Offset, rotate, or tile your textures in the shader.
– You can insert a replacement UV map. For example after you have added distortions to the map.

How to use
- Create a VRay OSL Texture map.
- Load in the downloaded OSL shader.
– Set the transform values for Offset, Tiling and Rotation.
– If you want to generate a replacement UV map for adding distortions, you can use a VRaySamplerInfoTex map set to UVW coordinates. You can then mix it with a noise map for example. It will look cool, believe me!

O = Offset
T = Tile
R = Rotate

[sharktacos]

@Morbid_Angel

I’m guessing it’s the difference in how strings get interpreted.
For example in other programs, the OSL string gets interpreted as a text input, and color as a texture mappable input… which is then not callable with the texture command. It’s all a bit confusing.

Yes. In Maya it would be preferable to have texture maps be read in as color inputs, rather than as strings. This is the default behavior in OSL, and Vray’s implementation differs in that it uses string inputs for textures. I believe this has to do with the way Max works. Consequently, stuff like in Ren’s OSL code like this:

string n_out_tex = ""         [[ string description = "Texture to use for the outside material IOR." ]],     int use_n_out_tex = 0         [[ string widget = "checkBox",         string description = "Use the texture instead of the value for the outside IOR." ]], 

does not work well in Maya, and stuff in my shaders like this
(which is a sloppy work-around until we are able to have mappable color inputs)

 color getTextureDif(string texture_name, color no_texture_default_color) {     int channels = -1;     if (gettextureinfo(texture_name, "channels", channels))     {         return texture(texture_name, u, v);     }       return no_texture_default_color; } 
color MainColor = getTextureDif(Diffuse_color, color(0.5,0.2,0.2));

does not work well in Max.

Really, the best solution I think is to simply have color inputs be mappable.

It would also be great to have floats be able to be sliders (for example with a OSL “slider” widget). I think this is also a Max/Maya thing. In Max a float is displayed as a number, and in Maya it has a slider. But for Maya with OSL we get numbers for the floats when what we would normally have is a slider.

Finally, a difference between OSL in Max v. Maya is that Max can have a dropdown menu with choices (like Blinn, Phong, Ward, GGX in the VrayMtl BRDF type), whereas Maya cannot.

[Rens]

@ludovick

Yes. In Maya it would be preferable to have texture maps be read in as color inputs, rather than as strings. This is the default behavior in OSL, and Vray’s implementation differs in that it uses string inputs for textures. I believe this has to do with the way Max works.
(…)
Really, the best solution I think is to simply have color inputs be mappable.

Ooh now that would be great. I’m not sure how that could be implemented though. Interesting!
Yes, in max mappable texture inputs and colour swatches are two completely different objects. Color is more of a dead end with no real connection behind it except for the UI swatch. It just supplies the RGB value and you can’t connect to it with another node.
Texture is just an empty placeholder with a map connection slot, no colour swatch to set colour when nothing’s connected.

Now in OSL most of the implementations that I’ve seen use color to get map data, and sort of ignore texture, except for VRay. Ignoring that is weird because then you can’t get to the UVs or alpha channel at all. Unless I’m not getting how it’s supposed to be set up.

What does the string input in maya look like?

Nice shaders BTW sharktacos!

[vlado]

@super_gnu

@Vlado, is there any way of creating a scripted interface so we can use maxscript to control properties of an OSL map that are generate from the OSL file? The camera map one for instance is a brilliant map but to build it into some camera mapping tools we have I’d need to be able to set the width/height via maxscript. Any thoughts?

One of our interns is working on MaxScript support right now.

Best regards,
Vlado

[sharktacos]

@dbarter

What does the string input in maya look like?

In Maya we just have a color input on a shader that can either stay a color, or can be mapped to a texture. In OSL for Maya that could be

string Diffuse_color = “”**,
…
color DiffuseColor = texture (Diffuse_color, u, v, “missingcolor”, color(1,0,0));

except that the “missingcolor” widget has not been implemented, so all the color swatches that are mappable strings all turn black. I think if we could specify a default value for the color to be for a string (as it is in the above code), then it would be fine to keep it as a string in both Max & Maya.

[ricorio]

Nice Shaders !

Would be so nice if someone would make them work in Maya.

Thanks & Greets

Rico

[Rens]

I’ll have a look. : )