Better Material Conversion
Issue #1075
resolved
In the course of pulling apart how the Uber shader works (see #1064
Please let me know if this is a concern and how much technical detail you want me to share.
So far I’ve implemented the diffuse base, diffuse overlay, and dual lobe specular shaders with relative certainty. I’ve also made inroads into the volumetric “subsurface scattering”, but that is mostly eyeballing and guesswork since that part of the code is incomprehensible to me. I barely know what a logarithm is, let alone how to use it on a color.
This is the current status of the exporter in Cycles and Eevee.
This is the status of my implementation of the Uber shader.
One thing I can say (since I got it from the publically available MDL specs and other internet sources, not the Uber shader). To get the blue halo around the head you need you need to implement the Schlick Approximation. It’s long but straightforward if you know math nodes.
You give it the IOR of your surface (typically 1.5) and the IOR of air (1.0) and it computes a fresnel effect. The angle of incidence is here calculated by the dot product of the viewing angle and the surface normal. You also pass in the exponent (5.0 at default) to the equation, and if you increase it the rim lighting gets stronger and narrower.
This is one part of the dual lobe specular mix factor, but it’s a commonly known algorithm.
Comments (56)
-
-
reporter
Until three days ago, I couldn’t read MDL either. But if you take the time, it’s not so hard if you know basic programming conventions.
I probably won’t do the PBR skin shader. I don’t use 8.1 characters, and this is strictly driven by my own needs. But I can look it over and say what I see.
As for OSL, that can’t be used with GPU, so I have no interest, sorry.
I will say, there’s no real difference between Cycles and Iray. If you look at the simple stuff, diffuse BSDF, refractive BSDF and so on, they’re all made with the same algorithms. Lambertian, Oren-Nayer, etc. I haven’t noticed any great differences in the simple building blocks, only the way the Uber shader combines them.
-
reporter
- marked as major
- edited description
- changed title to Better Material Conversion
-
Well I know exactly what a logarithm is I have basic foundations in math, and I was a professional programmer but that was a long time ago before becoming a IT professional. Nonetheless I find learning mdl not easy at all there are a lot of “shading concepts“ apart programming itself.
If you may be interested there’s also some work to add gpu support for osl. But it’s far from complete.
Will gladly test what you find and compare with the actual solution to check for improvements. Again thank you so much for your work on this. If you can’t read complex mdl code then we’ll be happy with what you can do.
note. I’m actually going to improve the top coat that only has basic support right now. Would you do it from mdl instead ?
note. The iray conversion is intended for cycles, not for eevee. I mean, eevee can try to follow the bsdf nodes setup but will be mostly limited and produce different results from cycles. So as for eevee it is best to try to convert the iray uber shader into parameters for the principled shader, with some extra bsdf nodes for the enhanced features, that’s what we do.
-
reporter
It’s not the MDL that’s the problem, it’s that I don’t know how to use a logarithm on a color. What’s the point of that? What does it result in?
I only use Cycles so I’m not concerning myself about Eevee too much, but I’ll see what I can do about Eevee support. Though I’m still waiting for Thomas to give the go-ahead, unless you want to ask on the Daz forums if it’s okay to reproduce the Uber shader’s inner workings?
Edit: Apparently it’s used as a kind of curve to fade things out slower over time? https://docs.blender.org/api/current/bpy.types.DynamicPaintSurface.html?highlight=logarithm
-
For one thing the Schlick approximation is certainly an improvement. The actual fresnel group supports pbr dielectric and metal outputs so schlick could be added. You can generate the daz groups from advanced setup > materials > make shader groups.
note. Or we could use a “daz.blend“ file containing the shader groups to be used for daz materials. Then personally I wouldn’d use the daz name in the importer and would rather replace “daz“ with “diffeo”. But when I talked of this with Thomas he didn’t seem to care of the “names owners”.
-
reporter
I figured the logarithm thing out now. It’s used to calculate color decay for the subsurface scattering. That’s probably why the Principled BSDF has a vector slot rather than RGB, since it has to do some heavy math to calculate the falloff. That’s volumetric SSS sorted then, next I guess is glossy. But since it looks like a redo of dual lobe specular it shouldn’t take too long, I hope.
-
Also, when possible, we try to keep the shader groups simple, and use equations in python for the group input, rather than math nodes. This makes the materials more optimized and easy to read. You may want to consider this as well in your design.
-
reporter
Nope, I’m doing a straight 1:1 copy of the Uber shader. You and Thomas are free to change what you want, but I make no guarantee what I post is performant, only that it’s accurate.
-
The schlick fresnel works great. Formally in your implementation there’s an error since it should be ((1 - ior)/(1 + ior)) ** 2 while you do ((ior -1)/(ior + 1)) ** 2. But given that it is squared it produces the same result.
Below the comparison with ior = 1 that gets no reflections with the pbr fresnel. That of course means that the Schlick approximation is not pbr as it also doesn’t take into account the roughness. But it seems indeed what iray does.
Will update soon the schlick fresnel for Thomas after a bit more tests, since it also changes the equations we use to convert reflectivity to ior. And I need to test the pbr skin as well plus the dual lobes. So it’s a bit of work.
edit. note. Please do you mind to check if metals use the same schlick fresnel as well ? Since we now use two different pbr fresnels for dielectric and metal.
edit. request. What’s the equation used in the mdl source to convert the glossy reflectivity to the schlick ior ?
-
reporter
Here’s the MDL specs:
bsdf custom_curve_layer( float normal_reflectivity, float grazing_reflectivity = 1.0, float exponent = 5.0, float weight = 1.0, bsdf layer = bsdf(), bsdf base = bsdf(), float3 normal = state::normal() ); BSDF as a layer on top of another elemental or compound BSDF according to weight and a Schlick-style directional-dependent curve function. The base is weighted with 1-(weight*curve()). normal_reflectivity – Reflectivity for angle of incidence normal to the surface. grazing_reflectivity – Reflectivity for angle of incidence at 90 degrees to surface normal. exponent – Exponent for Schlick’s approximation. weight – Factor for layer. Range: [0, 1]. Values outside of the range are clamped to this range. layer – Layer to add to the base BSDF. base – Base BSDF. normal – Surface normal vector, in internal space, applied to top layer
The surface normal is the first parameter, implies that the surface is n1 and the air IOR is n2. This is supported by the Blender Foundation, who use part of the equation to convert specular maps for the Principled BSDF shader. https://docs.blender.org/manual/en/latest/render/shader_nodes/shader/principled.html
But as you say, the order is irrelevant.
You don’t even need to look in the MDL file to see how reflectivity is calculated by Daz. If you open the shader mixer (which I have no idea how it works), but if you flail around the bad interface you find the reflectivity value is scaled by 0.08. So the reflectivity is the normalized IOR, exactly like the Principled BSDF’s specular slider.
For the uninitiated, an index of refraction can be specified in three ways: as the actual index ( 1.5 ); as a float from 0.0 to 0. 08 ( 0.04 = 1.5 ); and as an “artist-friendly” normalized float of 0.0 to 1.0 ( 0.5 = 0.04 = 1.5 ). On the Principled BSDF, the specular slider is internally converted from 0.5 to 0.04 (for nonmetallic materials). This 0.04 amount is how much reflectivity a surface should have when viewed dead-on. As it approaches the edges it approaches 1.0, indicating total reflectivity. This is exactly what is seen when looking at the fresnel node’s output for mixing between diffuse and glossy. The fresnel node uses the correct calculation, but the Principled BSDF uses the Schlick approximation (invented in the 1990s for more limited hardware) since Disney, who introduced this “artist-friendly” normalized float for IOR, used it in their own principled shader. As Disney themselves say, “it is "principled" rather than strictly physical“. So the Principled BSDF in Blender breaks PBR for artistic effect.
Internally the Uber shader credits this for inspiration: http://www.iryoku.com/stare-into-the-future
I haven’t looked at metallic materials yet, but MDL offers multiple fresnel functions. So it’s not either or, it’s all at different times.
-
Yes of course it’s simple thank you so much. From the blender equation I can’t get the ior but I can get the R0 term that’s all is needed as input for the schlick approximation. As for the ior order I trusted wikipedia but it’s the same.
# specular to ior conversion for schlick specular * 0.08 = ((ior - 1)/(ior + 1)) ** 2I don’t think the principled shader implements schlick though, at least not the blender implementation. Because for specular = 0 we get no specularity at all, same as the fresnel node for ior = 1.
-
reporter
It does, it says so in the source code. https://github.com/blender/blender/blob/594f47ecd2d5367ca936cf6fc6ec8168c2b360d0/intern/cycles/kernel/closure/bsdf_principled_diffuse.h
-
Yes I know it is based on the disney prinicpled, but obviously it’s not a schlick as shown above. Specifically it seems the fresnel depends on the diffuse color, that is, for specular = 0 the reflection is tinted, even if it is dielectric, while schlick doesn’t.
-
Below it’s my implementation of schlick.
-
reporter
I’d expose the exponent like in the MDL function call. If you turn it higher, it makes the rim lighting stronger and narrower. The whole thing is a non-PBR aesthetic trick anyway, so why not?
So I looked at the Diffeo material setup again. Thomas still hasn’t said anything so I won’t share specifics. But I will say it’s pointless to worry about glossiness at this point. You should absolutely focus your efforts on the Base Color Effect. It’s not hard to implement (a handful of MixRGB nodes) but it is the single biggest thing responsible for making some skins look terrible. Here’s some publically available documentation from Nvidia about the glossiness version (the diffuse version is a Daz custom mode but they’re conceptually similar):
http://mdlhandbook.com/mdl_handbook/index.html#light_at_a_surface#specular-interaction-at-a-surface
-
Actually I have no idea how to implement the base color effects and I just use a different factor for the translucency depending on the effect, based on empiric comparison aka “eyeballing”. So this can be improved for sure as well. But didn’t understand a thing from the document you pointed.
Personally I don’t think you have to worry about exposing/reversing the mdl code. The EULA states you can’t redistribute it, not that you can’t convert it to another shading system. But we may ask to Daniel who’s a daz developer.
https://www.daz3d.com/forums/discussion/578966/can-we-translate-the-daz-shaders-to-blender
-
reporter
It also forbids disclosing the contents, what I’d be doing if I told you how it works.
-
As I understand it, since I own my license of daz studio I’m not a 3rd party (aka someone how doesn’t own the license) and of course I do have my copy of the file so you’re not disclosing anything. These terms were probably intended when daz studio was on sale, though still apply. But we can wait for the answer by daz.
-
reporter
I meant not telling you specifically but revealing its technical details on a public webpage and putting them in a third party addon.
-
It states “except as explicitly allowed in the DAZ Script license“ and I found it, that basically allows you to use the documentation and scripts to develop your own software as expected. Otherwise there would be no addons for daz studio.
http://docs.daz3d.com/doku.php/public/software/dazstudio/4/referenceguide/scripting/eula/start
note. Then of course this is not to push in any way we may very well wait for the answer by daz. I mean I do this for fun so we do what we can.
-
reporter
The EULA places a lot of limits on what you can do but also offers exceptions for law. Based on the US Copyright Office, “copyright protection will extend only to the original expression in that work and not to the underlying idea, methods, or systems described or explained.“ So I am now confident disclosing it is legal, but will speak broadly about methods and systems not expressions and leave the implementation details to you _(_unless we get a response from Daz). And according to the A.F.C. test, “The court explains that elements dictated by efficiency are removed from consideration based on the merger doctrine which states that a form of expression that is incidental to the idea cannot be protected by copyright. In computer programs, concerns for efficiency may limit the possible ways to achieve a particular function, making a particular expression necessary to achieving the idea. In this case, the expression is not protected by copyright.” So achieving the “Daz look” isn’t copyrightable anyway if the steps are already as simple and efficient as possible.
Currently, you use the translucency weight as a mix factor for blending the diffuse and translucent. But this is only true in Scatter Only mode. This is why Mousso figures look good but others look awful, Mousso uses the Scatter Only mode so their figures were designed for the exporter’s current method. In Scatter & Transmit mode, you instead need to darken the diffuse texture by the inverse of the translucency weight and use that as a mask for the mix function. For this to work properly the Translucent BSDF should be the 0.0 input of the mix shader and the Diffuse BSDF the 1.0 input. You may conceptualize this as the light going into the skin is “under” the light reflecting off it.
In S&T mode the diffuse texture is also “normalized”, it’s brightness is removed so it’s color data only. This is used as input to the Diffuse BSDF instead of the texture map. The coupling of normalized texture and darkened mask is why many Daz skin textures are unnaturally bright, to compensate for the darkening effect of Scatter & Transmit mode.
The only difference in Scatter & Transmit Intensity mode is the darkened mask is desaturated to a grayscale image before being used as a mask. This compensates for the darkening so the skin takes the appearance of Scatter Only mode.
Really these three modes are poorly named. They should be “Diffuse Only”, “Diffuse & Translucent”, and “Diffuse & Translucent but as bright as Diffuse Only”.
This simple change, which amounts to a handful of Photoshop blend modes, is key to making the texture maps “look like” Daz skin. The documentation mentions light being “sent to the transmission layer” and such, all that means is a translucent surface lets light enter the volume. Just a natural facet of BSDF shaders, nothing specific to the Uber shader.
Often times translucency makes figures look like gummy bears when light passes through the volume. The SSS layer is used to “consume” light so it doesn’t come out the other side. Currently the exporter uses a much higher scatter density over absorption, but this is wrong. The skin is the same material, absorption and scattering should have the same density. I set both to 1.0 because it’s not necessary to change it. The Uber shader uses the natural logarithm of the transmission color to create a falloff effect to make light appear to lose energy as it enters skin. The logarithm-ized color is then divided by distance, though it must be scaled because Daz and Blender use different units. The scattering component is exactly the same except for mono/chromatic mode. The only different between the two is mono mode turns the SSS Amount into a grayscale RGB color before dividing into the distance but chromatic mode lets you set all three RGB values individually as SSS Color.
SSS took by far the most brute force to get right. Blender cannot do logarithms of colors so it needs to be decomposed into floats and then recomposed, and there was a lot of trial and error about whether RGB values are clamped, whether values should be inverted, and so on. But after much trial and error using a Daz figure with full translucency for reference, I stumbled on the correct formula.
These two steps are the crucial keys for making Daz skin look like Daz skin. Everything else is just gloss (pun intended).
-
reporter
@Alessando
Side note, you’re correct the Principled BSDF doesn’t have true Schlick Approximation. Apparently there’s a head to toe revamp coming and that’s one of the issues brought up. https://developer.blender.org/T99447
-
Thank you Midnight for your exceptional work on this. Some of what you say I can understand, some less. Will try to fix things following your guidelines and testing the results, but I wonder if this makes sense since it seems you already did the job yourself.
Again if you want to fix the actual material groups please go ahead I can help with testing.
-
reporter
I now have implemented pretty much the whole Uber shader inside Blender. Diffuse base, dual lobe specular, glossiness, metallic flakes, top coat, SSS, and emission work more or less the same per the values in Daz Studio. So the above picture is as far as autoconversion will take us.There are some issues.
Iray is a spectral renderer that models light’s actual wavelengths. Cycles is an RGB renderer. It can’t do 100% accurate refraction (dispersion) or thin film unless it’s faked with a custom shader. And frankly that’s more effort than I’m willing to put in.
MDL also has a dedicated backscatter BSDF and the description looks like an advanced physics textbook, so support for that is barebones.
Metallic flakes uses some strange custom Voronoi noise made of oblong ovals that looks like a carpet from the 1950s. It came from a dedicated MDL function and there’s no info how it works, so I gutted everything and faked it with layered musgrave. It looks okay but it’s not too accurate to Iray.
None of these affect skin much so it shouldn’t not be an issue in most cases.
Now we just wait for somebody at Daz to respond.
-
You picture above doesn’t look quite right though, if that’s intended to show the actual result. But it may also happen if you didn’t use the same shape for the figure, or the same lights or camera angle.
- The eyes and lips look off. Also the eyes shape looks different, may be there’s a HD morph applied for that specific figure.
- The fresnel effect on the right side of the nose looks different.
- It may also be nice to see some comparison with strong backlights to compare the sss translucency. And some skins other than human, as a green alien for example.
I’ve not much hope that daz will reply. But again personally I don’t think we need permission from daz for this.
And thank you again for your exceptional work on mdl that’s amazing.
-
reporter
I made a mistake in my comparison render. I had the character in Transmit Intensity turned on but it should’ve been Scatter & Transmit only.
The new comp render has much closer skin textures.
Both images use the same camera, same skydome. No other lights. The Iray render is default load Evangeliya. The Cycles render is a character I use in production with morphs and different eyes, but the skin material was made from scratch with the Evangeliya textures. This is only a skin compare right now. The default material had a 4k texture mask to make shiny lips, I got rid of that before exporting to save memory.
I noticed the glow on the nose too but couldn’t find any bugs in my shader nodes. I think Cycles is just built different.
The tonal range is much different at the levels low enough to get the same SSS effect.
-
If you use a different shape for blender then it’s expected that fresnel is different where the shape is different. As on the nose for example. You should use the same shape to make comparisons. And same textures of course, if your PC can’t handle 4K then go for a 2K figure or resize 4K to 2K (both in daz and blender).
There’s no point making comparisons with wo different figures and texture sets. Apart comparing the overall skin tone, but that’s a very limited comparison this way. I mean it would be useful to compare lips and eyes too.
I don’t get what you mean by “tonal range“ and “the levels“. To compare sss you should just use the same lights, apart tone mapping that should be close enough with standard + medium low contrast as explained in the blog. So, is your sss comparison using the same lights, or did you have to use different lights to get the same sss ? If it is the latter then there’s something wrong with the conversion.
Also in your sss comparison I notice that cycles has the “glowing eyesocket“
#1043I would help with tests myself but can’t without the shaders. So I’m just helping here for what I see.
edit. note. To exclude tone mapping differences, you could save the exr then use the same tone mapping in gimp.
-
reporter
I said, both figures use the same skin textures. Only the eyes are different.
As for the shaping and the lips, I don’t care about that. The Cycles render is the figure I’m going to use in production. I saved my preset and originally exported it with custom materials before I chose to scrap them and redo the Uber shader. I am only interested in skin at the moment so I don’t waste time changing anything else on the default Evangeliya load.
It’s not possible to reliably compare point lights between Cycles and Iray. Cycles point lights have a wider influence area even if set the same as Daz Studio (10cm). And Cycles uses Watts for strength while Iray uses lumens, but the standard conversion of 1 Watt to 683 lumens doesn’t produce the same results. So one of them is off.
The eyesocket uses the materials I exported with, so it having the same flaw as
#1043 -
reporter
Per Alessandro’s (persistent) request, here are the actual node setups I invented from studying the Uber shader.
Models are Philadelphia by Mousso and Cristella by Kooki99. Default load settings, everything turned off except diffuse, bump, and subsurface scattering. Glossiness can wait. Only the face and torso materials have been changed, everything else is autoconverted by the exporter. The ears and lips share the face material so any separate settings they have in Daz are lost.
Scatter Only
This is what the exporter already does. But now translucency is the 0.0 input and diffuse is the 1.0 input, and translucency weight is inverted. This doesn’t make a difference here but for consistency with the other base color effect modes where it’s important.
Scatter & Transmit
The diffuse texture is now normalized with a MixRGB node before being going to the diffuse, to remove the brightness from it. It’s also split and mixed with black according to weight to be used as mask for mixing with translucency.
Transmit Intensity is the exact same except a Hue Saturation node after the black mix desaturates the mask texture.
Chromatic SSS
The distances need to be converted for Blender units. Note the transmission scalar is positive, the scattering scalar is negative.
Mono SSS
Now the scattering distance is positive. The logarithm of a color is always negative, so dividing negative from negative creates a positive. Since SSS amount replaces SSS color and doesn’t get a logrithm, the two numbers are already positive.
-
I would never have guessed by myself what the “base color effect” does in a million years, again thank you so much. To complete the translucency, do you happen to get how the “invert transmission normal“ can be converted ? Because that’s another parameter I ignore since it doesn’t seem to make any difference to me.
As for volumes, that the transmitted and scattering distances get mapped to the color really makes little sense to me, they should get mapped to the density. But I’m going to test.
edit. note. As for lights, 683 lumens per watt is the human eyes perception, not the light source efficiency. The old blender did 15 lumens per watt that’s the incandescent bulb efficiency. In my tests the conversion from daz to blender seems to be 1500 lumens per watt, where 1500 is the default value for lights in daz studio. That’s what the importer does atm, apart zero point lights that get a factor.
-
reporter
Invert transmission normal flips the bump map for translucency, I think for the inside of thin walled materials. Just create a separate bump map node for translucency and tick the invert checkbox.
struct material_volume { vdf scattering = vdf(); color absorption_coefficient = color(); color scattering_coefficient = color(); color emission_intensity = color(); }; Volume properties of the material model. scattering – VDF describing the scattering of light within the participating medium. absorption_coefficient – The probability density (per meter in world space) of light being absorbed by the participating medium. scattering_coefficient – The probability density (per meter in world space) of light being scattered from its current direction. emission_intensity – Uniform light emission in the volume given as radiance per distance traveled through the medium in W/m3/sr.There is no separate density parameter in MDL. Only absorption/scattering coefficient defined as a color. You can try and map it to density but it won’t be accurate to Iray.
-
Thanks for the normal, again I would never ever guessed it myself.
-
@Midnight
I’m trying to fit the mdl translucency in the actual implementation, but honestly I have doubts. That is, for translucency = 0 the setup obviously can’t work, but this may be expected and if so it’s not a issue. Also the results I get in my first test are extremely different from iray. Both in color intensity and tint. I know the tone mapping is similar as you can see from the diffuse reference. It just seems we miss something may it be the mdl translation went wrong ?
Below it’s the comparison for various degrees of translucency for scatter and transmit. Test scene translucency.duf
edit. note. Scatter only translucency works perfect, so this may be another clue that something is wrong with the conversion.
-
- attached translucency.duf
simple test scene for translucency, it's a translucent cube
-
reporter
Did you add the volume? It’s always applied so testing translucency in isolation is pointless. Just set all the values to 0 or black.
-
What do you mean ? Iray can have thin walled materials, thus translucency alone. Or is your translucency setup intended to work only for volumes and not for thin walled ? I don’t think the mdl translucency is different for thin walled, it should be the same code. That is, for skins the volume is just added behind the thin walled translucency. Thus it makes perfectly sense to test translucency alone and it’s the way to go to check if it works in the general case.
Again scatter only works perfectly so I don’t see why transmit and intensity should not.
edit. note. And anyway if you set all the values to zero or black there’s no volume in iray. It is the same as thin walled. So there isn’t any difference. Same for the blender nodes with zero and black they do nothing and there’s no difference.
-
reporter
Inside the Uber shader, volume calculations are done regardless of the thinwalled flag. They’re passed to Iray which does something with that, I don’t know what. But if you set the Uber volume parameters to black/zero and flip Thinwalled on and off, it’s exactly the same. So thinwalled seems to apply the volume at all times, only with black/zero parameters. Which is not the same as no volume.
In Blender, attaching my Iray-style volume node group and setting all its parameters to zero produces a result close to Iray. But disconnecting the volume entirely creates very different results.
So when testing, always attach the volume with zeroed parameters like it’s applied in the Uber shader.
-
As for the uber docs thin walled means no volume. Also in any pbr engine zero transmission/absorbtion and zero scattering means no volume. If the uber mdl code does otherwise I would be very surprised, also because in my tests it doesn’t seem so.
Anyway to test your volume setup I need the color logarithm group. I suppose it’s something as below but I need the log base.
note. important. Also be aware that log(0) is invalid so can’t be used for black colors. Unless you handle special cases. Same for the divide mix that can’t divide by zero.
note. important. Another issue is that log(n) is negative for n < 1, and cycles doesn’t handle negative colors they are always rounded to zero. So the combine rgb will always output black at least this is what it does here. Whatever the base.
-
Did a quick test with log 2 for colors and the volume setup doesn’t seem to work either. Test scene included volume.duf and the blender conversion volume.blend. It’s a volumetric cube with two cubes inside.
note. You don’t need to combine rgb from scalar to color since blender does it automatically.
note. Oops .. didn’t notice your log picture I corrected the log from 2 to 2.718 but makes no big difference.
-
- attached volume.duf
test scene for volumes, it's a volumetric cube with some cubes inside
-
- attached volume.blend
and the blender conversion with the setup by Midnight
-
- attached translucency.blend
for completeness this is the blender conversion for the translucency test with the setup by Midnight, that doesn't seem to work as shown above
-
reporter
I took a look. Mono SSS works, Chromatic SSS has issues. Evangeliya is mono SSS so I did the bulk of my testing with that figure. For now, test mono only. I’ll see if I can find the issue with chromatic.
You are mistaken about negative colors. The RGB node rounds them to black but Cycles does not.
-
reporter
As for log(0) being invalid, MDL offers a utility function to find a color’s natural logarithm. It says nothing about what it returns in case of errors.
The Uber shader has a conditional check for pure black, that my sample omits since it’s not reasonable for human skin tones.
-
Thank you for looking at this. My purpose is to help with testing for what I can do. Your insights are both interesting and useful, though I may not agree with everything.
p.s. In my tests iray disables volume if you use either black or white colors.
-
reporter
For context, in the Uber shader the actual equation is the natural logarithm of the color divided by negative distance. But this doesn’t work in Cycles (for transmitted color). Using the negative distance inverts the absorption color. Instead using the positive distance creates the correct tint. But despite the scattering equation is the same in the Uber shader, in Cycles instead that distance must be inverted for SSS to work properly. I don’t know why but I assume Cycles and Iray volumes simply have different handling of “atypical” color input. So the exact equation won’t carry over and must be solved through trial and error.
But I doublechecked and the chromatic node network I provided is correct (for the values given below). I scaled the distances in multiples of ten in both directions and results were accurate besides minor tonemapping mismatches.
-
You say you double checked and the setup is correct. That doesn’t happen here so this means the blend file I provided with the conversion is wrong. If so please provide the correct blend file so I or anyone interested can double check with you.
p.s. Your setup above is wrong for the volume test scene because the distance is 5 meters 5000 mm, so 50 is already multiplied. May be this is why it works for you ?
-
reporter
The issue with your test scenes is, refraction is not transparency. The refraction part of the code is almost a hundred lines long and full of complicated blending. The white “mist” in your image is the glossy tint coloring the volume.
The settings I posted above (using translucency set to 1.0) should provide the correct results.
-
repo owner
I feel lost atm, but I hope you tell me when the dust has settled.
-
@Thomas Yes of course I’ll tell you together with the complete steps to follow for the implementation to fit the actual setup. I hope that we can get the mdl insights to work soon with some nice results.
@Midnight The test scene for volume doesn’t use translucency at all it’s a thin walled 100% refraction it doesn’t certainly tint anything. Thus it’s a transparent shader in blender. But again please provide your blender file if you think you have the correct conversion so we can check on the same boat.
-
@Midnight As for translucency I believe I got where your mistake is. The “scatter and transmit intensity” is good as you explain it. While in “scatter and transmit” you don’t have to use the normalized color so the setup is as below. At least this way all the colors match perfectly with daz studio for the various degrees of translucency. If you can confirm this I’ll prepare the instructions for Thomas.
Please verify in the mdl code and let me know.
-
reporter
You do need to normalize the color. Removing that does not work for some models like Evangeliya. Left is with, right is without.
Now that I understand materials I’m starting production again, so I don’t have time for deep testing anymore. I’m using my own stripped down skin shader, not the exporter’s materials. So if you want to try and improve on what I posted, feel free. But I tested with translucency/volume because that’s how the Uber shader is made to work. Even the docs, bad as they are say “In PBR modes, refraction wins over other settings.“ It seems to do a complete overwrite of all other layers. So I don’t think your use of refraction for testing volumes is correct. But that’s your choice.
I don’t post data files, only images. The last materials setup I shared should reproduce my results when applied to a cube of the same size in both programs.
-
Thank you, unfortunately your setup works fine with Evangeliya but not with other colors, as in my example above. I’ll try to figure this out.
-
reporter
The MDL file comments directly say it’s meant to normalize the color. So that is supposed to happen.
I did a quick test with and without a Colm Jackson skin texture and got the expected results for a translucency weight of 0.5.
-
- changed status to resolved
This is implemented and there are no news.
- Log in to comment
I’m not an expert on eulas so I can’t tell. Personally I believe the license states that you can’t redistribute, not that you can’t convert the shader to another system. As for implementing a shader directly from mdl absolutely go for it that’s awesome. Personally I can’t read mdl so I do it by comparison testing the possible range of values in iray and trying to understand how it works by reading the uber docs. That’s a pita but worked fine enough so far.
There was a project by Jessub Kim to implement mdl for cycles but unfortunately it was discontinued.
https://bitbucket.org/Diffeomorphic/import_daz/issues/7/convert-shader-brick-materials-from-daz
irayubermaterial.mdl
note. Please look also at pbr_skin.mdl since the dual lobe is different there so we need both versions. Then why only dual lobe ? I mean would you be able to convert the whole shader because that would be amazing. The absolute best would be to convert the uber mdl shader to a uber osl shader for blender.