Physically accurate material values
polycounter lvl 12
Sorry if this was covered elsewhere already, I am very lazy and don't feel like looking.
I was just wondering, in my final push to even out any technical kinks in my work - do people use physically correct values for things like albedo/base color and roughnes? I am assuming a metallness workflow here, where specular/reflection intensity is taken care of automatically.
Let me provide a more specific example in case that doesn't make sense. Let's say I have a concrete slab I'm texturing. I set it a nonmetal, so the guesswork is taken out of the reflection intensity. Now, for the color, I pretty much guess what it should be based on how weathered it is, if there's any paint on it ,etc etc, ie i use my own creativity, and sort of 'guess' at what look I want. Same goes for the roughness, I think about where or not it's polished or rough/weathered, and come to a decision of the value range based on that + what looks cool in real-time preview.
Is this the "wrong", or rather, physically inaccurate way to go about this? Should I always be consulting some sort of chart for every value for every material? Does such a resource even exist? I've seen a couple PBR value charts but they don't contain that many variations of materials.
I keep seeing all these amazing looking materials/textures, and feel like maybe I am missing something with regard to using the 'correct' values, and that maybe I have been doing that wrong? (I know someone people are amazing at texturing, i'm ok at it, but for the sake of argument let's just say we're both using a flat concrete slab that doesn't involve any crazy texturing abilities, and theirs looks 'physically accurate' and mine less so).
I was just wondering, in my final push to even out any technical kinks in my work - do people use physically correct values for things like albedo/base color and roughnes? I am assuming a metallness workflow here, where specular/reflection intensity is taken care of automatically.
Let me provide a more specific example in case that doesn't make sense. Let's say I have a concrete slab I'm texturing. I set it a nonmetal, so the guesswork is taken out of the reflection intensity. Now, for the color, I pretty much guess what it should be based on how weathered it is, if there's any paint on it ,etc etc, ie i use my own creativity, and sort of 'guess' at what look I want. Same goes for the roughness, I think about where or not it's polished or rough/weathered, and come to a decision of the value range based on that + what looks cool in real-time preview.
Is this the "wrong", or rather, physically inaccurate way to go about this? Should I always be consulting some sort of chart for every value for every material? Does such a resource even exist? I've seen a couple PBR value charts but they don't contain that many variations of materials.
I keep seeing all these amazing looking materials/textures, and feel like maybe I am missing something with regard to using the 'correct' values, and that maybe I have been doing that wrong? (I know someone people are amazing at texturing, i'm ok at it, but for the sake of argument let's just say we're both using a flat concrete slab that doesn't involve any crazy texturing abilities, and theirs looks 'physically accurate' and mine less so).
Replies
But like, what I mean is, how do i determine the correct 'color' value for say, a painted metal, wouldn't it just be whatever color I want it to be then? Same goes for roughness, wouldn't it just be defined by how weathered or polished an object is, as there is no such thing as a universal roughness value for say, all plastics or concrete whatever. At least that's as far as I understand?
That said I don't think you're doing it "wrong" in terms of some absolute, but guesswork does undercut the whole PBR idea a bit.
This page gives some general guidelines as to values to stay near: https://docs.unrealengine.com/latest/INT/Engine/Rendering/Materials/PhysicallyBased/index.html
One useful reference chart: https://seblagarde.wordpress.com/2014/04/14/dontnod-physically-based-rendering-chart-for-unreal-engine-4/
Additional reference: https://seblagarde.wordpress.com/2011/08/17/feeding-a-physical-based-lighting-mode/
For a more technical background on the basis of the shading model being used currently read this: https://disney-animation.s3.amazonaws.com/library/s2012_pbs_disney_brdf_notes_v2.pdf
And the huge reference archive of actually scanned materials that the model is based on:
http://www.merl.com/brdf/
Here's a viewer: http://www.disneyanimation.com/technology/brdf.html
There are a ton of resources out there for establishing base values for materials, but even those sometimes won't be 100% perfect for your asset. You'll always have to adjust things.
Depending on the engine, it's more important to make sure you have specular in the right range and your maps are imported correctly as sRGB or Linear. And that your diffuse isn't pure black or pure white. Everything else are just guidelines.
Thanks for the resources! I was also curious, with regard to staying within the 'intensity levels' for certain values (ie albedo or roughness, again spec is out of the equation for now since we're assuming a metalness workflow at least as far as I wanna be concerned) , what exactly is meant by that, if I am working in photoshop? Like, say I have a roughness map with lots of variation, how do I determine that I am staying within the 'physically correct' value provided for that material? Is it just a question of clamping the texture image, or is it more complicated than that? Is there an easy way to tel what the value range is in my image? Do I use the histogram for that?
@leleuxart
Yeah that's actually more or less what I was thinking/seems like the common sense thing.
That was my point to begin with ,it seems like a weird thing to be like 'ok well what is the roughness for a piece of concrete that has been aged for this many years and has this exact amount of scratches on it' lol, it's part of the reason why the whole physically correct color/intensity value thing can confuse me.
The roughness range really matters actually. And yes it varies but not by a huge amount.
This isn't specifically roughness like "Its been scratched up", its roughness like, "Its molecular structure at the boundary between the atmosphere and the object is bumpy." IE a hand print on a piece of glass is "rougher" than the glass because the distribution of oil molecules is less regular than the polished glass surface.
Conversely a hand print on a rubber ball, or your keyboard plastic is less rough because the oil molecules fill the pores in the structure of the plastic or rubber and create a smoother surface coating.
All this stuff in PBR is really approximating microscopic photonics.
Albedo is quite literally the amount of incoming light reflected back out. We think of it as surface color, but its a physical property, which is why it has these guidelines of being less bright and less contrasty than you'd previously texture something. The moon has an albedo of I think 0.12 if I recall. That's nearly black in a texture, but the sun is just that bright. This is the physically correct shading we're working with now. Brighter lights, and actually calibrated energy reflectance.
Anything you texture bright and saturated isn't just brightly colored, its overly bright. A really good mirror would have an albedo of around 0.9. (IE 90%white.. or if the metalness workflow a 10% roughness value and a black color map and 100% metallic)
That said, if you're working in sRGB space ( you probably are) the colors aren't going to line up linearly, because sRGB is in gamma space.
So the easiest way to be sure you're working with realistic values, is to get a color chart, or a photo of a color chart under known conditions and work with that as a color reference.
TLDR: yes use the histogram. Yes there's some room for artistic interpretation. Keep your variations fairly small for any given material unless you have something in the material that is changing it significantly (Does your concrete have flecks of glass or polished gypsum in it so that it sparkles? The sparkles are smooth bits) Generally, err on the side of being too rough if you're going to experiment. You're likely to be closer on the rough end than on the smooth. Basically between 0.75 and 1 for anything that hasn't had some kind of polish applied on top.
Great posts by Vailias.
Also, another good rule of thumb is to consider your asset in game. If your values are too bright/dark, then this will multiple the value when the asset is under bright light or deep shadow.
I usually stay between around .2 and .8 for albedo. Sometimes I just colour pick from google images of what I'm creating and maybe tweak the HSV until I'm happy. Don't get caught up in the science too much. After all, this is art we're supposed to be creating:)
EDIT: Plus the whole headache of texturing in marmoset (which i use before getting stuff into engine), so I'm going photoshop > marmo > then Unreal, so I don't know what the deal is with how each one reads roughness maps in terms of the color space and how to ensure a consistent result across the board. Oh, and figuring out how take roughness of 0-1 range and map into 0-256 or whatever photoshop values are.
@musashidan : hmm isn't color picking from google images technically a bad idea cause you don't know what lighting conditions the image was taken in/how much reflections are hitting it and thus you'd be starting out with a base that is physically incorrect?
The quick and dirty of it is: its an encoding scheme to make images look right on CRT monitors or old TVs. Its been around long enough that its a standard, so that even new displays calibrate to the standard, so we keep a consistent look across all media. If you capture linear values from a scene, making your white point 1 and your black point 0 then take all the values inbetween to the power of 2.2 you'll get the sRGB values.
You can simulate what this does to values in a photoshop curves operation where you pull the center point down from 0.5 to 0.21. If you do this you'll see that the image overall gets darker through the midrange, but also gains a higher contrast.
The reasons behind this are a combination of human perception and display technology when it was developed. The reason its important to us on this forum NOW is because we're doing lighting simulation in linear space, so we need to convert the colors back from display space (sRGB) to real space (linear). This shouldn't matter a huge amount to you as an artist, as the engine should handle the transform for you, but it IS important to be aware that some maps should not and will not use the sRGB transform such as Normal maps and other maps of data rather than perceptual color. For these you want to read the raw data values because they're already linear.
Photoshop also has a zero to one range. The reason for the values being 0-255 is bit depth. Your normal images are 8 bits per channel. (2^8 is 256) So you can (and probably should) get good at knowing the ranges (value/255 = value in 0-1 space ) or you can use the photoshop info box and set the RGB mode to 32bit. (upper left eyedropper tool has a dropdown arrow) This will give you a 0-1 readout without changing your bit depth.
You can also change this to HSB space, which will give you a direct % brightness value even in color images, which is helpful for the above mentioned albedo ranges.
Roughness maps are data images, so they should be read in linear space. I'd suggest, rather than using Marmoset as an intermediate step, that you set up your assets in Unreal and just work directly there. Marmoset is a fantastic piece of software, but if its not your end target, then you're just adding time and possibly introducing errors to your work when you correct for the look of something that works differently in your end engine.
Re: colorpicking from google images. Technically speaking: yes this can be error prone. However, its much much better than just winging it. You need some kind of reference, and unless you're a very experienced artist, you're likely to miss the nuance of colors in many materials. You can also make an educated guess about what the environmental conditions your reference photo is in. If you are painting in a 3d paint program like Substance Painter, or 3d Coat (or others I'm sure) you can load in a similar light environment to check against. So you can use found photographic reference, but you also want to keep in mind what you're doing and what your target is, so you can correct from your reference to something reasonable.
This is the artistic component. We're doing real simulation, but our bar for passing work is believably.
Not gonna lie, still confused about most of the sRGB/linear stuff, but the whole data maps vs. perceptual color does make sense to me, so for now I'll just stick to paying attention to that.
As far as using Marmoset, that's an interesting issue.. I'm really used to it, and I like the instant feedback when iterating on more complex textures. Although, do you know if unreal has a some sort of auto-reload function for textures like that? I doubt it, since the textures are stored as an embedded part of the project after they are imported, rather than being referenced as external files? It is annoying having to correct stuff when I get into unreal from marmo, I assumed since it had a 'unreal preset' material type, it was calibrated to accurately reflect the final result I'd get in Unreal, but I guess not, since I've found myself having to correct stuff a ton of times once I got it into unreal....
Anyways, this also reminds me -- are we expected to use values for light brightness, that are within a certain range, in order for textures to look right? Like, is there a 'physically correct' range of intensity for lights in Unreal? Does that matter?
For basic info on lights etc in unreal, check here: https://docs.unrealengine.com/latest/INT/Engine/Rendering/LightingAndShadows/Basics/index.html
It gets to the heart of what PBR actually is. The lights in a PBR renderer must also be physically simulated. The values in unreal for point lights and spotlights are chosen to be the standard unit of Lumens. 1700 lumens is about equal to a 100 watt bulb.
Sunlight is just incredibly bright by comparison. Its also a bit different in that its best simulated by a directional light.
A quick web search shows that noon sunlight has a brightness of 98000 lumens per square meter.
So if you're doing outdoor scenes, just go by eye and go brighter on the lights than you think you need. Look at some of the examples provided by Epic in their learning resources section of the launcher.
The tonemapper in the camera should help keep the dynamic range suitable for display on your screen, so don't worry too much about blowout.
For indoor stuff, light it like you would in the real world. Find some values for lights that would likely be in your scene, and place the appropriately.
Lighting in general can be open ended because it all depends on the project and style, but your textures don't necessarily rely on the lighting for them to be accurate. They're accurate in the sense of how they interact with [any] light based on the material setup, and that's based on the renderer itself.
Both CryEngine and Unreal have a debugger that shows you the Luminance of a scene. Combining that measurement and targeting real-world Luminances with proper Kelvin temperatures, you can get something fairly accurate, although the in-engine tonemapper and post-process tools will affect the final look since they aren't affected by the debugger. But it's a good start if you're interested in physically-plausible lighting as well.
And I guess the scale of the lighting is based on the 96 or whatever it is player height, as a point of reference? Since obviously a light of the same intensity would have a different effect on a stadium vs like the inside of a fridge.
I've been messing around with the Static Level Lighting Scale value (among others) in lightmass - it seems like decreasing it gives very nice looking results, since the light is calculated at a more detailed resolution, but does this mess up the 'physical correctness' of the lighting in the scene?
Light decays via the 1/distance^2 like in real life.
Stadium lights are like 50-60 thousand lumens. A fridge light is under 300.
If you happen to have a fridge in a stadium, just make the internal light level 300, and the spot lights in the stadium 55000 each, and you should have a good baseline for real world values.
The static lighting level scale is more of a quality/time tradeoff setting. It doesn't affect the physical correctness, so much as how often the calculations are done across a surface. Basically its a detail slider with lower levels adding more detail at the cost of much more calculation. That's definitely an "up to your discretion" setting.