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 (:
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 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
SSBump map made using Xnormal and specific parameters
seperate channels of ssbump
in-game
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.
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
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.
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.
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.
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.
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.
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.
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.
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:
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)
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
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?
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?
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.
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 ?!?!
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.
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
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.
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...
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.
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...
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 ;-)
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.
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.
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.
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
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.
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.
Replies
:poly142::thumbup:
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) 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 (:
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 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
SSBump map made using Xnormal and specific parameters
seperate channels of ssbump
in-game
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.
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
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.
that's cause there're girly hands.....
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.
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.
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.
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.
Edit: Added image to better illustrate what I'm talking about.
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.
http://mentalraytips.blogspot.com/2008/11/joy-of-little-ambience.html
It's mainly aimed at offline rendering tho.
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:
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)
"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
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?
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?
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.
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
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:
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.
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...
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.
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.
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.
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
http://download.microsoft.com/download/b/5/5/b55d67ff-f1cb-4174-836a-bbf8f84fb7e1/Picture%20Perfect%20-%20Gamma%20Through%20the%20Rendering%20Pipeline.zip
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.
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:
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.