Yeah, just recently updated everything to 3.1 ( linux nodes ), 2 nodes spit out black buckets, i belive issue on my end will triupple double check, my bad didn’t phrase it correctly, i assumed it wasn’t transferring osl’s since i was getting black buckets. Thanks, hope it’s just on my end.
Alright, let me know if the issue still persist.
As I understand it, subsurface has not been implemented in OSL for Maya (although it has in Max). Any idea when it might be ready?
I was thinking it would be neat to make an SSS shader with OSL that divides the scatter values up into R G and B.
Just tried this with 3.1 and it looks like it’s now in Maya. Yay!
I had a question about the implementation. The OSL closure is defined as
[COLOR=#000000]closure color [COLOR=#666699]vray_subsurface[/COLOR] (float refractiveIndex, float phaseFunction, color meanFreePath, color albedo);[/COLOR]
From what I can tell, it looks to me like meanFreePath = scatter color in the SSS2, and albedo = subsurface color. So how would one control the scatter radius? Is this simply a multiplier for the scatter color (i.e the meanFreePath)?
Also, how would one adjust the scatter subdivs in OSL? I tried adding an “int subdivs” variable to the sss closure but it does not appear to have any affect.
Would it be possible to add subdiv control to the sss scatter in OSL in a future release?
Also, two more questions on theory here:
1. Am I correct that the sss part of the VraySkinMtl is made of 3 layers of sss2 added together with differing values for the scatter radius (in OSL the meanFreePath)? Or is there something more complex going on? That is, is the VraySkinMtl just this:
spec
+
spec
+
sss2 (shallow
+
sss2 (med)
+
sss2 (deep)
2. Some other renderers use 3 values for the scatter radius instead of a single float. The idea here I think is to have the red wavelength pass more light though that the blue or green.
One could of course easily multiply the meanFreePath value (which is a color) by another color value. This seems kind of unintuitive to me however. I don’t see any advantage of doing this. Is there something more complex/fancy going on with these the approach of these other sss shaders that I’m missing? I’m sort of guessing that since you guys opted to only have a single float for the radius that you are not a fan of the 3 channel approach. So perhaps you could comment on why you opted for the single channel radius approach?
thanks
2. Some other renderers use 3 values for the scatter radius instead of a single float. The idea here I think is to have the red wavelength pass more light though that the blue or green.You do have three values for the scatter radius - the meanFreePath is a color, so it has three separate values. Although it is represented as a color, the meanFreePath is actually the scatter radius for the red, green and blue light components.
Yes, will make a note about it.
1. Am I correct that the sss part of the VraySkinMtl is made of 3 layers of sss2 added together with differing values for the scatter radius (in OSL the meanFreePath)?No, not exactly. The vray_subsurface() closure corresponds to the VRayFastSSS2 material. The VRaySkinMtl material is somewhat different; there I tried to follow the way it is implemented in other renderers and it works pretty much in the same way. It is calculated internally as three grayscale vray_subsurface() closures multplied by the color of the respective component (with the VRayFastSSS2 material being a special case where the three components have red, green and blue colors). The VRaySkinMtl is also optimized to compute the three sub-surface components together, whereas if you just add them in an OSL material, you could get the same result, but it would lead to way more calculations.
Best regards,
Vlado
Great thread - thanks for the fabric shader sharktacos - it’s easier and looks better than my own I’ve been using for years.
@Vlado- will there be basic texture support coming for VP2? I see that it already works in VP1 so I assume it is on the list…but just in case I thought I should post something.
How does one achieve a “gold” look with the advanced refraction osl texture?
I go to here;
And use wavelengths for:
Red: 0.65
Green: 0.51
Blue: 0.475
to extract k and n values for gold but the colour I get from the OSL texture looks like a copper colour? Anyone can give me pointers where I am doing this wrong?
I’ve been thinking about that as well; I think the problem comes from point-sampling the reflectance curves at specific wavelengths. For some materials just moving the wavelengths a little bit up or down can change the appearance a lot, which doesn’t seem normal. I think the correct approach would be to integrate the color values over the CIE color curves for red/green/blue. However that would require some tool to download preprocess the n/k curves over the entire visible spectrum (or at least, some more wavelengths, like 20 or 50 or 100). Maybe one of the devs here can look into this…
Best regards,
Vlado
Hm, ok will look into it.
Best regards,
Vlado
I’m noticing that the code I have for a bump map in OSL does not match a VrayMtl bump exactly. Wondering if someone knows how to fix this? Here’s a gif showing the difference:
The images are close, but still off. It seems that the VrayMtl bump goes in a bit more and is shifted slightly (as if it is rotated in Y). Also the delta is set in the OSL to 0.004 while the delta in the VrayMtl defaults to 1.0.
Note to get this I had to set the bump amount on the OSL to 10 rather than 1 (which the VrayMtl bump is set to). So initially the difference is even greater.
Here’s the OSL
normal getBumpedBump(color centerColor, color uColor, color vColor, float inverseBumpAmount)
{
vector worldTangent = normalize(dPdu);
vector worldBitangent = normalize(dPdv);
vector worldNormal = normalize(N);
vector average = vector(0.3333333);
float center = dot(average, vector(centerColor));
float ddu = center - dot(average, vector(uColor));
float ddv = center - dot(average, vector(vColor));
return normalize(ddu * worldTangent + ddv * worldBitangent + inverseBumpAmount * worldNormal);
}
surface bump_mat
(
/* Diffuse section */
color Diffuse_color = 0.5,
float Diffuse_weight = 0.8,
float Roughness = 0.0,
/* Bump section */
string Bump_texture = "bump.png",
float Bump_amount = 1.0,
float delta = 0.004,
output color result = 1 )
{
/* Define Bump */
normal bumped_normal = N;
if (Bump_amount > 0.0)
{
color center = texture(Bump_texture, u, v);
color uColor = texture(Bump_texture, u + delta, v);
color vColor = texture(Bump_texture, u, v + delta);
bumped_normal = getBumpedBump(center, uColor, vColor, 1.0 / Bump_amount);
}
closure color diffuse_component = Diffuse_color * Diffuse_weight * diffuse(bumped_normal, "roughness", Roughness);
Ci = diffuse_component;
}
Vlado - I can’t work out what it is but it may not be “trace reflections” that is causing the issue but rather glossiness of the specular is not respected. Well at least on my tests and scenes it seems this is the case.
Can you post a test scene? I am not able to reproduce the error.
Okay I think I see the problem. The shader uses a Vray_Blinn closure combined with a reflection closure. The reflection closure has a parameter for the ETA (the fresnel reflection IOR), but does not have a parameter for reflection glossiness. The Blinn closure has glossiness, but does not have the ETA. A quick fix would be to do this:
closure color specular_component = Spec_amount * SpecColor *
vray_blinn (bumped_normal, Glossiness, Anisotropy, Aniso_rotation,
"subdivs", Subdivs, "trace_reflections", Trace_reflections);
Ci = diffuse_component + specular_component + sheen_component;
This basically removes the reflection component. The Vray_Blinn is also doing reflections, so the reflection closure is redundant. The Vray_Blinn closure does not have a parameter for fresnel, but the shader has code that adds this to it.
Awesome, that code seems to have fixed it. This is a very nice shader - thanks for sharing it. 
The support guys will look into that, but in the meantime have you tried using .oso files instead of the original .osl?
Best regards,
Vlado