I myself do not really understand the term ''metallic''.
Is it mix of specularity +reflection ? Is it a gloss or a term to determine the hardness/roughness of a surface?
Edit; ok I just read that. It's a workflow setup, not a map. I'm sorry, never used real time renderers bexcept zbrush.
hopefully i can clear it up a little further for you as well.
with PBR, there isn't really such a thing of specularity. i know you might think it's productive to think of specularity and reflection as two different things, but really they're the same.
so with that in mind, in PBR we try to refer to it as just "reflectivity". what you're controlling with your reflective input, whether it's through metalness or "specular" map, is the strength and colour of the reflection when fresnel is at zero (ie: when you're looking straight at it).
using a full colour reflection map input (or "specular"), it gives you access to the full range of reflective values for ALL materials that are being controlled by this map, regardless of their metallic state. what this typically means is that you'll be painting very dark grayscale values for non metals, with little variance and full colour bright values for metals in this map.
a metallic map kind of simplifies this workflow quite a bit, by letting you just have one colour map for everything, you paint your diffuse colours for non metals, and your reflection colours for metals all into the same map, and then use a black/white metallic mask to tell the shader "these bits are metal, so use this pixel value for reflection, and these bits are not so use them for diffuse, and assign them a reflective value of 0.04".
To expand a little, its not that specular or specularity "isn't a thing", its that what we're actually talking about is specular reflections, its one thing, not two different things as many traditional shaders have implemented it.
Older shaders would often have simple specular reflection from dynamic light sources, and then a single generic cubemap for ambient image based reflections. Because this cubemap didn't really match the scene, and often didn't match the microsurface (roughness or glossiness of the material), it often had separate paramaters entirely to control it in the scene.
These days we still have simple specular reflections from dynamic light sources, but IBL systems are way more advanced. Now the cube maps are actually rendered from the content in your scene, and the cubemap reflections are sharper or blurrier depending on your roughness/gloss map as well, so the entire system can be consolidated into one system, even though technically its still 2 or even 3 different functions (screen space reflections are often used on top of cube map reflections as they can be more accurate than pre-baked content for moving objects or objects that need inter-object reflection).
So what you end up with in a PBR system is basically all your light sources behave in a physically plausible way, so your inputs can be simplified.
The specular map and metalness map workflow are really just two different ways to pack the content that drives the lighting system, and both can give basically the same results.
anyways, looks like metal has an overwhelming lead right now, with 5x the votes as spec, so hopefully when unity 5 comes out, it'll start with metal. because i hate spec.
anyways, looks like metal has an overwhelming lead right now, with 5x the votes as spec, so hopefully when unity 5 comes out, it'll start with metal. because i hate spec.
As the Unity 5 beta already uses the specular workflow, I doubt they'll get rid of it. I think they're just trying to determine if they should also include the metalness workflow.
Actually there is : simplicity. People are already confused enough over what PBR is and what it implies. Arguably, both workflows have only very minor advantages over one another, so it makes sense to just stick to one. Having both means having double code paths for Unreal/Unity to maintain (for their shader and everything that has to interact with it). Same thing for documentation, tutorials, and teaching material in general. In the long run, it means market fragmentation for assets : people wanting to give or sell ready made textures on the Asset Store or Unreal's equivalent will have to ship for both or deal with "Why didn't you do it the other way ?" complaints all day long.
I actually see it the other way round : either way's fine, but why include both for a given engine ? And why make such a fuss about it ?
Which one u like to work with?
Black and white masking pipeline can reduce the amount of texture i use for complete map.
But traditional spec map workflow seems quite friendly when it ported to weaker devices or different platform. I know unity love this. But I could be wrong btw
Actually there is : simplicity. People are already confused enough over what PBR is and what it implies. Arguably, both workflows have only very minor advantages over one another, so it makes sense to just stick to one. Having both means having double code paths for Unreal/Unity to maintain (for their shader and everything that has to interact with it). Same thing for documentation, tutorials, and teaching material in general. In the long run, it means market fragmentation for assets : people wanting to give or sell ready made textures on the Asset Store or Unreal's equivalent will have to ship for both or deal with "Why didn't you do it the other way ?" complaints all day long.
I actually see it the other way round : either way's fine, but why include both for a given engine ? And why make such a fuss about it ?
I think they sshould use the specular workflow since if someone wants metalness they can easily just write a simple modification to the specular shader to start sampling reflectance from a static value or the albedo based on a mask.
You could easily have one pbr method be the default one everyone sees, and it's also pretty easy to convert spec into metalness. One method allows for better compression, the other has better control. You could easily hide a switch under project settings or hide it under shader options just for people that know what they are doing.
it's also pretty easy to convert spec into metalness
It's easy to convert metalness/rough into spec/gloss but not the other way round, if only because the latter allows for more "material appearances" than the former. Whether you actually want or should use those additional possibilities is debatable.
to DefaultEngine.ini (of your project), you'll get the old Specular workflow in your materials.
Note that it is a different rendering path and some newer features will not function with it turned on (Subsurface Profiles may not work).
If you set it in BaseEngine.ini, it will break example content, and will break any content you've created in your current project using base/metallic inputs. Edit the inis in your project
It removes the Base and Metallic material inputs and replaces them with Diffuse and Specular.
I don't really recommend it, as I'm not sure how supported it will be, but if you want to use it - the option exists right now (and has since the launch of UE4)
It's easy to convert metalness/rough into spec/gloss but not the other way round, if only because the latter allows for more "material appearances" than the former. Whether you actually want or should use those additional possibilities is debatable.
Nope its easy to convert both ways actually. I'm working on a tutorial that explains how. =P
You'll get some slight variation doing the conversion, but nothing crazy. Also spec to metalness will give you vastly different results if your original spec content isn't properly calibrated (eg, implausible values).
Sorry if those images are confusing, I've got a bunch of text to go with it but its all still WIP.
Nope its easy to convert both ways actually.
You'll get some slight variation doing the conversion, but nothing crazy. Also spec to metalness will give you vastly different results if your original spec content isn't properly calibrated (eg, implausible values).
Well, that was my point. Sorry if I was not clear. It's possible to convert from spec to metal if you are using specular and diffuse values which you can obtain with the metalness workflow. It's much more complicated, and not always possible, if for example you have a strongly colored specular with a non-zero diffuse. One can get somwhat close by using intermediate metalness values. But if one's going to limit onself only to spec/gloss values that can be converted to metalness then I see even less reason for having both in a given engine.
substance designer does it afaik but I don't remember is it spec->metalness or other way round.
Yes, we've done filters that go both ways in Substance Designer, though as I said above the spec to metalness converter does not work in all cases since not all cases are convertible. Not sure if the spec->metal filter is currently shipping though.
Well, that was my point. Sorry if I was not clear. It's possible to convert from spec to metal if you are using specular and diffuse values which you can obtain with the metalness workflow. It's much more complicated, and not always possible, if for example you have a strongly colored specular with a non-zero diffuse. One can get somwhat close by using intermediate metalness values. But if one's going to limit onself only to spec/gloss values that can be converted to metalness then I see even less reason for having both in a given engine.
Yes and no. Mostly yes on a technical level, the metalness workflow isn't as easy to represent (or convert) odd values, however in reality those values don't show up too often. If you're seeing hugely different results with the spec vs metalness workflow, more than anything that is probably a sign that your content isn't authored in a logical manner, rather than any sort of technical restraint. In that case I would look into the root cause which is probably poorly calibrated content.
Nearly all non-metals have uncolored reflectivity in the 2-8% range, most around 4%, I really doubt that anyone would ever spot the difference between 4% or 6% reflectivity when viewing an asset in an actual game situation. Most of the surface variance comes from the gloss/roughness for non-metals. For metals, the albedo map works nearly identical to the standard specular map content, so all that variation can be added in the same typical way. You're locked to 0% diffuse, but again for an actual pure metal, the difference between 5% diffuse and 0% diffuse is going to be hard to spot. If you have a metal with like 80% reflectivity and its got a diffuse of 40%, you're just straight up breaking the laws of energy conservation, so again, its content that would be the problem there.
Now, maybe you're doing a NPR game or something and unrealistic materials values are part of the asthetic, in that case you're likely better off with full color spec, and yeah, it would be hard to convert from one workflow to another in that case.
Also gloss values are neither here nor there. All you will need to do is invert the content if using roughness (rough=white smooth=black) scale vs standard gloss scale (rough=black smooth=white), maybe throw a curve on it to account for the gloss curve of a particular shader model.
should also note, if you set that ini setting in your ue4 project and create content, then later want to switch back - a function will be added to your materials that will try to convert to a metalness workflow. It isn't perfect, but its pretty damn good.
Being a programmer, I only speak on a technical level
the metalness workflow isn't as easy to represent (or convert) odd values, however in reality those values don't show up too often.
That's where I beg to differ, or at least we seem to disagree on what "too often" is. As far as I could tell from reading posts here on Polycount and other places, one of the arguments often used by artists in favor of the "specular workflow" is precisely that you can setup materials which you can't with the "metallic workflow", even implausible/non physical ones if you want to. And because they can, you can be sure that some will.
From the game engine programmer point of vue (because that's what the discussion is originally about: whether Unity/Unreal should ship with both spec and metallic or choose either one), it's difficult to rely on an automated process to convert from "spec" to "metal" because there will be content that can not be converted and about which users will complain and file bug-reports about on a regular basis. And, as you probably know, the "it's not my program that's faulty, it's your assets" argument is not always taken very well by users. In that context, even every once in a while is "too often" in my opinion.
If you have a metal with like 80% reflectivity and its got a diffuse of 40%, you're just straight up breaking the laws of energy conservation, so again, its content that would be the problem there.
Usually, it's the shader that enforces energy conservation (Designer's one does, and AFAIK Marmoset's one does to). Users expect that it will, and they do complain if the engine does not render a plausible material when they provide it with 80% specular and 40% diffuse textures. You can't just tell them "fix your assets".
But that is not what I was talking about. There are also a whole lot of diffuse+specular combinations that respect energy conservation and yet are not reachable with the "metalness" workflow. An extreme example, admitedly "never seen in real life", would be diffuse=0,0,1 specular=1,1,0. There are of course less extreme and more plausible examples, but this one has the merit of being obvious to understand.
Again, some people advocating the "specular workflow" prefer it because they can use it to produce materials whose appearance fall outside of the simple "either metal or dielectric" classifications, like clothes with diffuse reflections and yet colored specular highlights, or translucent coating on metals, or subpixel mixes of metals and dielectrics. This is arguably a valid use and it is not a problem of calibration, or the users not understanding PBR. If the engine forbids them such use of the "specular workflow", it might as well just force them to use the metallic one, and provide separate shaders to address the other cases. Allowing for both would not be that empowering, and probably not worth the added confusion, maintenance costs, etc.
Also gloss values are neither here nor there.
I know that. I just used the "spec/glow" association as a name for the workflow, as a lot of people seem to do.
Being a programmer, I only speak on a technical level
That's where I beg to differ, or at least we seem to disagree on what "too often" is. As far as I could tell from reading posts here on Polycount and other places, one of the arguments often used by artists in favor of the "specular workflow" is precisely that you can setup materials which you can't with the "metallic workflow", even implausible/non physical ones if you want to. And because they can, you can be sure that some will.
Oh I do not disagreee that this is something people often say. What I do disagree with is the reality of the situation. IMO most people say this sort of thing because they do not understand how it works fully, much of these sort of statements that you hear are based on misconceptions. Rather than perpetuate the myth, I would like to at least attempt to improve access to information in this regard. On Polycount at least, people are generally very open to this sort of thing.
From the game engine programmer point of vue (because that's what the discussion is originally about: whether Unity/Unreal should ship with both spec and metallic or choose either one), it's difficult to rely on an automated process to convert from "spec" to "metal" because there will be content that can not be converted and about which users will complain and file bug-reports about on a regular basis. And, as you probably know, the "it's not my program that's faulty, it's your assets" argument is not always taken very well by users. In that context, even every once in a while is "too often" in my opinion.
Yes I agree that a conversion tool is prone to user error, and during the course of tech support you can't blame problems on the user, I understand thats not how it works. However, in an open discussion I feel its important to look at the root cause of the problem, not simply the symptoms. For reference, I started talking about this because you claimed it couldn't be done, which is simply patently false. It can be done, the degree to which it works reliably depends on the input art content.
Also, for the record, I am in favor of supporting both workflows. We do it in TB2 and it really isn't a big deal. Sure, you have more shader permutations, but this is only a big issue if your shader system is poorly optimized. For instance in Unity 4.X additional shader permutations would result in insanely long compile times with Skyshop, however it is my understanding that this is significantly improved in Unity 5 (though I could be wrong here, not really my area).
Also, I personally prefer working with the spec workflow, but more so because its something that I've used for 10 years so its second nature, and because of the artifacts that you will typically have at material transition points in the metalness workflow.
Usually, it's the shader that enforces energy conservation (Designer's one does, and AFAIK Marmoset's one does to).
Yes, we enforce reflectivity energy conservation in the shader as a fail safe. With logically set up materials it generally doesn't make much of difference though, you'll see the biggest difference when importing illogical values.
So if one of the argument for the specular workflow is "It allows me to use nonsense values that my shader will fix anyway", I don't think thats a good argument in any sense.
Users expect that it will, and they do complain if the engine does not render a plausible material when they provide it with 80% specular and 40% diffuse textures. You can't just tell them "fix your assets".
Yes, I agree, at least on a person to person basis you can't just tell people to fix their stuff, but I certainly will try to make a more overall effort to inform people. You can simply throw your hands in the air and say why bother, but I will not.
But that is not what I was talking about. There are also a whole lot of diffuse+specular combinations that respect energy conservation and yet are not reachable with the "metalness" workflow. An extreme example, admitedly "never seen in real life", would be diffuse=0,0,1 specular=1,1,0.
Right, so now we're using examples of materials that are possible with the spec workflow but impossible in reality, so again, this serves my general point. The cases where things would break is when they don't make sense in the first place.
There are of course less extreme and more plausible examples, but this one has the merit of being obvious to understand.
Again, some people advocating the "specular workflow" prefer it because they can use it to produce materials whose appearance fall outside of the simple "either metal or dielectric" classifications, like clothes with diffuse reflections and yet colored specular highlights, or translucent coating on metals, or subpixel mixes of metals and dielectrics. This is arguably a valid use and it is not a problem of calibration, or the users not understanding PBR.
For the most part we're talking about special purpose shaders now like cloth, hair, iridescent, car paint, etc, all of which you would be better off with a specialized BRDF and which won't look great simply using a full color specular input. But yes, if you don't have access to any specialized BRDFs, the full color specular workflow will get you a little closer to certain types of materials.
If the engine forbids them such use of the "specular workflow", it might as well just force them to use the metallic one, and provide separate shaders to address the other cases. Allowing for both would not be that empowering, and probably not worth the added confusion, maintenance costs, etc.
Meh, I think those concerns are overstated. We support both and our codebase has yet to explode. :poly142:
Spec or Metalness? How about we just call it "reflection"?
Maybe toss in some logically named settings tucked into it, to describe what they are.
Oh but wait we need to name settings after the people that worked on them: Euler, Fresnel, Catmull-Rom, Mitchell-Netrovali bla bla bla... Because, who really cares about clarity and being descriptive when you can attempt to immortalize yourself?
Diffuse, albedo, specularity, Metalness, Normal? Did people just put some "sort of related names" in a hat? Mind you I know most of the stories and logic behind most of these names but if you have the chance to straighten out the names and rebrand something why stick to the tradition of convoluting things?
So yea, lets forget metalness, forget specularity, call it what it is, reflection.
Oh and thank you to whoever named things logically like "Sub Surface Scattering" I may not know your name but I know what it does, so thanks.
@Earthquake: Honestly, I don't understand what we're arguing about anymore. We seem to agree at 99% and just bicker about details and out of context quotes. I'll just reply to this, which may be the root of our misunderstanding :
For reference, I started talking about this because you claimed it couldn't be done, which is simply patently false. It can be done, the degree to which it works reliably depends on the input art content.
For reference, I did not claim that it could not be done. I said "It's not easy because it does not work in all cases. Whether those cases are useful is debatable".
Replies
As for unity, I've always thought of the program as being about freedom for the user. As such, I'd prefer either specular workflow or both.
I've been warming to metalness recently, but I'm still not sure limiting everyone is the way to go.
"Note we are planning to support both, but we might only support one initially due to time and testing constraints."
Is it mix of specularity +reflection ? Is it a gloss or a term to determine the hardness/roughness of a surface?
Edit; ok I just read that. It's a workflow setup, not a map. I'm sorry, never used real time renderers bexcept zbrush.
hopefully i can clear it up a little further for you as well.
with PBR, there isn't really such a thing of specularity. i know you might think it's productive to think of specularity and reflection as two different things, but really they're the same.
so with that in mind, in PBR we try to refer to it as just "reflectivity". what you're controlling with your reflective input, whether it's through metalness or "specular" map, is the strength and colour of the reflection when fresnel is at zero (ie: when you're looking straight at it).
using a full colour reflection map input (or "specular"), it gives you access to the full range of reflective values for ALL materials that are being controlled by this map, regardless of their metallic state. what this typically means is that you'll be painting very dark grayscale values for non metals, with little variance and full colour bright values for metals in this map.
a metallic map kind of simplifies this workflow quite a bit, by letting you just have one colour map for everything, you paint your diffuse colours for non metals, and your reflection colours for metals all into the same map, and then use a black/white metallic mask to tell the shader "these bits are metal, so use this pixel value for reflection, and these bits are not so use them for diffuse, and assign them a reflective value of 0.04".
and that's that.
Older shaders would often have simple specular reflection from dynamic light sources, and then a single generic cubemap for ambient image based reflections. Because this cubemap didn't really match the scene, and often didn't match the microsurface (roughness or glossiness of the material), it often had separate paramaters entirely to control it in the scene.
These days we still have simple specular reflections from dynamic light sources, but IBL systems are way more advanced. Now the cube maps are actually rendered from the content in your scene, and the cubemap reflections are sharper or blurrier depending on your roughness/gloss map as well, so the entire system can be consolidated into one system, even though technically its still 2 or even 3 different functions (screen space reflections are often used on top of cube map reflections as they can be more accurate than pre-baked content for moving objects or objects that need inter-object reflection).
So what you end up with in a PBR system is basically all your light sources behave in a physically plausible way, so your inputs can be simplified.
The specular map and metalness map workflow are really just two different ways to pack the content that drives the lighting system, and both can give basically the same results.
because everything has fresnel and it's almost constant?
in vray i just turn off the fresnel parameter if i just want to see fully metallic object. and play around with roughness
+1
Just today I had to use specular instead of PBR because I couldn't get a good result. What would I do if it wasn't available to me ?
Specular workflow can still be PBR. There's nothing "more PBR" or "Less PBR" about Metalness or specular workflow.
Yeah you are right but I can never nailed it down with "specular PBR" . It alway feels "still not there" to me.
The best post I read today. LOL'ed heavily
MARK! where is that from? i remember watching it but i've never found it again.
What the hell did i just watch? :poly142:
first off, love the vid, that was great.
anyways, looks like metal has an overwhelming lead right now, with 5x the votes as spec, so hopefully when unity 5 comes out, it'll start with metal. because i hate spec.
I'd vote for both of course, but if you are gonna do one before the other, I'd think specular/glossiness would be the way to go.
and why would you hate it?
there's really no reason NOT to include both.
Tell that to Epic.
I actually see it the other way round : either way's fine, but why include both for a given engine ? And why make such a fuss about it ?
Which one u like to work with?
Black and white masking pipeline can reduce the amount of texture i use for complete map.
But traditional spec map workflow seems quite friendly when it ported to weaker devices or different platform. I know unity love this. But I could be wrong btw
I think they sshould use the specular workflow since if someone wants metalness they can easily just write a simple modification to the specular shader to start sampling reflectance from a static value or the albedo based on a mask.
Not sure if it is an option in the menus, but if you add:
[SystemSettings]
r.UseDiffuseSpecularMaterialInputs=True
to DefaultEngine.ini (of your project), you'll get the old Specular workflow in your materials.
Note that it is a different rendering path and some newer features will not function with it turned on (Subsurface Profiles may not work).
If you set it in BaseEngine.ini, it will break example content, and will break any content you've created in your current project using base/metallic inputs. Edit the inis in your project
It removes the Base and Metallic material inputs and replaces them with Diffuse and Specular.
I don't really recommend it, as I'm not sure how supported it will be, but if you want to use it - the option exists right now (and has since the launch of UE4)
Nope its easy to convert both ways actually. I'm working on a tutorial that explains how. =P
You'll get some slight variation doing the conversion, but nothing crazy. Also spec to metalness will give you vastly different results if your original spec content isn't properly calibrated (eg, implausible values).
Sorry if those images are confusing, I've got a bunch of text to go with it but its all still WIP.
substance designer does it afaik but I don't remember is it spec->metallnes or other way round.
Maybe once I have time I could make a simple little app that converts back and forward between the 2 workflows.
Yes and no. Mostly yes on a technical level, the metalness workflow isn't as easy to represent (or convert) odd values, however in reality those values don't show up too often. If you're seeing hugely different results with the spec vs metalness workflow, more than anything that is probably a sign that your content isn't authored in a logical manner, rather than any sort of technical restraint. In that case I would look into the root cause which is probably poorly calibrated content.
Nearly all non-metals have uncolored reflectivity in the 2-8% range, most around 4%, I really doubt that anyone would ever spot the difference between 4% or 6% reflectivity when viewing an asset in an actual game situation. Most of the surface variance comes from the gloss/roughness for non-metals. For metals, the albedo map works nearly identical to the standard specular map content, so all that variation can be added in the same typical way. You're locked to 0% diffuse, but again for an actual pure metal, the difference between 5% diffuse and 0% diffuse is going to be hard to spot. If you have a metal with like 80% reflectivity and its got a diffuse of 40%, you're just straight up breaking the laws of energy conservation, so again, its content that would be the problem there.
Now, maybe you're doing a NPR game or something and unrealistic materials values are part of the asthetic, in that case you're likely better off with full color spec, and yeah, it would be hard to convert from one workflow to another in that case.
Also gloss values are neither here nor there. All you will need to do is invert the content if using roughness (rough=white smooth=black) scale vs standard gloss scale (rough=black smooth=white), maybe throw a curve on it to account for the gloss curve of a particular shader model.
That's where I beg to differ, or at least we seem to disagree on what "too often" is. As far as I could tell from reading posts here on Polycount and other places, one of the arguments often used by artists in favor of the "specular workflow" is precisely that you can setup materials which you can't with the "metallic workflow", even implausible/non physical ones if you want to. And because they can, you can be sure that some will.
From the game engine programmer point of vue (because that's what the discussion is originally about: whether Unity/Unreal should ship with both spec and metallic or choose either one), it's difficult to rely on an automated process to convert from "spec" to "metal" because there will be content that can not be converted and about which users will complain and file bug-reports about on a regular basis. And, as you probably know, the "it's not my program that's faulty, it's your assets" argument is not always taken very well by users. In that context, even every once in a while is "too often" in my opinion.
Usually, it's the shader that enforces energy conservation (Designer's one does, and AFAIK Marmoset's one does to). Users expect that it will, and they do complain if the engine does not render a plausible material when they provide it with 80% specular and 40% diffuse textures. You can't just tell them "fix your assets".
But that is not what I was talking about. There are also a whole lot of diffuse+specular combinations that respect energy conservation and yet are not reachable with the "metalness" workflow. An extreme example, admitedly "never seen in real life", would be diffuse=0,0,1 specular=1,1,0. There are of course less extreme and more plausible examples, but this one has the merit of being obvious to understand.
Again, some people advocating the "specular workflow" prefer it because they can use it to produce materials whose appearance fall outside of the simple "either metal or dielectric" classifications, like clothes with diffuse reflections and yet colored specular highlights, or translucent coating on metals, or subpixel mixes of metals and dielectrics. This is arguably a valid use and it is not a problem of calibration, or the users not understanding PBR. If the engine forbids them such use of the "specular workflow", it might as well just force them to use the metallic one, and provide separate shaders to address the other cases. Allowing for both would not be that empowering, and probably not worth the added confusion, maintenance costs, etc.
I know that. I just used the "spec/glow" association as a name for the workflow, as a lot of people seem to do.
Oh I do not disagreee that this is something people often say. What I do disagree with is the reality of the situation. IMO most people say this sort of thing because they do not understand how it works fully, much of these sort of statements that you hear are based on misconceptions. Rather than perpetuate the myth, I would like to at least attempt to improve access to information in this regard. On Polycount at least, people are generally very open to this sort of thing.
Yes I agree that a conversion tool is prone to user error, and during the course of tech support you can't blame problems on the user, I understand thats not how it works. However, in an open discussion I feel its important to look at the root cause of the problem, not simply the symptoms. For reference, I started talking about this because you claimed it couldn't be done, which is simply patently false. It can be done, the degree to which it works reliably depends on the input art content.
Also, for the record, I am in favor of supporting both workflows. We do it in TB2 and it really isn't a big deal. Sure, you have more shader permutations, but this is only a big issue if your shader system is poorly optimized. For instance in Unity 4.X additional shader permutations would result in insanely long compile times with Skyshop, however it is my understanding that this is significantly improved in Unity 5 (though I could be wrong here, not really my area).
Also, I personally prefer working with the spec workflow, but more so because its something that I've used for 10 years so its second nature, and because of the artifacts that you will typically have at material transition points in the metalness workflow.
Yes, we enforce reflectivity energy conservation in the shader as a fail safe. With logically set up materials it generally doesn't make much of difference though, you'll see the biggest difference when importing illogical values.
So if one of the argument for the specular workflow is "It allows me to use nonsense values that my shader will fix anyway", I don't think thats a good argument in any sense.
Yes, I agree, at least on a person to person basis you can't just tell people to fix their stuff, but I certainly will try to make a more overall effort to inform people. You can simply throw your hands in the air and say why bother, but I will not.
Right, so now we're using examples of materials that are possible with the spec workflow but impossible in reality, so again, this serves my general point. The cases where things would break is when they don't make sense in the first place.
For the most part we're talking about special purpose shaders now like cloth, hair, iridescent, car paint, etc, all of which you would be better off with a specialized BRDF and which won't look great simply using a full color specular input. But yes, if you don't have access to any specialized BRDFs, the full color specular workflow will get you a little closer to certain types of materials.
Meh, I think those concerns are overstated. We support both and our codebase has yet to explode. :poly142:
Maybe toss in some logically named settings tucked into it, to describe what they are.
Oh but wait we need to name settings after the people that worked on them: Euler, Fresnel, Catmull-Rom, Mitchell-Netrovali bla bla bla... Because, who really cares about clarity and being descriptive when you can attempt to immortalize yourself?
Diffuse, albedo, specularity, Metalness, Normal? Did people just put some "sort of related names" in a hat? Mind you I know most of the stories and logic behind most of these names but if you have the chance to straighten out the names and rebrand something why stick to the tradition of convoluting things?
So yea, lets forget metalness, forget specularity, call it what it is, reflection.
Oh and thank you to whoever named things logically like "Sub Surface Scattering" I may not know your name but I know what it does, so thanks.