PBR: The Problem with Greyscale Metalness
ngon master
So I've seen a lot of posts regarding physically based rendering around lately, and one of the things I commonly see discussed is "metalness" and how to use it appropriately. Firstly I'd like to preface this post with my own personal opinion. I do not like the metallic workflow, I believe that there are too many semantics associated with a word that ends in "ness" and I find that it is fairly difficult to teach it's intended use. I'd also like to preface this post with an understanding that I am not an academic graphics programmer, I did not come up with these concepts and there may be flaws in this post. I would hope that this sparks a discussion.
That being said lets jump in.
Metalness is a rendering optimization. Full stop. There is no real life property "metalness." The metallic workflow is intended to be more intuitive for artists to use. It also allows us to "pack" a mask into a pass in the renderer enabling us to effectively drop the need of a full RGB pass for specularity.
In order to understand what a "metallic value" is first we have to understand why it exists. We can fairly easily split up real life materials into two categories, dielectric materials (substances that are insulators) and non dielectric materials (those that conduct electricity). Effectively this separate materials into metallic and non metallic categories.
Here's where we start to make assumptions. The index of refraction (in simple terms reflectivity) of dielectric materials tends to be around 1.33 - 2.0, this is about a 15% variance. But when you look at that in terms of an 8 bit sRGB texture (0-255) that's not a lot of value change. Therefore we can make a fair assumption that most dielectrics can be represented by a sRGB value of 56 out of 255, or a linear value of 4%. (That magic number everyone talks about.) With that assumption we can typically optimize out of the equation - for dielectrics - the need for a texture map to define that value.
We also know that most non-dielectric materials, occupy the sRGB range of 155-255. Thats a fair amount of space that can also have RGB (color) values, so we know we need a more precise value (maybe a texture map). We now make another assumption, most perfect metals have a nominal diffuse value, so we can optimize that out of the equation as well using a value of 0 for metallic diffuse.
What do those optimizations mean? Well okay, we know we can remove the need for a diffuse value for metals and use our non metallics space on the albedo texture for specularity. We can also remove the need for a texture map to define non metallic reflectance. But, we need a way to define the interpolation between what is going to use full RGB specularity for metals and what is going to use that magic 4% reflectance for non metals.
So now enters the "metallic map." We use this texture, which is stored in a multi use GBuffer with one channel, as a per pixel interpolator to inform the shader where to make those optimizations.
_________________________________________________________________________
So Chris? why can't we use this as a greyscale value shouldn't we use all the tools we have available to use?
Yes. That's fine to do if your studio/project/TA allows it. But keep in mind you are using the renderer in an unintended way.
Why is that "bad?"
Well, the purpose of PBR is to have more consistent and predictable results using real life as a reference. By adjusting this value to be outside the typical range (greyscale) you create an predictably unpredictable result.
Can you explain that to me?
Yes I can try. The shader is purely making a linear interpolation between A and B based on C. The result of which is being what is fed to the lighting calculation.
C represents our metallic variable, A represents our Albedo and B represents our Specularity on our base color texture map. This allows us to use the same texture as two inputs using an interpolator value. If we use C as a binary value its effectively just a switch in the shader between areas that use the base color map as Albedo and areas that use the base color map as Specularity. If we use C as a greyscale value we end up with a non exclusive mix between the two. (I explain the math in images below)
When you use a grey value for metallness you end up mixing the GBuffers together. No longer is your base color map used explicitly for specular or explicitly for albedo. You end up mathematically using the same texture to define two values, both of which do not represent what the actual texture looks like.
So why does that actually matter?
Well first, you are not representing the final value that reaches the lighting calculation in any texture or explicit value, you've mixed them together with no idea what the actual value that's being fed to the renderer is. Next there is an excellent possibility that you are feeding the renderer non plausible reflectance values between 56 and 155 in sRGB resulting in "frosty" looking materials. Where the ratio of diffuse light to specular light is non plausible.
Can I get some pictures?
Yes. I have tried to recreate this problem in Substance designer where I have recreated the math behind the Metallic Workflow optimizations using a Spec/Gloss material.
Here is a standard non metallic material. It has an albedo value of 255 and a specularity of 4% reflectivity.
Here is the same set of values using full metallic. The material now uses a spec value of 255 and a base color of 0 or black.
What happens when I use the same set of values but a metallic value of 50%?
So if you take a look at the base color and specularity these do not represent my input textures or values any longer. In fact if I was expecting to get middle grey in the specularity but it's actually a value of 33%. (The actual math behind this is a linear interpolation between 56 and 255 using an x value of 127 which results in a value 155. That is then converted to linear space for a value of 0.3278).
This is what I was referring to as predictably unpredictable, I do not know what explicitly is being fed to the renderer as it is not coming from a texture map or a value that I set.
So finally I discussed above having values that were out of range of physical specular values. So I've put together a black and white gradient that I will use to illustrate my point. I've also set up a pixel validator that will turn red when it detects specular values that are out of range.
That's a lot of red. Those areas will not produce expected lighting results as you've created a diffuse/specular value that isn't grounded in any informed way.
I see some areas that are not red does that mean I can use some of the metalness value?
Not really no, this illustrates only the inaccurate values for this particular material in other materials it may be less, it may be more.
Chris, what does this all even mean?
Well, this is the way that I personally explain to artists why using greyscale metallic values results in unexpected results and I encourage them to find the right look within the parameters. PBR is about having a consistent look.
That being said lets jump in.
Metalness is a rendering optimization. Full stop. There is no real life property "metalness." The metallic workflow is intended to be more intuitive for artists to use. It also allows us to "pack" a mask into a pass in the renderer enabling us to effectively drop the need of a full RGB pass for specularity.
In order to understand what a "metallic value" is first we have to understand why it exists. We can fairly easily split up real life materials into two categories, dielectric materials (substances that are insulators) and non dielectric materials (those that conduct electricity). Effectively this separate materials into metallic and non metallic categories.
Here's where we start to make assumptions. The index of refraction (in simple terms reflectivity) of dielectric materials tends to be around 1.33 - 2.0, this is about a 15% variance. But when you look at that in terms of an 8 bit sRGB texture (0-255) that's not a lot of value change. Therefore we can make a fair assumption that most dielectrics can be represented by a sRGB value of 56 out of 255, or a linear value of 4%. (That magic number everyone talks about.) With that assumption we can typically optimize out of the equation - for dielectrics - the need for a texture map to define that value.
We also know that most non-dielectric materials, occupy the sRGB range of 155-255. Thats a fair amount of space that can also have RGB (color) values, so we know we need a more precise value (maybe a texture map). We now make another assumption, most perfect metals have a nominal diffuse value, so we can optimize that out of the equation as well using a value of 0 for metallic diffuse.
What do those optimizations mean? Well okay, we know we can remove the need for a diffuse value for metals and use our non metallics space on the albedo texture for specularity. We can also remove the need for a texture map to define non metallic reflectance. But, we need a way to define the interpolation between what is going to use full RGB specularity for metals and what is going to use that magic 4% reflectance for non metals.
So now enters the "metallic map." We use this texture, which is stored in a multi use GBuffer with one channel, as a per pixel interpolator to inform the shader where to make those optimizations.
_________________________________________________________________________
So Chris? why can't we use this as a greyscale value shouldn't we use all the tools we have available to use?
Yes. That's fine to do if your studio/project/TA allows it. But keep in mind you are using the renderer in an unintended way.
Why is that "bad?"
Well, the purpose of PBR is to have more consistent and predictable results using real life as a reference. By adjusting this value to be outside the typical range (greyscale) you create an predictably unpredictable result.
Can you explain that to me?
Yes I can try. The shader is purely making a linear interpolation between A and B based on C. The result of which is being what is fed to the lighting calculation.
C represents our metallic variable, A represents our Albedo and B represents our Specularity on our base color texture map. This allows us to use the same texture as two inputs using an interpolator value. If we use C as a binary value its effectively just a switch in the shader between areas that use the base color map as Albedo and areas that use the base color map as Specularity. If we use C as a greyscale value we end up with a non exclusive mix between the two. (I explain the math in images below)
When you use a grey value for metallness you end up mixing the GBuffers together. No longer is your base color map used explicitly for specular or explicitly for albedo. You end up mathematically using the same texture to define two values, both of which do not represent what the actual texture looks like.
So why does that actually matter?
Well first, you are not representing the final value that reaches the lighting calculation in any texture or explicit value, you've mixed them together with no idea what the actual value that's being fed to the renderer is. Next there is an excellent possibility that you are feeding the renderer non plausible reflectance values between 56 and 155 in sRGB resulting in "frosty" looking materials. Where the ratio of diffuse light to specular light is non plausible.
Can I get some pictures?
Yes. I have tried to recreate this problem in Substance designer where I have recreated the math behind the Metallic Workflow optimizations using a Spec/Gloss material.
Here is a standard non metallic material. It has an albedo value of 255 and a specularity of 4% reflectivity.
Here is the same set of values using full metallic. The material now uses a spec value of 255 and a base color of 0 or black.
What happens when I use the same set of values but a metallic value of 50%?
So if you take a look at the base color and specularity these do not represent my input textures or values any longer. In fact if I was expecting to get middle grey in the specularity but it's actually a value of 33%. (The actual math behind this is a linear interpolation between 56 and 255 using an x value of 127 which results in a value 155. That is then converted to linear space for a value of 0.3278).
This is what I was referring to as predictably unpredictable, I do not know what explicitly is being fed to the renderer as it is not coming from a texture map or a value that I set.
So finally I discussed above having values that were out of range of physical specular values. So I've put together a black and white gradient that I will use to illustrate my point. I've also set up a pixel validator that will turn red when it detects specular values that are out of range.
That's a lot of red. Those areas will not produce expected lighting results as you've created a diffuse/specular value that isn't grounded in any informed way.
I see some areas that are not red does that mean I can use some of the metalness value?
Not really no, this illustrates only the inaccurate values for this particular material in other materials it may be less, it may be more.
Chris, what does this all even mean?
Well, this is the way that I personally explain to artists why using greyscale metallic values results in unexpected results and I encourage them to find the right look within the parameters. PBR is about having a consistent look.
Replies
Having said that, this will probably still come down to two schools of thought, pragmatism and scientific adherence. The pragmatisms won't mind eyeballing values, as whatever works, works - technical invalidity be damned. These artists will be concerned with the end result (will the average person be able to eyeball an invalid specular value? And if they could, would they care?). While those loyal to the idea of PBR will be more worried about following a logical set of rules, end results be damned. This is not to say that they are not concerned with the end result as such, but rather they think their set of rules will inevitably give the best results. Perhaps they are right. Or perhaps they have a different idea of what best is, and for whom.
Imagine a a side-by-side comaprison of a hero asset, one with black and white metalness and valid values only, another with greyscale/invalid values, tweaked to whatever the artist desired. If the majorty of players (customers) prefered the artistic version, who should we listen to? The consumer? The Artist? Or the person who knows that things are technically incorrect? I guess what I'm asking is, can anyone convince me that correct matters when it comes to specular values in the end product. In writing this though, the more it seems like a non-issue. I'd be happy with either outcome; greyscale is forever banned and we only do things the correct way, or greyscale is cool because fuck it. Let's just pick one.
Personally, while I sympathise with the idea of a clear set of logical rules, the pragmatist in me tells me that in the end such things matter not. People won't notice, nor will they care. Games don't have to be perfectly accurate - hell, our physics aren't even physically accurate. Why must our materials be?
As long as the materials are tested in multiple light environments and different ambient/direct lighting I agree with all your points, great note about physics engines as well!
Good post. One small note that may be helpful: The problem with metalness being unpredictable in grey values is purely a matter of shader implementation, not any theoretical failing. In an offline renderer you would be using metalness as a mask to blend between two materials. One locked at your default spec value and one using the spec stored in the albedo map.
The source of error is that in real time renderers, instead of being able to shade an objects diffuse+spec for both a dielectric and metallic material and THEN blending them together, this has to happen in one shader pass. The result is a loss of energy because you linearly interpolated between your diffuse and specular values BEFORE shading. This is why Disney films look fine when using a metalness shader but games have visible energy loss and other ugly transition artifacts.
The moral of the story is that unless you really need to save on memory, specular should probably start replacing metalness as the default workflow. Especially now that most people finally understand the framework of PBR. The spec workflow removes the awkward coupling between diffuse and specular, as well as opening up the ability to make a huge amount of materials that simply are not possible, or require gross approximation, with metalness.
because here http://blogs.unity3d.com/2015/02/18/working-with-physically-based-shading-a-practical-approach/ says that mettalic should be 0.0 or 1.0 for pure metallic. BUT there is not such a thing as pure metallic materials. this is obvious.
From Unreal
"For pure surfaces, such as pure metal, pure stone, pure plastic, etc. this value will be 0 or 1, not anything in between. When creating hybrid surfaces like corroded, dusty, or rusty metals, you may find that you need some value between 0 and 1."
*Insert popcorn gif here*
Perna knows what he's talking about. 95% of metal textures in games (and the real world) have dust, dirt, grime, wear, oil, paint, rust, etc.
You see, I'am not trying to prove a point. Its just how the Shader works. Its theoretical math.
So yeah, pure materials have 0.0 dieletrics an 1.0 for non dieletrics. And is just how it works.
IF someone wants to learn metallic workflow. He need to know this theory. Do you consider number PI as an irrational number when doing math? No. you just use 3.1415. But the first time you learn about number PI, they tell you its a irrational number and bla bla bla.
So, that information doesn't need to be revised. Its true. Its math.
Do you paint a metallic texture with pure white? No you don't. because (in practice) there is no such a thing as pure materials.
So what big hole you put in "my" theory that I don't understand ?
This is why it's important to teach the pure insulators = 0, pure metals = 1 concept, without this basic information it's hard for artists who are less experienced to understand when and why to use greyscale values. Of course I agree with Per that there are times to use gray values, but this knowledge doesn't get you very far unless you've got a team full of Pers who are experts in material properties, which is obviously not going to be the case at most studios.
So, depending on your team, it might be easier to simplify this into "metalness should be 0 or 1 fullstop", even though this is incorrect. If you want to give your artists more control, but don't have a team of Pers, you should probably have some pretty good documentation/example content for where gray metalness values work and when they should be used.
1 - Some real-life scientific facts ("what are the characteristics of metals and non-metals ?")
2 - A simplified model that some engines rely on ("in our engine, it is best do use 100% white and 100% black for metalness input for various technical reasons, so please follow these guidelines when authoring content")
3 - A handy approach that artists can exploit to their benefits ("I might as well make a very clear distinction between metals and non metals for maximum visual impact, and this also means one less map to worry about, so it's all beneficial")
But of course since this is the internet it all ends up being mixed up and argued over endlessly
It's a pipe dream to think that a team of artists can all gather around highly complex going-ons of PBR and create art that all meets those expectations without massive amounts of QA and resources dedicated to just materials. Some teams can accomplish this, but those teams also need to sell 4 million copies to break even or they are a team of less than 10 artists. In a medium team sized environment the best case scenario is you create the most straight forward workflow, that has the fewest points of deviation. Teaching 0 or 1 metallness can be one of those ways to enforce this. Building an in-engine material system that removes much of the blending guess work can also do this, as other things.
It is much easier for a solo person to become an expert on a technical aspect than it is for a team.
There is no theoretical math behind the implementation for the realtime metallic workflow. It doesn't and could not exist because it can't conserve energy. It's based off theory, sure, but it immediately breaks the fundamental rule of PBR: don't lose energy. And does it in a really bad way.
Now I'm not knocking the visuals you can get out of it. You just have to compensate for this lost energy during material authoring and you can get something close to the source material you're trying to create, but that can only be done to a point. It won't ever be fully correct.
If we're critiquing threads on polycount about their use of metalness, then it seems we should be first asking "Why are you using / not using greyscale metalness here?", in order to make them double-check their understanding of these issues, rather than pushing one particular method over another.
Consider the fact that the metalness workflow in games functions by, in a single shader sample, lerping between a ~1.5 IOR reflection coefficient and the value contained in the albedo map using metalness as its range. That is the final specular. Then it lerps between the albedo and solid black, again using the metalness value as its range, which becomes the final albedo. These then get inserted into the BRDF and it computes its output.
This introduces a coupling between specular and albedo that produces a perceptually incorrect transition from dielectric to conductor materials. Because the specular and albedo values are manipulated before being passed into the BRDF, which naturally only shades once (assuming a single lighting pass because that is all that theoretically matters), the transition range loses energy. Let me try to make an analogy to reality.
Imagine each pixel on a model being composed of a percentage of quantum dielectric and conductor "particles". This distrubution varies across the surface where some points are pure conductor and some are pure dielectric. Realistically, as you would go from between 0% conductor particles to 100% conductors existing within any given area of the surface, you see a transition between two aggregate BRDFs, not one like we see used to shade in games. This is the source of energy loss. The fact that instead of blending between the aggregate of two shaded BRDFs, you're adjusting the diffuse and specular energy of a single BRDF is the reason. That's why the metalness workflow in realtime fails to pass the white furnace test. We cannot think of energy conservation as just a phenomenon of pixels. Otherwise the BRDF will appear correct. It has to be considered as a microfacet/particle distribution.
This is why Disney does not have the same visual drawbacks as the type of metalness implementation realtime renderers use. The two BRDFs blended after shading allow them to achieve the perceptually correct, and energy conserving response. It's prohibitively expensive to use such material layering in a game though, because you'd have to shade for every directional and indirect light source in the game twice.
Here's a visual I made to illustrate the difference:
Notice that the closer to half metal, the worse the result is. 0 and 100 are of course correct. Even in this simplest case, realtime metalness fails energy conservation. Here are full res versions if anyone wants a closer look:
Correct: http://i.picpar.com/uSRb.jpg
Incorrect: http://i.picpar.com/vSRb.jpg
Imagine how in a real world application of very different materials all being blended together, the coupling introduced by shading a metalness workflow with one BRDF cannot perceptually hold. Put into practice trying to author linearly will have a tendency to make an image look downright wrong. A good artist will adjust for this naturally, but this isn't information that's well known at all. A specular workflow would remove this artificial coupling and make material blending perceptually correct, because when painting both diffuse and specular as totally independent values, it's WYSIWYG.
I have several questions regarding this metalness usage plus a real-world example to ask questions about:
(BTW this is not for game engines and targeted for 3DS Max renderers and such)
1. We are told that solid black srgb 0 is used for metals in the diffuse/albedo texture. We are also told that we should never use srgb values lower then 30 and no higher then 230 because charcoal is the darkest at 30 and snow brightest at 230. How do you work this out ? Or are both correct and I'm misunderstanding ?
2. Metalness maps - real world texturing question and example:
German tank tracks are made from (manganese steel alloy, dark and slightly brownish in hue and very resistant to rust) as shown in this example they leave the factory with a red primer coat and sometimes flat black paint which quickly wears off in seconds after leaving the factory line.
Over time this bare metal becomes purpleish to dark chocolate brown color with a low gloss and spec but I would still treat it as metal except for the parts that are covered in heavy dirt, dust. Areas that come into contact with other tracks and sprockets idlers are worn down to bright bare metal continously as the tank drives as well as scratches, edge wear/exposed. These areas I would automatically asssume to be pure metal white srgb 255.
Real Panther tank tracks:
https://worldwar2revisited.files.wordpress.com/2015/02/img_0303.jpg
http://static.panoramio.com/photos/large/10962110.jpg
My question is would this brownish part of the track be considered pure metal 255 or something much lower such as the example given above antywhere from 155-255 (perhaps 155 or 180 might be appropriate). What do you think in this situation ?
Here is my render of Panther tank tracks as my interpretation:
http://i.imgur.com/CiVd0NH.png
3. My other question and example:
Camoflouge paint on armored vehicles such as the Panther are very low spec perhaps srgb 46-56 and gloss srgb 66-86.
This type of paint reflects back the very blurry color of the camo instead of wide blurry white spots.
Would this paint be considered low-end metallic grey value ? perhaps 155-180
The material on the Panther is not behaving like a metal at all, treat it as a non metal.
Thank you for the answer for the paint.
The tracks are solid manganese metal alloy but does not behave like metal.......Thats the million dollar question.
Edit: The name is "Zimmerit" https://en.wikipedia.org/wiki/Zimmerit
Yeah I've done zimmerit before on a Tiger 1.
http://i.imgur.com/wQuxmBw.png
But was mainly asking about the tracks since they are solid metal but do not behave like metal. The metal alloy turns darker brown over time it is not rust. And asking about the paint.
The zimmerit is not metal. The paste is applied and then dried with blow torches.......
I'm not discounting what large teams have to face when ensuring consistency across assets, but I certainly feel that metal/rough is an improvement on reflection/glossiness in terms of more predictable results.
As for the example above, if I were trying to create the shader/maps I probably wouldn't worry too much about it on a scientific level. The Zimmerit material is a paste......black in the metal map........where it's chipped it reveals a metal.....white in the map....it's a hard shell-like coating so it's either chipped or not......no greyscale values. The roughness map will make the magic happen.
Again, another great PC discussion.
Although one note is that gloss just an inverted roughness, and a roughness/specular workflow would produce identical results if you're authoring correctly. There are even benefits to authoring with roughness maps instead of gloss. Internally though PBR shaders convert gloss into roughness.
Wanted to reply to these two bits.
We don't actually break it down to atomics. We break it down to the "atomics" of a microfacet distribution, and it's totally necessary because that's how we derive the BRDFs which shade the objects. Without that the development of PBR could never happen. I understand your sentiment, but at that point you've basically stretched it to say, "Why use PBR anyways?" Well, it looks great. And it will keep getting better until the difference is imperceptible. For some of us, it's our jobs and passions. PBR is not hacked by any means, though in realtime it employs some shortcuts because hardware can't do it fully correct yet. But I don't think that means it's a less worthwhile of an effort, and any GDC talk over the last 4 years would agree.
Those things you mention: hair, skin, cloth, etc. They are all being more and more based on real microfacet BRDFs or otherwise real world physics. This is good from a production standpoint because it's what we perceive as being correct results, right off the bat. It's what we experience in the real world. It's not just about consistency between assets in production. It's about being able to get the visuals you want. If people want photorealism, there are rules they have to adhere to. Ad-hoc (read, made up) shading models have been all but abandoned at this point because they actually made artists jobs harder and could never achieve the fidelity of something based on life.
Metalness vs Specular are not -- in the offline implementation a la Disney -- be more or less predictable. They are identical, but take different routes to get to the same result (again, in the offline implementation). If an artist doesn't understand how to get from A to B with either then I'd argue they don't really understand what they're doing in the first place. With Metalness in realtime implementations it is a gimped and not energy conserving version of PBR that can't achieve the same results or consistency as Specular.
My point was more aimed at how the end-user (the non-tech artist) decides to use that power. Getting bogged down in th semantics, unnecessarily at times.
A good example, which also pertains to the reflection/glossiness method, is skin shading over the years in a(skin) shader like MentalRays. There have been many great portrait renders but nearly every one of those artists(who did a breakdown) have shown different reflect/gloss maps. So each artists just brute-forced the maps until the result looked good. Each had their own idea of what was required in the maps. These were more guidelines than rules.
Your skin shader example is a perfect because with cutting edge skin shaders (like UE4's newish separable SSS), you pretty much just author the textures exactly how they should be in real life. The reflection/normal/gloss maps will be standardized in such a way that guesswork is unnecessary. Just like how these days gloss or roughness values have a physical basis and should be identical from engine to engine. The same will happen to skin, hair, fabrics, and other unique BRDFs. Probably within a couple years too!
I do feel like many artists are still averse to this kind of change, as if it removes control from them rather than opening up new possibilities. But I'd rather learn a new workflow and learn it well than have to hand tune every asset I make any day of the week. As far as current PBR goes I don't think it's really that hard at all, and is more to do with people not wanting to get on board and learn a few simple rules that can be understood purely by just observing the world.
It would be great to put a source to this because right now you are just saying these as facts with no reference to back it up and what you are saying is contradictory to almost all material I’ve ever discussed. I think there is a misunderstanding of what “energy conservation” is.
I totally don’t understand where you are coming from. Physically based shading has nothing to do with accurate textures that are within specular and albedo ranges. “Conservation of energy” has nothing to do with input textures, it is only relevant to normalizing the lighting model and enforcing a 0 - 1 range of reflectance.
This is wildly irrelevant and some of it doesn’t make sense at all. I think you’ve gotten distracted by the technical terms. Energy loss is only relevant to ensuring that the amount of light returned in direct lighting does not go above the amount of light transmitted to a surface. There is no loss of energy, I think you are mistaking interpolating between variables before they enter the lighting model and the lighting model function that ensures energy conservation.
You are NOT blending between two BRDFs, I think that is where you are misunderstanding. There is only ONE lit pixel with ONE set of input variables. Metalness is just interpolating the variables BEFORE it even is lit. It does not have to be considered at an atomic level either I’m not sure why you think that is relevant, the most finite source of measurement is a pixel. Even further evaluating whether a single pixel is metal or not metal is irrelevant as it has nothing to do with the lighting model.
If this is true, and I know nothing about the Disney renderer, blending two BRDF’s doesn’t sound as physically accurate as you make it out to seem. The lighting of particle at an atomic level is not blended its either one BRDF or the other. Which again imo is irrelevant because we are evaluating the BRDF of a single pixel given its variable inputs.
What is this an image of? I don’t understand what is going on here as you have provided and quantifiable data. Can you either provide your shader code if this is a custom shader or an image of your node graph if this is substance.
Unfortunately again this doesnt make sense. You are only ever feeding a single set of variables into the BRDF with metalness. The metallic workflow only interpolates the inputs BEFORE entering the light loop. What does authoring in linear space have to do with this? You are correct in this last sentence however and its part of the reason I dislike metalness and why I wrote this post. Greyscale metalness produces variables that are only ever fed to the shader and never visualized in art production.
If you want some kind of source, you can compare how Disney's shader setup works: http://blog.selfshadow.com/publications/s2012-shading-course/
On page 17 they show something similar to what I'm talking about. I'm confused why you're arguing with me on this while not knowing at all about the original implementation of metalness. That is a total prerequisite dude.
That transition in Disney's example would not be energy conserving without two BRDFs, because the surface is defined as a distribution of two BRDFs. This is how every CG film you go see works.
The reality is that there is not much discussion on this in realtime aside from something I saw on the Unreal forums over a year ago and can't find now. Realtime can't afford two BRDFs per pixel, per light. But I feel that if you run through my posts you will realize these are not assertions but proofs of something perhaps non-intuitively true.
Now pls give me the benefit of the doubt, because I do have the experience to know what I'm talking about. I've thoroughly read and replicated most microfacet BRDF papers since the original Torrance-Sparrow, and all the way up to toying with ideas for preintegrating microflake distributions. I'm not getting bogged down in any technical term. Appeal to authority (does it work when it's my own?), yada yada.
The image I made shows the difference between when you blend between two BRDFs, versus just adjusting metalness values with Substance's shader. Any realtime engine will look like the Substance result. The correct result was made in Photoshop because there is no realtime equivalent shader, and doing it this way does not change the result. I could've done a Corona render but that would take ages.
I'll try to run through a proof, no code. This is dependent on your understanding of microfacets. Argue with this logic:
Scenario 1) You have two materials on a sphere: A pure dielectric and a pure conductor. This is like real life, where you could say one is rust and one is clean metal. Your surface is made of microfacets. Consider the microfacets as real and rendered with a brute force raytrace. Each microfacet must be a single value for its diffuse and specular, and because you have two materials on this sphere, a dielectric and a conductor, the distribution of microfacets is simply a percentage of one type vs the other.
The transition ranges on the sphere where there are, say 50% of each material, are two types of microfacets, two BRDFs, converging into final values. Now we've established a physical basis for how this blended material should reflect the incident light.
The binary nature of microfacets demands that for a perceptually and energy correct dielectric/conductor blend, any kind of calculation of this must be equal to a two BRDF problem. I am not saying that passing values into one BRDF is incorrect or suffers energy loss on its own, because it's not true. I'm saying that the assumption that you can use one BRDF for two disparate materials and still get the right result is incorrect, because that breaks all physical ties to the fact that it is, way way down, a binary problem. This is why I made a distinction. It is the metalness lerping between diffuse and specular values before a BRDF event happens that is losing energy, not the BRDF itself.
Scenario 2) You have one material on a sphere: A material which uses lerps on diffuse and specular to go between dielectric and conductor. When you look at a two microfacets that both represent 50% in between your "pure" values, what you are really seeing is two microfacets with the properties: specular = (0.04, diffuse, metalness) and diffuse = lerp(diffuse, 0, metalness). Then you shade a single BRDF.
Scenario 2 =/= Scenario 1. You can run the math yourself and you will get the same result. Alternatively, you could duplicate your BRDF code inside your shader and shade two BRDFs that use metalness to lerp between their results. There will be a obvious difference due to the fact that you are mucking with energy values in a way it should not be.
The takeaway: Adjusting energy of diffuse and specular in a single BRDF =/= to blending between two BRDFs which have different diffuse and specular values. And the latter is absolutely the correct way to render because microfacets are binary. Thinking that all you need for energy conservation between two disparate material types is a single, correct BRDF is a huge mistake. I can make the code in Unity if you really want, but I would suggest you read the original Disney implementation before responding. Perhaps read the GGX paper too, or some of Eric Heitz's stuff on energy conservation.
You're making irrelevant and inaccurate statements on a thread that is supposed to alleviate misunderstandings and you just keep at it. You're not going to confuse me with technical terms, but it seems you are confusing yourself as you keep backtracking on what you are saying. Variable inputs to the BRDF cannot "lose energy." You also seem to forget that non metallics and metallics is just a concept we made up to make the "metalness" workflow possible. You also made your image in photoshop, how is that even remotely relevant?
I'd love to know what kind of production or credible research experience you have that allows you to making these unquantifiable statements other than "I've wrote some pbr shaders in my day." Id love to see your Unity code, thanks.
http://blog.selfshadow.com/publications/s2012-shading-course/
How can you possibly talk about metalness and then admit you know nothing of the original paper?
Since you ask, here is my own shader, not using the implemenation I describe.
http://pastebin.com/d3u3x8gy
I have done proofs for all code within, except I use Marmoset's indirect lighting because we didn't have the production time at my company to implement a custom indirect solution.
The Photoshop example works because it is the aggregate of two BRDFs, which you would understand if you had followed the paper. It does not matter if I blend them in Photoshop or in the shader. The result is the same. This is not something new:
http://www.cs.cornell.edu/projects/layered-sg14/layered.pdf
https://www.cg.tuwien.ac.at/research/publications/2007/weidlich_2007_almfs/weidlich_2007_almfs-paper.pdf
^ READ THIS ONE
On a personal note, I can't believe I'm being personally attacked over this when your job title is "Shader Artist", yet you can't even be bothered to read good material to comprehension. Attack my argument, not me. All I've read so far is "irrelevant and inaccurate" ad nauseum. If you can't muster the professionalism to even try to understand without being rude then you'll get what you want and I'm done. But that won't stop this information from being totally correct and you being horribly mistaken for not knowing why.
Sorry Pior.
@radiancef0rge That's what I'm saying. In the original implementation the metalness workflow is a 2 or more BRDF layered material setup. It lerps between a metal BRDF and a dielectric BRDF artists define, after both are computed. That is where the energy conservation I'm talking about is neglected. Just like how a clearcoat layer could not be accurately represented as one BRDF by subtracting energy around, a metallic-dielectric blend material actually loses energy when reduced to one BRDF. Not because the BRDF itself or its source inputs are wrong (as I tried to indicate in every post since the first), but because the in-shader adjustments done to the specular and diffuse for a single BRDF metallic-dielectric equation aren't going to produce the same image as what would come out of the two BRDF version. And the 2 BRDF version is the true physically correct one. I will try to put together an implementation tonight based on the shader I posted.
Perhaps microfacets weren't a helpful way of explaining. They are however the ultimate proof of dielectric-metal materials needing to be two BRDFs for a truly reciprocal and energy conserving image. Their nature is binary (one microfacet = one brdf), so they have to be treated as layered, or in this case distributed linearly. Another good reason why you should keep them separate is because metals reflect (based on free electrons) fundamentally different from real dielectrics in real life, so their microfacet analogies should copy that too. Both reasons are good enough, but the important thing is that the equation must be reciprocal (or for realtime, as close as possible). I've said from the beginning that it's too expensive to do this on current gen tho, so all of this is just trying to explain theory that I was asked to expand on.
My first bit should summarize why I could blend in Photoshop and not care, because all I needed was the final screenshot from Substance of a pure dielectric, and a pure metal. Same color, roughness, etc. Then I made a scale of metalness values for my chart between 0-100% and blended duplicates the two layers together until I had enough spheres. The middle sphere in the "Correct" img for example is just a 50% layer blend of the pure metallic image over the pure dielectric one. The "Incorrect" is taken directly from Substance where I've adjusted the metallic value and took a screenshot, so for the middle sphere it would be 128/255 metalness and so on for the other spheres. Because I know the real equation is a two BRDF problem and just a linear blend of the two it was easy to make an accurate example by just blending PS layers and not requiring real code, because the code would do the same kind of blend after shading too
I believe the Disney BRDF Explorer allows you to see this all yourself with their own shaders. It's a little hard to compile, or at least was for me, so be warned it might take some tinkering.
Just wanted to thank @radiancef0rge for writing that up, makes a lot of sens to me and cleared some things up.
cheers
I had to head out of town to handle a small emergency today, but I wanted to share another part of the metalness workflow that not many people know:
Where did the original rule of 0 or 1 only come from?
When Disney introduced the metalness workflow 4 years ago, they urged artists working with their system to use binary values because they use a material layering system. When blending between a metallic and nonmetallic material instead of doing it by blending texture flats together to produce one set of inputs, they blend together two different materials after they have been shaded. So instead of say a set of rust and metal textures being blended together to make one final set of texture flats, they would make a rust and metal set of textures for the entire object and then use a mask to blend between the two whole materials, after shading. That is why metal IS in fact binary in an offline renderer setup.
And that was the entire source of the argument on the last page really. Anyone who read Disney's paper on the subject knows this stuff already though.
Good heavens... I think my virginity might have come back after reading this thread
Please just ignore the attack, i enjoy your post very much and i think many others to.
please keep on its so important stuff for noobs like me.
Thank you guys, by the way, for pointing all that stuff out. It is great to learn from [some] people that actually undertand the physics behind PBR good enough to explain it in a fairly simple way.
PBR isn't a real thing. It's just a general term/buzz word used for a group of loosely defined standards that have been around in one form or another for 30+ years. As Per said there isn't a global 'one size fits all' standard.
As stated by others transitions between metal and non-metal are absolutely fine as long as they are done in a consistent manner. We can never be totally physically accurate with the metallic model as 100% metal materials don't really exist outside of a vacuum . The instant they hit a real world atmosphere they start to oxidise (nobel metals are resistant to oxidisation but still become weathered and get covered in dirt/dust) and going by the binary logic and being totally physically accurate we would need to have everything as dielectrics, which negates the need for metalness altogether, but it would look like ass so we don't do it. We are already breaking the rules of being totally physically accurate when we count rust as a dielectric and use 4% reflectivity for all non-metals, but we live with it as an optimisation.
In any case, the Disney shading model is "principled" only, so we are not even basing our assumptions on something that is physically accurate in the first place. They made optimisations and specifically choose fewer, more intuitive & artist friendly parameters over a more complex, strictly physical model (roughness not actually being true surface roughness is a great example of this) & specifically state that the metallic parameter is a linear blend between two separate models, as they don't have the same limitations that we do in realtime.
TL;DR: Transitions between metal and non-metal are absolutely fine when done in a consistent manner. Metalness is simply an optimisation used to make the authoring and rendering of assets simpler, faster and cheaper to do and it looks great for the most part. The whole point is to make plausible materials rather than perfect physically accurate ones.