Why so blue?

[EarthQuake]

Alright, so most people have seen or created specular maps that have prominent blue colors in them, for various effects, but it seems many do no actually understand why we do this.

I've had a few discussions with programmers about this from time to time, because they never seem to understand why we would want anything but grayscale, so i figured i would give a few examples here and try to open up some discussion about colored spec in general. Generally these discussions end in the programmer telling me something about gamma which i dont really understand.

Now the most common use most people will say, is use blue for specular in your character textures. What they really mean is use the inverse color of your diffuse for your specular. Why do we do this? Its simple, adding light on top of a tan/brownish color is going to give you nasty yellow highlights.

You can see clearly in this image what i mean:

http://johnyontehspot.com/pix/blueee.jpg

Specular in most 3d engines is done additively, so we can sort of test this out in photoshop.

The top two images are blue(left) and gray(right) using the normal blend mode in PS.

The bottom two images are the same, but using additive. You see how the gray image actually turns yellow, while the blue is a much cleaner near-white result. Its worth noting that if your additive color(spec color)
is bright enough, your end result is always going to be white, but the gradient to that point may still be yellow, and if the case of skin, you want very minimal specular reflection generally, so you wont have a very high spec value.

http://johnyontehspot.com/pix/fingerslol.jpg
You can see in this ref here(my fingers lololol) that the highlight is more of a clean white than anything else, if you colorpick it, its a slight pink, but a quick look gives you the distinct impression of "white" more so than a yellow or red or anything else. Even in areas where the highlight is quite faint, its still distinctly white.

So when the goal is to get nice clean white highlights, it helps to use the inverse color of your diffuse.

Another good example that pretty much follows the same exact theory and usage is lacquered wood, the shiny wood you would see on the stock of a rifle for instance, tends to be a clean white or even bluish highlight in some cases. One of my biggest pet peeves is seeing people use grey, or even worse a yellow/brown spec color for wood, it just looks *terrible*.

here are some examples of what i mean:

http://i25.tinypic.com/1dypnt.jpg
http://www.fortunecity.com/olympia/kickbox/377/b19/b19stock1.jpg


Some other good uses for color in your specular are:

Bronze/Gold

Its good to have more of an orange/brown color in the diffuse, and a yellow/greenish color in the spec, to get this sort of effect:
http://farm3.static.flickr.com/2275/2489931647_88fb822b32.jpg

Certain materials like christmas ornaments, or certain cloth(like satin) or types of plastic you may want to push the color of the diffuse into the spec to get an even more saturated highlight:
http://2.bp.blogspot.com/_pQZf3-JFkdM/SU3g3UdxdDI/AAAAAAAAAFI/6mhVRbAtD_4/s400/christmas_ornaments.jpg

[Mechadus]

Wow, thanks EQ - very handy reference thread. Looks like you need to use a higher rez image for your kitchen floor tho - shits blurry! :P

I learned something very much like this in HS physics which I use sometimes in spec maps... Basically invert the diffuse color to simulate how colored light is reflected off an object, thus canceling out 'wrong' colors.. Is this a good rule of thumb for in engine textures, or is this mostly a 3d animation trick? Just wondering because I also only really ever have seen blue on spec maps in my limited experience.

-N!

[EarthQuake]

Well the general rule here, is that if you want a less saturated highlight, use the inverse color, and if you what a more saturated highlight, use the same color. How you actually apply that is very specific to what material you're trying to create.

[monkeyscience]

There may be something to your first diagram EQ. IRL specular hilights aren't exactly additive because if incident light hits the oily surface on the skin and bounces right off, it will not illuminate the yellowish, diffuse flab underneath. Really the equation becomes SPEC + (1-SPEC)*DIFFUSE. Adding some inverse diffuse color to the spec map probably approximates this.

Also the light source in the photo is not white, its blue, check out the "white" kitchen floor.

[EarthQuake]

The shot was taken with natural, overcast lighting, which is about as neutral as i think its going to get. And how dare you call my floor white, you racist. While i'm sure there is a little blue being added from the sky, i dont think its a very large amount.

[jocose]

This is really informative. Thanks a lot EQ.

[SideEffect]

Thanks!

[EarthQuake]

ok white balanced on my camera to be as accurate to what the floor actually looks like(slight yellow/offwhite color) and a darker exposure to see the detail a bit more clearly. I think this still paints the same picture, spec = clean white. =)
http://johnyontehspot.com/pix/fingerslol2.jpg

[oXYnary]

EQ, if your engine only allows greyscale specs in a alpha. But you can set the color of the spec via umm whats it called. Not CMYK, the 4 numeric system manually in the shader setup. Will this still help? As per since the spec color wont change, and if the texture is across multiple surface types.

I mean is there a neutral value? Or should I make a copy of the final texture with a average blur filter to see what the most prevalent color is and make the 4 digit the opposite of that?

[warby]

this is great information i was often wondering why the blue .... however:

lets not forget than if you use a grey scale specular mask you can get away with just "1" channel !!! j
ust stash the spec mask into the alpha channel of your normal map or defuse map.
if 99% of the shaders in your game use specular masks than that is a HUGE amount of texture memory !
that slight color difference, that is going to get raped by all the bloom and color correction post filters anyway, might not matter that much compared to texture variety and resolution!

[MoP]

warby, actually in general if you put a specular mask into the alpha then you're not saving memory at all, in most common cases.
Since DXT1 (3 channels) is half the size of DXT5 (4 channels), so you might as well have two DXT1 textures instead of a single DXT5, it adds up to the same amount of texture memory at runtime and you get colour for "free" in your specular.

[EarthQuake]

warby, actually in general if you put a specular mask into the alpha then you're not saving memory at all, in most common cases.
Since DXT1 (3 channels) is half the size of DXT5 (4 channels), so you might as well have two DXT1 textures instead of a single DXT5, it adds up to the same amount of texture memory at runtime and you get colour for "free" in your specular.

Absolutely.

Also i've been told that a single8 bit image cannot be compressed by the graphics card, so while your grayscale spec map is 1/2 the size of your rgb map, compressed that rgb map is 1/4th the size. Thus actually being MORE expensive to use grayscale spec on its own.

[EarthQuake]

EQ, if your engine only allows greyscale specs in a alpha. But you can set the color of the spec via umm whats it called. Not CMYK, the 4 numeric system manually in the shader setup. Will this still help? As per since the spec color wont change, and if the texture is across multiple surface types.

I mean is there a neutral value? Or should I make a copy of the final texture with a average blur filter to see what the most prevalent color is and make the 4 digit the opposite of that?

I'm not exactly sure what your asking here, seems you may be thinking a bit too hard about it? =D

If you HAVE to use grayscale, its good if your shader supports and RGB value to tint the entire image, you'll just have to tweak this until you get a good result, because you may be balancing flesh and non flesh in the same image.

[perna]

ok: If you want to play with fancy shader stuff you can have the value in one channel and the saturation in the other and calculate opposite colors automatically in the shader. This would work well in most cases as there's rarely much need to actually paint "color" (as opposed to the saturation value for the highlight) into spec maps.

EQ, how did you get people to respond positively to this message? Whenever I have brought this up the last 12-13 years people tend to go apeshit and talk about how spec color is related to the blue sky or some lameness, usually backing it up with photographic "evidence"

[jeffdr]

Really the equation becomes SPEC + (1-SPEC)*DIFFUSE
This is not correct, though it sort of is in spirit. The actual relationship is more complicated, as it depends on the incident angle of the light source. You can have for example angles where the viewer sees no specular, but the surface is reflecting a lot of light specularly, the result being dark diffuse but no visible spec. tl;dr - this equation is wrong, don't use it.

Also fwiw I don't buy that the artists are just trying to emulate blue light by putting blue in the spec maps, I think they are actually on to something here, a flaw in gamma correction or the RGB color model or some other technical wankery.

Also mechadus: you learned this in physics class?? If you know a physical basis for the phenomenon, then do share it please!

[Ruz]

so I suppose that you would vary the spec colour a little ie slightly warmer colour for the lips.
I personally found that it hard to avoid it looking like you painted the model with inks if you have too much color in the spec.
it can look quite saturated I mean.

If you haven't got a good grasp of warm and cool colors it can be a bit tricky to get your head around

whilst testing I mainly use a grayscale spec.

The idea for a blue spec may have come from the color of jacks lips in titanic:)

[Ben Apuna]

Great thread EarthQuake! Finally someone put all this specular color info into a concise post. I knew about the invert color for skin from a previous polycount thread but now it all makes sense, thank you very much :)

[warby]

warby, actually in general if you put a specular mask into the alpha then you're not saving memory at all, in most common cases.
Since DXT1 (3 channels) is half the size of DXT5 (4 channels), so you might as well have two DXT1 textures instead of a single DXT5, it adds up to the same amount of texture memory at runtime and you get colour for "free" in your specular.



hmmmm now that IS interesting ...

the truth is i take the memory efficiency thing so far i usually just use a channel from the dxt1 - diffuse texture do some contrast adjustments in the material/shader and hook that into the specular mask.

because thats what most environment artists do anyway ... just taking the diffuse photo of a wall in photoshop and turning the contrast way up to make the spec mask and than call it a day ...

[Bal]

Very interesting thread guys, and yeah I often heard the "use blue cause of the sky" explanation, which always sounded kind of silly.

Sorry to go off topic a bit, but to come back to what warby and MoP are saying :
Why is DXT5 2x times larger than DXT1 if it only has an additional channel?
And I guess another advantage to just using grayscale specular, is even if you're using 2 DXT1 textures, you can use the 2 other channels of the specular texture for stuff like gloss and reflection maps (or even apha, to avoid using a DXT5 on the diffuse texture).

[CrazyButcher]

why is dxt5 2x times larger?

http://en.wikipedia.org/wiki/S3_Texture_Compression
btw for normalmaps dxt1 is rather sucky quality, best quality is a swizzled dxt5. (and ofc 3dc)

[warby]

so you get something for your money with dxt 5 right ???
dxt5s usually look less altered than dxt1 textures !? ( haven't used one in ages)

[GCMP]

so you get something for your money with dxt 5 right ???
dxt5s usually look less altered than dxt1 textures !? ( haven't used one in ages)

Sorry to jump in on your discussion but I used quite a few of these in conjunction with nvidia's direct x toolkit, simPE and Sims 2 engine. Yes DXT1 was poorish quality, DXT3 was the ideal 24bit solution that saved the intended quality and DXT5 is 32 bit with an alpha channel which I was warned about not to use unless my texture had an alpha included because this format is double the memory of DXT3!

[CrazyButcher]

dxt3 and dxt5 are same size. just look at the wiki link has the details. [if an admin can do, we might want to break the trheads into two, splitting away the compression stuff]

[GCMP]

That's strange, it was definately double the size after x conversion from tga inside the game editor as I extracted the textures to compare the dxt3 and dxt5 formats. This must be specific to the editor I was using, so if you use no alpha information in your dxt5 in some other editor the file size remains the same? Information noted:thumbup:

[demoncage]

I remember talking to my bro about this cause I didn't see the point. He brought up using it as a hack to get the superficial sss effect, which made sense to me. So I can see on stuff like skin or other materials with noticeable translucency that it could be effective but not a huge difference.

But on everything else it seems like the additive effect is mimicing what you see on real world objects, and with the degree of specular control you can get w/ different maps, I'm not sure I see the returns in spending alot of time on color values. But whatever works for the indivdual artist.

I know one horrendous experience I had, the client wanted me to not only tint the spec in a certain way on every material, but also to hand paint complex spec maps with stagnant hilights and duplicate that map for falloff control. Tell me how that makes ANY sense.

using areas of grey for both strength and falloff looked great in the engine to me...

[jeffdr]

DXT1 and DXT5 compress color in the exact same way; you won't see a quality difference for color data by switching between the two. DXT5 is bigger because it also holds alpha channel information, while DXT1 essentially does not (tho there are ways to use DXT1 and get a single bit of alpha, 0 or 1, by sacrificing a little color precision, but this is rarely done afaik).

[EarthQuake]

Very interesting thread guys, and yeah I often heard the "use blue cause of the sky" explanation, which always sounded kind of silly.



Just to touch on a specific point here a bit. Not responding specifically to your comment, it just reminded me.

Generally if you can do it, its best to create your assets with a neutral lighting environment, something without a whole lot of color, but still representational of your game engine. Unless of course you know with certainty that the sky/lighting will always be the same color. The problem you get into is that you're color correcting for whatever environment you are previewing textures, and then in another environment stuff falls apart. Its important to let the lighting add the sky ambient/sun color to your assets(if you lighting system has those sort of things, of course).

We had this problem quite a bit on darkest of days, where our artists would create content for the default sky that is loaded, make it look good, but then when its loaded up in a level with a different sky, its all whacked out(too much contrast, too little, crazy spec colors, etc).

Other things like previewing your textures in anything other than your game engine, or a shader synced up to your engine's lighting in your 3d app of choice should be avoided at all costs as well. Especially if you have a really simple point light shader that you're texturing with in max, and then throwing that content into a nice engine with fancy image based lighting. You really need to texture to the specs of the engine you're using.

[jeffdr]

Ok, so after poking around and doing some reading and thinking on the problem, I'm starting to think my initial guess was right - that this is an issue of gamma correction. This means two things:

#1 - You artist types arent just smoking crack or anything :P In fact actually whoever originally picked up on the whole "use a cool spec map on warm materials" approach was pretty observant.

#2 - This is something a programmer can fix for you. The root of the problem has to do with the assumptions made about texture inputs for lighting and compositing done by the author of your game, or your art tool.

The problem is in fact quite widespread - many game engines and many art tools (like Photoshop) and even offline renderers (Max, Maya, others) have this problem, at least in their default configurations. I know the renderer I wrote (the one that drives Toolbag) has this problem too, because we stumbled on it too late in our project to fix it. So what's the deal, you ask?

A bit of science first. A dielectric material (a non-conductive material), will not reflect light differently for different wavelengths. Examples of dielectric materials are wood, rock, dirt, skin, water, glass, and polymers such as plastic. Pretty much everything except for metal. This is not to say they don't diffuse light differently (clearly they do, they vary in color obviously!), but the actual reflection ("specularity") of light is not tinted. That is to say nearly everything you see IRL on a day to day basis has a white or at least grayscale spec map. Yes, really.

So what's with all the colored spec maps out there? It was this question, paired with EQ's detailed examples, that got me thinking on this in the first place.

The answer I think is gamma correction of input textures as well as the final displayed image. Adding two uncorrected images together doesn't work properly, and most importantly CAN ALTER THE HUE OF THE RESULT. What you'd expect if you added say, white to brown, is a less saturated brown. What you'd get instead without gamma correction would be sort of ass yellow/orange - *exactly* the kind of problem people are trying to get around by tinting their spec maps.

Gamma correction is a mostly mathematical topic that I won't go into in detail here, but all of you who want to understand should at least skim through this article on the subject:

http://http.developer.nvidia.com/GPUGems3/gpugems3_ch24.html

Note in particular figure 24-5, that's about the most obvious example of improper gamma correction I've ever seen. If you've ever seen one of your models start to look like (b), when you really wanted (a), this is probably why. To be clear: the problem is purely technical, and very widespread. Tinting of spec maps is merely a workaround - properly addressing gamma on the rendering side will resolve this artifact and many others to boot.

Other symptoms include artifacts with lighting, with generating mipmaps, with compositing of all kinds (such as adding spec on top of diffuse), and bad alpha blending. Basically everything goes just a little bit wrong. It can be hard to spot in most cases.

As an example, for lighting, the process should be:

(1) gamma correct the input textures
(2) perform lighting calculation
(3) un-gamma correct the result for proper display

Often when people get it wrong, they leave off steps 1 and 3. Steps 1 and 3 mostly cancel each other out, but not completely, so it can be hard to notice in many instances when it's off.

I hope this makes at least some sense, and that everyone goes forth today with a better understanding of their tools and their work.

Cheers,

Jeff

[EarthQuake]

Just posting some of the images from that article

http://http.developer.nvidia.com/GPUGems3/elementLinks/24fig04.jpg
http://http.developer.nvidia.com/GPUGems3/elementLinks/24fig05.jpg

[00Zero]

thanks for taking the time to write this up guys. learned a lot.

[SHEPEIRO]

mmm most interesting, my weekend addled brains finding it a little difficult to assimilate though, isnt a screen gamma correctionx2 much more expensive than tweaking the colours of the specular, how much more accurate would it be to do it like this?

[EarthQuake]

Well apparently OGL and DX9 both have functions to do this for free, or so i've been told.

[glib]

So am I reading this right, that colored specs are just trying to cover for issues caused by bad rendering?

[EarthQuake]

Not in all cases, but potentially some, yes.

Some materials really do need a different spec color to represent properly.

[EarthQuake]

Just to touch on some of this compression stuff a bit more, so we've come to the conclusion that using a greyscale spec, either in the alpha or as a separate image doesnt actually save you any memory.

So why would anyone want to do it?

Well there are a couple reasons:

1. In terms of performance, grabing a texture from the alpha channel is going to be quicker, and result in a simplier shader(code wise). This may have barely any effect on 1 mesh, but if you use the same shader for virtually every mesh in the game, it could have a decent hit on performance. I also think that you can squeeze in more inputs by throwing stuff into alphas, because each card has a set # of texture calls it can do, or something of that nature. Also, if you're working with older hardware, it may be your only option, because of the texture call thing.

2. If your game uses uncompressed textures, then you actually will see some memory savings for sticking things in the alpha, or saving as 8 bit images.

3. Just good old fashion miss-information. =)

[jeffdr]

EQ has asked me to lay some programmer shit on you guys regarding texture storage in real time renderers, so here goes.

Some common textures formats:


DXT1: 4 bits per pixel, typically RGB only
DXT5: 8 bits per pixel (4 for color and 4 for alpha)
L8: 8 bits per pixel, uncompressed grayscale
R8G8B8: in theory 24 bits per pixel, but often stored to use 32 bits for memory alignment reasons
R8G8B8A8: full 32 bits per pixel, with alpha channel

There are of course many more formats than these 5, but these are the "all stars" so to speak; a vast majority of texture data is stored in one of these layouts. So these are the typical puzzle pieces we have to work with when deciding what textures to put where, how to arrange data, etc.

From these numbers you can see that using for example a dxt5 texture is going to take up twice the space as a dxt1, and all you get in the trade is a low precision alpha channel. In terms of quality it may be slightly better to use two dxt1 images (I'll leave that to you to judge), which would be equivalent in terms of space. Plus then you can use color.

You'll also notice that an uncompressed grayscale image takes the same amount of space as a compressed RGBA image in dxt5 format. Take from that what you will.

Also worth noting is that the 24bit RGB format is often stored as 32bit with an unused alpha channel (for purely technical reasons), and so if you are using uncompressed textures often that alpha channel is totally free - the memory is already used so you can go ahead and drop stuff in there at no cost (except maybe disk space / load time).

Now with all that said, it is still possibly in your interest to use as few textures as possible. If you have two shaders that are equivalent, and one uses say 4 textures when the other version uses 3, your programmers are probably going to tell you that the version using 3 is preferable. There are two reasons for this:


Driver overhead. It takes some time and work on the CPU to switch textures, or to ready them for use. This overhead is small, and the guys at ATI/NVIDIA et al take great pains to minimize it, but it is still there. So you will lose a bit of CPU time using more textures. This varies only with the number of textures, not their size or format.
Rendering cost. The more textures your graphics card has to sample, the slower it will render. The cost is again not drastic, but it is measurable in many cases. If you have a shader that uses *lots* of textures (in DoD we have one that uses 14!), this cost can really start to build. So this is a drain on the GPU. This cost does vary with the size of the textures.

So this is just sort of a technical overview; you will have to decide based on your tools/pipeline/goals (and programmer skill :P) what works best for you.

Jeff

[Bal]

Good info guys, thanks for sharing this.

[glib]

Just to touch on some of this compression stuff a bit more, so we've come to the conclusion that using a greyscale spec, either in the alpha or as a separate image doesnt actually save you any memory.

So why would anyone want to do it?

Well there are a couple reasons:

1. In terms of performance, grabing a texture from the alpha channel is going to be quicker, and result in a simplier shader(code wise). This may have barely any effect on 1 mesh, but if you use the same shader for virtually every mesh in the game, it could have a decent hit on performance. I also think that you can squeeze in more inputs by throwing stuff into alphas, because each card has a set # of texture calls it can do, or something of that nature. Also, if you're working with older hardware, it may be your only option, because of the texture call thing.

2. If your game uses uncompressed textures, then you actually will see some memory savings for sticking things in the alpha, or saving as 8 bit images.

3. Just good old fashion miss-information. =)

4. There's a reason to use a 1-bit spec in your scene, or perhaps a mask for reflection or something else. In this case, dropping it into a DXT1 compressed texture is (AFAIK) free.

[Whargoul]

I was reading through the thread, writing up my response in my head, thinking all about gamma-correct lighting and dielectric materials, and lo and behold jeffdr posts it for me :)

But yeah, to reiterate: the bad tinting you get with a neutral coloured spec is due to doing your lighting in a non-gamma corrected way. Get your render engine modified do it right (be prepared to redo all the lighting though...). You can still get colour shifting though - due to clipping. Even if you are rendering HDR, when you bring your colours back to LDR space - some channels may clip before other ones do - leading to a colour shift. This is a nasty one, and tough to get rid off with a nice visual quality.

Specular highlights should always be the colour of the input light source (since it is really a reflection of that light source) unless it is a specific type of metallic object, in which case the surface tints it accordingly (ie gold really does have gold-tinted highlights).

Another reason to use greyscale spec maps is that they can be packed together in a single texture with other single channel maps. Yes, adding them to the alpha is a sucky way to do it since you are effectively doubling the memory. If you have 3 maps, each with an alpha channel, you can rip those alphas out, pack them together, and have 4 maps total which uses 2/3's the memory of the 3 with alpha. But one reason to leave it in the alpha is due to sampler input limits on some hardware, ie it can only access 8 maps at a time so then leaving it in the alpha has a benefit. And as jeffdr said, less textures = better performance.

In our current engine, it renders gamma correct so we have no tinting problems, except for the very bright clipping problem at the moment. We pack our greyscale specular map, specular power (also called eccentricity, gloss, roughness, etc), and ambient occlusion into a single map - so base shaders use difffuse, normal and the packed map - we also have an RGB value per material for globally tinting the spec highlight for special surfaces. I am not currently tinting the spec very often, and certainly not using blue on the skin, as it had the effect of making the skin too cold and harsh, neutral was making it softer. Of course, the fast SSS fake helps warm it up as well.

14 textures on one object? heh, I had one using 22 textures :) Although some of those are "system" textures like the shadow map, env map, noise maps that all shaders share, but yeah it was crazy. Ran on PC & 360 no problem, but the PS3 choked because of sampler limits (I think only 16?). Anyways, it was a pre-pro shader and ended up being cleaned up - to 16 exactly.

[EarthQuake]

Just curious, why are you loading AO as a separate image and not baked into the diffuse/spec?

[MattBush]

Realistically the AO should not affect direct light sources, only ambient light, and diffused ambient reflections.

See this quality ms paint diagram:

http://decaysoftware.com/personal/images/polycount/aodiagram.png
Notice how direct light and specular reflections are only affected by the amount the sample is in shadow from the direct light source, and not by any global/ambient function.

What I do, is use the AO to modulate the ambient light (from an ambient cube/light probe), then for reflections, use the gloss map to select the mip level of the reflection cube and modulate the reflections with the AO more/less according to how glossy the sample is. So more diffused reflections get affected by the AO more than glossy ones.
And that is the extent to which the AO should be used in my opinion.

You may of course prefer the look of AO in the diffuse and spec, but it's something to consider.

Also, hi!

[Brice Vandemoortele]

Hi mattbush, welcome and thx for those explanations :)
It reminds me of talks around the SSAO buzz: most studios use it as a post process multiplied on top of the whole back buffer. Some studios on the other hand choose to output the ssao in a texture in screenspace sampled by the shaders only to be used to modulate the ambient lighting contribution (i think i read that about crysis but i might be wrong).
I had the same experience not so long ago when using ao maps on a separate uv set. Even when gamma corrected, the specular looks pretty wrong when it's multiplied by ao.
(glad to see other people use glossy cubemaps :P, interesing use of ao AND specPow)

[MoP]

EQ: Yeah, if you multiply AO into diffuse then it will always shadow even if the surface is lit by a direct light (which doesn't happen in reality) ... it's called "ambient occlusion" for a reason!

If you have it as a separate map then you can actually use it in a more correct way - only multiply if not affected by direct light (or maybe a range of values to multiply so a strong light source will completely blast away the AO while a weaker light source will show the AO through a bit).

Obviously this is more expensive in terms of texture memory and shader complexity though, which is why most people don't do it currently. I imagine it will become more common as hardware gets more powerful.

MattBush: Thanks for posting, interesting stuff! I never considered using the gloss to select the cubemap mip level, that's pretty cool.

[fly_soup]

This information is really neat. This might be a really silly question, but is proper gamma correction something that an artist can accomplish in a shader, or is it the kind of thing that would be hard-coded into the rendering engine?

Also, somewhat relatedly (though this is probably a little subjective, and probably even sillier of a question), if it can be done with a shader, reducing/eliminating the need for colored specs on most materials, would it be a safe bet to go that route for portfolio pieces or would it be better to do it the other way so it's clear one knows how to do it? Or would it even matter much either way? I guess it's minor, but I'm just trying to get an idea so I can do whatever's likely to be more well-received. Like, if it was gamma-corrected and it rendered well using grayscale spec for human skin, is that something that, in an applicant with no experience, would look cool for being tech-savvy, or would it just be taken as "not knowing to make them blue" or something?

[Whargoul]

Yeah, what those guys said. I use the AO in many ways:
*full strength vs ambient light (duh)
*maybe %20 or so vs direct lights (still adds a bit of shading, without looking like a big multiply)
*contasted & brightened vs reflections (kill refs in dark spots)
*same again with different params vs ambient specular (helps weaken bright spec from sky, etc)

Shader complexity is pretty minor, a couple lerps, multiplies and adds. Packing the values together and doing fancy math is they key :)

Yes, do NOT use SSAO as a full screen multiply - yuck. That's as bad as doing a full screen multiply of your shadow map!

Our current AO is a combination of a few things, like geometry baked AO, screen space AO, textural AO, etc.

[EarthQuake]

My biggest concern is that for certain materials, flesh for instance, you dont want to have grayscale AO multiplied on, you want a more saturated pink sort of color. But maybe this too would be improved with proper gamma correction?

And as far as personal preference, i think it helps to make what are generally flat surfaces with much more detail normal mapped onto them, pop out more and look better to have that ao baked into the diff/spec. That said i havent really seen any examples of what you guys are talking about here either. At first glance i would see having it in a separate map with a custom shader benifiting lightmaps on large environment pieces moreso than unique AO baked from the highres for characters and props, but what do i know.

Anyone have some realworld examples?

[Whargoul]

Well it doesn't look bad on skin because it's not multiplied on at any time, it just removes light.

[MoP]

Yeah I think we will always need to keep the AO baked into the diffuse until self-shadowing normal-maps become the standard.

Since currently all you really know is whether the direct light is hitting the pixel or not, but this doesn't take into account any "overlap" or "protruding" detail you want in the normal-map, unless you use a self-shadowing shader.

So until they become standard I think the AO should at least always be at least a bit evident in the diffuse & specular, otherwise you will find your textures losing contrast.

Anyway, it's obviously the case that this stuff pretty much only applies if you're looking for realism - if you want a more stylised look then you may even want to crank up the AO baked into your diffuse/spec for more visual "pop".

[EarthQuake]

Well it doesn't look bad on skin because it's not multiplied on at any time, it just removes light.

Oh alright, so i imagine that if you had say, a game that was almost entirely outdoor lighting with very little direct lighting, it wouldn't really be worth it to do?

[MoP]

No, it would, because in outdoors you have a very strong direction light source (the sun), and the rest is ambient. So in this case the ambient occlusion map would be fully visible on the "un-lit" side (ie. a character's back, if they are facing into the sun), and the ambient occlusion map would not be used on their front since it was lit directly.

[EarthQuake]

Oh yeah, right. derr

[Firebert]

screw this amazing informational technical data...i am most impressed by EQ's well manicured hands.

[Mark Dygert]

Thanks for all the awesome info guys! So incredibly helpful!

[jerry]

Thanks for all the awesome info guys! So incredibly helpful!

:poly142::thumbup:

[MattBush]

fly_soup: That's a tough one, I suppose if you can get a screenshot of the model in an engine that does it properly and it looks good, it shouldn't really matter that your spec is grayscale. On the other hand, if you're showcasing the actual texture, coloured specs probably look more impressive than grayscale... heh.

I'm still not actually sure what 'doing it properly' is, gamma is part of it, but I'm fairly sure "diffuse * light + spec" isn't right. I've played around with this a bit, need to look in to it a bit more I think. Any insight on this is greatly appreciated.

As for gamma in the shader, yep it's pretty simple: (Think this is right)
// Convert your texture samples from gamma to linear space
textureSample = pow(textureSample, 2.2); // 2.2 being the gamma curve

... do all your calculations in linear space

// Convert your final result back to gamma space
finalColor = pow(finalColor, 1.0 / 2.2);I'm not sure about alpha blending though, if that's done in gamma or linear space.. anyone?

Mop: Good point about detail in the normal map that should cause occlusion from direct light, hadn't really considered that.
You could assume that the AO is being caused by protrusions co-planar to the sample, and modulate the AO by angle between the normal and the light direction, so you get more AO at grazing angles. This would cause a few problems, but it might be slightly better than just using the AO directly for direct lights.

Self-shadowed normal mapping seems to solve the problem pretty well. I think Valve only use it for tiled textures as an extension of their radiosity normal mapping though. I guess the pre-process tool for doing the normals on arbitrary geometry, or even from a high res source would be a bit more difficult..

Some per-pixel PRT baked from a high res source would do the trick. Memory requirements would be a bit excessive though...

Brice Vandemoortele: Thanks for the welcome.
SSAO is a pet hate of mine, especially as a modulative post effect.. yuck (:

[cman2k]

Hey dudes, great info in this thread, thanks for sharing!

Wanted to chip in on self-shadowing normal maps, or at least valve's implementation (coined SSBump). I've been using SSBumps quite a bit in my mod so I have some experience with them.

Mattbush is correct in his statement that these are only used with Valve's radiosity-normal mapping (ie; on brush surfaces and not model surfaces). All of valve's models are still vertex-lit and use standard normal-mapping solutions.

The effect of Valve's solution is very similar to what is described by using a seperate AO channel of information, allowing the AO to be augmented by lighting so that it is more visible in shadow and goes away in brightness. However what they are doing is essentially combining in each RGB channel a direction of normal information as well as AO information (checkout the individual channels of my example to see what i mean).

Furthermore a dynamic light (like the players flashlight) will augment the direction of the shadows by blending different shadow directions that are stored in the ssbump (so the AO looks to be lit directionally). It's a trick, and it isn't 100% accurate, but in real-time it's pretty damn convincing.

I can't say I understand the implementation much more than that, but there is a whitepaper (http://www.valvesoftware.com/publications/2007/SIGGRAPH2007_EfficientSelfShadowedRadiosityNormalM apping.pdf) on the subject. All I know is it works pretty well and makes for a really nice look. I've attached some examples of my usage.

Zbrush sculpt
http://carlosmontero.com/media/xeno_2w1_sculpt.jpg

SSBump map made using Xnormal and specific parameters
http://carlosmontero.com/media/xeno_2w1_ssbump.jpg

seperate channels of ssbump
http://img188.imageshack.us/img188/5434/xenochannels.jpg

in-game
http://carlosmontero.com/media/xeno_2w1_ingame.jpg

Its pretty apparent that the AO is more visible in the shadow than near the lights, which is a neat effect. Like normal maps though, this really shines when it's seen or augmented in real-time.

Coolest of all though is that this is still very cheap and works on many older machines, like most of Valve's stuff.

[MattBush]

I've been using SSBumps quite a bit in my mod
Sweeet, can't wait (: Thanks for the info.

Interesting point, if you add the individual channels of a SSBump map, you get AO, since SSBump maps are basically AO but divided into the contributions from 3 directions.
Can easily be done in the shader to save storing the AO as well, e.g if it were used for something other than radiosity normal mapping and you wanted AO for a single ambient sample.
Edit: Actually I think there is a lighting calculation involved in generating a SSBump map, so it will be a bit different to AO, but probably near enough.

E.g
http://www.decaysoftware.com/personal/images/polycount/SSNMAO.jpg

Lots of stuff I'd like to experiment with now.. when I've got some time I'll make some comparison shots of the various uses of AO we've been discussing, and maybe some spec stuff, with and without correct use of gamma/linear space, etc.

[achmedthesnake]

[QUOTE=...i am most impressed by EQ's well manicured hands.[/QUOTE]

that's cause there're girly hands.....

[Whargoul]

Matt - alpha should not be gamma corrected. If you want something %50 transparent, you want your %50 grey to map to that. We keep our alpha unmolested throughout the pipeline and use it directly as the colour out. We also only gamma correct the diffuse map, and leave all the others as is.

I think of all the other maps as attribute maps (how shiny am I?, how occluded am I?), so they shouldn't be changed. ie 75% shiny is still that. They are numerical values. Diffuse is a visual thing - so it needs the gamma correction, and only that one.

Another thing is specular is not really supposed to be just straight added on top of the rest of the lighting, not sure of the technical details here, but something to do with energy conservation, etc blah blah. I still add it and it looks fine! I have seen this though: lighting = lerp(diffuse, spec coloured, spec) which blends the diffuse light out based on the amount of specular (non-tinted). But I took it out and didn't see a huge change in the lighting.

EQ - I agree that comping it into the diffuse is cheap & easy - but there is a subtle difference to having it applied to the lighting directly. It definitely makes surfaces feel a lot nicer, and less overly authored I guess. But yes, I still like to overlay my AO a few percent into my diffuse, to help make it pop. Maybe it's just not %100 used right in the shader yet, and when it get's there I will kill it from the map, but not quite yet.

I like the idea of Valve's directional AO - especially for flat surfaces. Essentially they are just saving out three directions of AO (how occluded is this pixel by light from this direction) - which can make the lighting look very nice & soft, with subtle self-shadowing. Very cool.

[doc rob]

No, it would, because in outdoors you have a very strong direction light source (the sun), and the rest is ambient. So in this case the ambient occlusion map would be fully visible on the "un-lit" side (ie. a character's back, if they are facing into the sun), and the ambient occlusion map would not be used on their front since it was lit directly.

That's not what Matt and Whargoul are saying, as I understand it. In your example, the character is getting skylight everywhere (not just where the sun isn't shining), so it should get the AO everywhere as part of that light source. The skylight is "ambient." Since the AO is affecting the entire character all the time, you could concievably bake it into the diffuse (and make it pink on the flesh like EQ was saying to simulate the effects of skin).

The second light, the Sun, is fully lighting the character on one side and fully shadowing on the other, so AO doesn't even come into the equation with respect to the Sun's diffuse component. If you were going to use the AO map to help with the Sun light, you would use it on the lit side, not the shadow side, because the shadow side is already fully occluded.

I think what Matt and Whargoul are saying, is that you get great results using the separate AO channel as an occlusion factor for specular from the Sun (on the lit side), as kind of a "cheap" substitute for directional occlusion. Valve's SSNM seems to be a slightly more advanced way to do this by introducing a coarse degree of directionality to that occlusion; a slightly directional occlusion factor instead of the completely directionless Ambient Occlusion.

[MoP]

doc_rob: I'm not sure I agree with you there, maybe there's a misunderstanding?

What I was saying was that while the character is getting skylighting everywhere (due to the ambient term), there are also areas where the character gets ambient and direct light (direct in this case from the sun).

It is these areas where the AO map should not be used, because it is in direct light. If the AO map was used in any areas getting hit by direct light, it would look wrong, because direct light is so strong that it blasts away any occlusion which might have shown up there.

This is why you wouldn't bake your AO into your diffuse and specular - because if you do, then you're negating the effects of direct light by assuming some areas are always ambiently occluded, which of course is not the case when they are lit directly.

Edit: Will see if I can find / create an example image when I get home. If you saw a picture I'm sure it'd be immediately obvious what I was talking about.

[doc rob]

I understand what you're saying - and it might seem right because the directional light is usually so much stronger than the ambient light, it looks like it 'blasts it away' - but I don't think its correct. In my version of your example, there is AO all over the character, but only used once, it's not used in the sunlight term.

Think about it this way. The fact that the sunlight won't use the AO doesn't change how the ambient skylight works. If you turned off the Sun, you would see AO everywhere right? Well, it doesn't go away when the Sun is on, and it doesn't get blasted, it just gets visually overpowered.

[MoP]

Ah, ok I think I see what you mean. Basically the difference would come down to how you set up your shader, I reckon. If you did it the "wrong" way then you'd still see occluded areas even when hit by direct light.

Edit: Added image to better illustrate what I'm talking about.

http://www.greveson.co.uk/dump/ao_shader.jpg

Basically if you bake AO into the texture, then even if you have a super-strong light source, you're always going to get AO in parts which wouldn't actually look like that in real life, since by definition the baked AO is darker than the surrounding area - so you will never get it up to the same brightness unless you crank everything so high that the whole area (AO part included) blows out to pure white.

So in the shader, the areas illuminated by the sun are essentially a "mask" for the AO. You could have the strength of the light be a modulator for how much to mask out - so a weak direct light source would allow some AO to show through, while a very strong direc light source would "completely mask" the AO, and the surface would be fully directly lit with no AO contribution at all.

[rebb]

Master Zap from Mental Images had an interesting article about how AO should and shouldn't be applied some time ago :

http://mentalraytips.blogspot.com/2008/11/joy-of-little-ambience.html

It's mainly aimed at offline rendering tho.

[MoP]

Ah, awesome link, rebb!
Yeah, that covers exactly what I'm talking about - why the ambient occlusion should be only applied to the ambient term, not the direct lighting.

Here's an image pilfered from that site, which illustrates exactly what the shader I'm talking about should do:
http://z4p.com/pd/ao-explain.jpg

[MattBush]

Nice illustration MoP, shows what we're trying to get across really well.

Thanks for the link rebb, totally agree with how he describes the look of AO on direct lights as 'dirty'. It doesn't make sense visually as a result of the direct light so it just reads as a mark on the surface, like dirt. (As you can see in MoP's image)

[doc rob]

Ok, I think I see the issue. In the "baked" version, your AO is getting multiplied over top of everything.

"baked" = (sunlight + flat ambient) * AO
"shader" = sunlight + occluded ambient

I don't know if we can just do the "shader" version in realtime (I'm not that smart), so what I'm suggesting is more of:

instead of:
(sunlight + flat ambient) * AO
do:
sunlight + (flat ambient * AO)

I'm not sure if the math is absolutely right, but do you see the difference?

------------

EDIT: Ack! You found it in the meantime. I'm happy to see my math is right and that we agree :)

[MoP]

Yeah I thought we were talking about the same thing ;)

[JordanW]

Great thread, too bad gamma correction had to rear it's ugly head...lol :)

Whargoul - I've thought about having masks or greyscale maps being in linear space but I think it's best to keep them in sRGB especially if you are creating those maps in photoshop. PS uses a gamma corrected pipeline so if you're creating your specular/mask to be 50% bright and you dont gamma correct it when bringing into the engine it wont be what you saw/painted in photoshop.

You're right about specular not being a simple add, most shaders do however just add it to the diffuse component. Knowing this about specular though can help you when creating your own shaders that include reflection etc...especially in the future when we have to worry about light bouncing around...(ok far future). If I had a shader that was Diffuse+Specular+Reflection I could potentially end up reflecting more light than I received from the light source. When I do reflection in a shader it's usually with a lerp although I should try it with the specular and see how that looks!

Oh btw I thought skin specular was blue because of the blood under the skin reflected the light of the sky? :)

[Ben Apuna]

This thread is great, however I'm not sure I grasp the solution to the main problem yet.

The problem:

Many engines out there assume that our textures are "linear" but in reality they aren't so by adding grayscale specular maps to diffuse color maps we get bad coloring in the highlights when we want most highlights to be white.

Many other rendering artifacts occur because of "nonlinear" textures.

The easy hack solution: (no offense EarthQuake I like easy hack solutions)

Coloring specular maps is a way to get around the fact that we are using un-gamma corrected crappy textures off the net to create our diffuse maps.

The real solution?:

Shouldn't we just gamma correct our maps so that they are then "linear" and the game engines can interpret them properly?

Then we can use grayscale specular maps and stuff them into unused alpha channels to keep the texture call count down.

This also helps the various textured objects avoid many other common rendering problems.

My questions:

So if I'm not being a complete idiot here as I'm recovering from a stomach flu atm and my brain might not be working to it's fullest just yet :(

How do we "gamma correct" our textures in Photoshop to be properly interpreted by an engine as linear?

How do we set up Photoshop's color settings to ensure we aren't corrupting the gamma of our textures as we work on them?

Or should we just leave it all up to the programmers to do all the gamma magic in engine as it seems that many modern GPUs can do some fixes for this stuff almost automaticaly?

[JordanW]

Engines should already gamma correct your textures for you. If you're using UE3 and you double click on a texture to see it's properties there should be a checkbox labeled sRGB. If that is checked then UE3 knows it is not in linear space and will convert it.

[warby]

yeah but that conversion step is what fucks it up right ? we want to see the fuckup in advanced ( in photoshop) and deal with it there wysiwyg style !!!! right ?!?!

[glib]

yeah but that conversion step is what fucks it up right ? we want to see the fuckup in advanced ( in photoshop) and deal with it there wysiwyg style !!!! right ?!?!

You should by default already be looking at sRGB in photoshop. This is why true mid-gray is actually 180,180,180 instead of 127,127,127. You want to tell unreal that you authored your texture in sRGB, so convert it to linear space before it does the math on it.

[MoP]

Yep, unless you've changed your colour settings, I believe Photoshop authors in sRGB space by default.

[rollin]

jumping in to say something about the "skycolour"-thing

I think this comes from film/photography
You can only match your picture to one colour temperature

so with a wrong whitebalance you get a blue-skylight-light and a red-light-bulb-light or a green-neonlight-light

but people somehow expect this to happen nowaday.. so I think it´s a bit like the bullet-hit-sounds from movies: as long as people think it's cool it's ok


btw.. i choose the spec colour just from my feeling.. sometimes I use a complementary and sometimes a simultaneous contrast.. sometimes more sometimes less saturated =)

[MoP]

Yeah, in the end, don't we always just go with whatever looks best, regardless of if it's "correct" or not? :)

[JasonLavoie]

Maaaannn... I just ate one of the tastiest knowledge sandwiches I've ever eaten, such a great discussion.

I do have a couple of dumb questions to ask though :(

For Mops breakdown (the picture he had posted), is the incorrect example just taking the baked out occlusion map and multiplying it over the base diffuse in photoshop (this is what I usually do)? And then just taking the map and inputting it into your shader etc.

And for the correct way of using ambient occlusion, are they taking your base Diffuse map (without the occlusion overtop) then taking it into your engine, and creating a shader that uses a separate occlusion map and does some sort of calculation (masking) depending on where light source / camera is located? Do a lot of games do this?

And I keep on hearing people talking about real-time occlusion in-game, is that just self shadowing? Or is like valves method, SSBump.

Again, crazy awesome dicussion :)

EDIT: Yeah, in the end, don't we always just go with whatever looks best, regardless of if it's "correct" or not? :)

Thats actually another thing that I wanted to talk about. I mean in one way it is awesome to get a spec to technically work like it would in the real world, but when it comes down to it... isn't it more important to have it LOOK good, even though it may not TECHNICALLY be correct.

From reading this thread, I've kinda picked up that a lot of spec in real life is more so "white", but that just seems kinda boring...

[glib]

And I keep on hearing people talking about real-time occlusion in-game, is that just self shadowing? Or is like valves method, SSBump.
SSAO (http://en.wikipedia.org/wiki/Screen_Space_Ambient_Occlusion)


Thats actually another thing that I wanted to talk about. I mean in one way it is awesome to get a spec to technically work like it would in the real world, but when it comes down to it... isn't it more important to have it LOOK good, even though it may not TECHNICALLY be correct.

From reading this thread, I've kinda picked up that a lot of spec in real life is more so "white", but that just seems kinda boring...

I think the most important bit to come out of this discussion is that you should make sure all the gamma calculations are being done correctly first, and THEN worry about post-effects and special looks. If you just ignore each step of the process and wing it, saying 'oh it looks cool', you're going to end up with something in the end that's impossible to tune. It may be a cool 'look', but someone (like an EP or AD) will come by and say to make it more _________ , and you'll be at a loss for how to make that happen since everything acts so unpredictably. My TAD explained it this way: you want to strive on the tech end to make your game look like a film plate (which looks boring as hell), then define your 'look' with post effects and texture tuning.

[MattBush]

JordanW: Cool, glad I'm not alone on that. I was thinking something more like a lerp too, but I'd love to know the exact physics behind it.

Ben Apuna: Getting your textures in to linear space is just part of the problem, once all the calculations are done in linear space, you need to get the result back to gamma space to display, so it really is up to the engine.

JasonLavoie: Well the spec will match the light colour, so not always white, but that's just how reflections work (On most materials at least), take a look at a few objects around your room/workplace so you can see a spec clearly (even the glare on your monitor!).

I guess the only solution at the moment (as everyone is suggesting) is to see what looks right in the engine you're using, checking the result frequently, and under different lighting conditions.
Really the specular should only get it's colour from the light source (with some exceptions), but if your engine isn't doing it properly, then you'll probably have to compensate for that, which is a shame really...

[SHEPEIRO]

completely agree with glib that you can add style and direction after acheiving as real effect as base. if your default values etc are correct then you start with an advantage, and from experience if default settings that are only slightly wrong, lazy bastard artists will leave them in, often as they dont understand why they are slightly wrong as they dont read polycount ;-)

[JohnnySix]

Having read through most of the thread I thought I'd have a go at a wood floor as a backdrop for a low poly character I'm working on.

It's super low detail and very cartoony, so I thought I'd be able to quickly get some cool spec effects, but the texture when lit is extremely washed out.

http://fc01.deviantart.com/fs49/f/2009/207/2/1/Floor_Spec_Map_Test_01_by_JohnnySix.jpg


The alpha on the right is also being used for a bump map.

The basic set-up is diffuse, the spec added in spec channel, and the alpha for the spec level, finally a bump map , again using the alpha.

http://fc09.deviantart.com/fs47/f/2009/207/8/e/Floor_Spec_Maps_by_JohnnySix.jpg

[oXYnary]

Hmm per the srgb correction wysisyg. I see the default is srgb for creation. But importing (color management policies), the default is keeping the images current gamma. Should that not be changed to convert to working space srgb to help lower the issues?

Slightly different topic related. I see many mentions of photos imported to create textures. Would not just creating your textures by hand or procedural filters lower this gamma difference as well?

Also, with AO and diffuse. If Ao gets to the point that we can use as a separate shader map versus baking into diffuse, would then a convexity or cavity map takes it place? Also, not sure this helps the discussion, but in order to keep the weird specular happening as much. from the AO multiplied in specular, I make the AO in the spec multiply like only 20. So its there, but its not as apparent when using direct lighting. Kinda of a middle ground as it were.

BTW this has been a great thread. Passed unto programmer.

[Whargoul]

As for other textures being gamma corrected or not:

I never gamma them - they are numerical. What I mean is that I am not painting them visually - but as data. So when I want something %50 specular, I am using the colour 127,127,127. Not the visual %50 grey. So when that goes into the engine, because it's treated as linear, that 127 becomes 0.5 spec value. If we treat that as a gamma'd value in the shader (we typically square them on input, and sqrt the final result) - it would only be %25 specular. Now, in reality this doesn't make much difference because you are tuning the values based on what the results look like.

The main reason visual data is gamma corrected, and linear data is not, is the precision of that data. If we take our spec data, in linear format it is a nice even progression, every step is equal. You can see when we un-gamma corrected it, it shifted all the data downwards, which means we are using lots of bits to store the high end more accurately - which is not what we need.

On the visual side, yes, that's good. We don't need to store as much info in the blacks as we are not able to discern as much difference between the steps, so we save the most bits for where we see it the most. If we were to pre-ungamma our diffuse maps and save them out linear our blacks would be all crushed and we'd see banding when rendered.

Of course, I get confused as to which way things are shifted, how gamma is corrected, etc, so some of what I said may be the inverse of reality - but you get the drift :)

[perna]

Is the AO discussion getting too theoretical perhaps? Baked AO looks "dirty" in the teapots on a box scenario, but games don't look like that :) In a game that box would have a muddled up noisy texture trying to look like gears of war and you'd probably want not only to include an AO bake, but to set it at 200% and include "fake ao" generated from the normal map as well, just to help shapes read better.

Got to keep in mind that even the pre-rendered FMV guys use a whole bunch of "unrealistic" tricks to help stuff read better. However one should always have a firm understanding of theory and rules before breaking them...

[JohnnySix]

So do you need a bump-map to really appreciate specular? One flat faces it tends to just wash out the texture completely?

[jeffdr]

More sRGB & gamma correction stuff if anybody's still interested:

http://download.microsoft.com/download/b/5/5/b55d67ff-f1cb-4174-836a-bbf8f84fb7e1/Picture%20Perfect%20-%20Gamma%20Through%20the%20Rendering%20Pipeline.zi p

[JacqueChoi]

Blue does a few things.

First off, (as Jordan Mentioned) it emulates the sky. But if your render engine multiplies spec with the skybox, (or has another GI type effect) Greyscale would be a much more suitable solution.


The second thing Blue does, is it's a very 'hacky' way of muting the diffuse. If you **push** the saturation in the diffuse, then the 'lighting terminator' would appear more 'flesh/blood/ red'. And with a wide enough specular (little to no gloss/spec power), you could mute the colour of the skintones.


If skin is Orange-ish (R+G) then theoretically Blue (B) would make it more 'desaturated' than 'grey(RGB)' would.... without drastically changing the value of the lighting halftone.


SO in a way, it would seem that it emulates the reflectivity SSS of the light halftone no? While the more aggressively saturated diffuse would help sell the effect of the lighting terminator in the SSS.

[Racer445]

First off, (as Jordan Mentioned) it emulates the sky. But if your render engine multiplies spec with the skybox, (or has another GI type effect) Greyscale would be a much more suitable solution.

i don't mean to be a dick, but the "blue is for sky" thing is a huge rationalization for an incorrect specular solution and/or being misinformed. again no disrespect, but as per noted on the first page, it's a silly thing to say:

Whenever I have brought this up the last 12-13 years people tend to go apeshit and talk about how spec color is related to the blue sky or some lameness, usually backing it up with photographic "evidence"

i think the problem is that you and many others may be thinking only in terms of making skin and other non-conductive materials like fabrics. from an art standpoint, grayscale is NOT a suitable solution for anything that which is a "conductor" (metals), requires variation, or has multiple materials on the same texture--all very common situations.

ever tried to pull off copper, brass, or heat discoloration using grayscale spec? ever needed to texture plastics and metals on the same texture with grayscale? you simply cannot get them easily readable, let alone attractive without colored specular.

and all of this is purely from an art standpoint, since all the technicals have already been covered in this thread.