I just wanted to follow up real quickly! The OneMinus trick does not work. I pointed out earlier that the issue behind is more systemic of how the system is interpreting the roughness map. Right now, a value of zero will give you a sharp, clear highlight and will also use the highest quality cubemap (the non-mipped…
Alright, I guess words aren't cutting it! To images! First, a clear guide to picking your roughness color and how it affects the texture. Now below, I am previewing the shader as it is regularly set up. No adjustments made. The preview on the left is coming from the custom node that sets up the specular D. We can see that…
sure, it's easy enough to do man. go into the material editor, and find the mask texture node here: http://i.imgur.com/KFRAddl.png add a "one-minus" node, and plug the R channel into it like this: http://i.imgur.com/HWUNFUU.png then plug that node into this constant clamp here: http://i.imgur.com/SVayQov.png and this…
By default a one-minus node in UDK will not give you the expected inverted values of a texture sample, because the one-minus node works in linear space whereas the texture sample is in gamma space. Here is a graphic illustrating the problem and the fix: It appears you are only getting correct inverted results because you…
it worked when i tried it out... if you plug it in exactly as i said then it will have the effect that you want. the custom node just contains the calculation i'd found for the way roughness is iterpolated from 0-1. so, all you need to input into that node is a value from 0-1. by placing the one-minus as i said, you're…
you're looking at one part of the whole sum. and that's why it doesn't look like it's working to you. the whole sum for the BRDF is: (D*F*G)/(4 * NoL * NoV) where D = that custom node (Specular Distribution), G = geometric shadowing, F = fresnel. see supporting images here for the the full formula node. with one-minus…
Yes, it would, if the cubemap that was used incorrectly represented an environment that was lit. The cubemaps would actually have to somewhat accurately represent the amount of light coming from the environment for it to work properly.
hey man, i've got no problem with that happening, i'm just not a maya licensee. if anyone else wants to convert the nodes over, that's fine by me. the more streamlined peoples workflows become, the better!
so are you suggesting that i put that into the diffuse instead? that would make no sense, as metals have black albedo, and all of their colour information comes from reflectance.
In my variation of the shader, I plugged the cubemap into the emissive, but it is multiplied by a scalar param to control how much comes through. Maybe not the most efficient way since the cubemap is being applied twice, but it looks nice, so take that for what you will.