I have been learning about conservation of energy being balanced between diffuse and specular values. But I am confused as to how specular maps play a role in this.

Doesnt a specular map create areas where total light = less than 1?

Conservation of energy means that a surface must not emit more light than it receives. It is perfectly OK for it, however, to absorb energy and reflect less than it receives.

Here's the shader, simple diffuse

When correctly used in a shader, a specular map controls the proportion of incoming light that is reflected specularly at each point on the surface, before anything else happens to it.

The principle of energy conservation requires that only the remaining proportion is made available for further processing in the shader - diffuse reflection, refraction, sub-surface scattering, absorption, etc.

That's the purpose of the Subtraction node in Anthanasius' shader - to subtract the specular (Blinn) from what is being passed through to the Diffuse node. A specular map would simply control the Blinn intensity via the Specular_Color input.

Quote - Here's the shader, simple diffuse

That shader does not implement conservation of energy.

Imagine you have light 1 shining at it at 100% intensity.

Now add another light 2, pointed at the same object. Should the specular contribution of light 2 reduce the diffuce contribution of light 1? It should not. That shader, however, does exactly that.

In my opinion there is no such thing as conservation of anything, in Poser. The things which do matter are: prevention of overlighting, and proper/believabe balancing of components. In both cases it seriously matters whether Gamma Correction is applied (it might when available (PPro/P10), as it improves the believability / level of realism of the result but it seriously affects the balances as well).

I'm happy to go into the details behind this, but only when someone is interested.

Quote - In my opinion there is no such thing as conservation of anything, in Poser. The things which do matter are: prevention of overlighting, and proper/believabe balancing of components. In both cases it seriously matters whether Gamma Correction is applied (it might when available (PPro/P10), as it improves the believability / level of realism of the result but it seriously affects the balances as well).

I'm happy to go into the details behind this, but only when someone is interested.

Don't. You still have not acknowledged the material I gave you to read, and more specifically, that 100 + 100 does not equal 200 in sRGB brightness.

Note: The Blinn negative feed into Diffuse shown above was something I used to make skin look more realistic when using the Blinn node. It has more to do with hacking one math function to look like another. I don't use it for other things besides skin. It is not conservation of energy.

Quote - That's the purpose of the Subtraction node in Anthanasius' shader - to subtract the specular (Blinn) from what is being passed through to the Diffuse node.

Nope. The purpose is that I didn't feel what I saw with my artist's eye matched reality and that skin is more complex than a simple Blinn can describe. So I started doing that trick back in 2007 - it's a hack. It was also needed more before linear work flow. Now that we (well, most of we) understand linear workflow, this trick is much less needed.

There is no physical reason that when you are lined up with a light source, the diffuse reflections would be subdued.

However, if you're not using linear workflow, that trick will make skin speculars look a lot more normal. It is mostly due to performing linear sums in gamma space, which we (well, most of we) now understand is just wrong.

Quote - > Quote - Here's the shader, simple diffuse

That shader does not implement conservation of energy.

Imagine you have light 1 shining at it at 100% intensity.

Now add another light 2, pointed at the same object. Should the specular contribution of light 2 reduce the diffuce contribution of light 1? It should not. That shader, however, does exactly that.

Correct. It is one of hundreds of hacks and goofy compensations motivated by a desire for realism in gamma space before the epiphany of linear workflow was revealed.

I have to admit that I used the words "conservation of energy" in conjunction with this node arrangement, but I also called it a cheat.

In this thread, we were discussing car shaders in 2010 (the year, not the Poser version) and templargfx was working on car shaders but did not want to use linear workflow (i.e. gamma correction). So I showed the trick.

Ice-boy asked "how did you get that highlight infront to look so good?
what is your secret?"

I replied "It's just a Specular node, using my standard cheat for conservation of energy, where I subtract its output from 1, and run that into Diffuse_Value."

http://www.renderosity.com/mod/forumpro/showthread.php?thread_id=2803614&page=2#message_3656608

This is hackery of the finest kind in a situation where the real problem is we add 100+100 and think it is 200. By making one of the addends subdued when the other grows, it gets closer to the linear workflow behavior where the sRGB values 100 + 100 = 137.

The numbers in sRGB are like unicode code points. Don't think of them as numerical values. Think of them as indices in a lookup table, which may or may not have anything to do with each other.

In sRGB the code point 100 is half as bright as the code point 137. The number 200 is much much brighter than twice the brightness of 100. The number 200 is 4.6 times brighter than 100.

My hack (and it is superemely a hack) was a one-node solution to the sRGB definition of 100 + 100 (and similar additions.) At the time I came up with it, I did it based on what I saw and felt looked wrong, not based on math and physics. What I felt was wrong was that the values approaching the brightest part of a highlight seemed to be growing too quickly. The result appeared to be giving off more light than had arrived - a violation of conservation of energy.

CoE is not about the balance between different kinds of reflection - that is mostly the concern of the "Fresnel" effect in a shader. CoE is about the total amount of reflected light in relation to the total amount of arriving light.

If you use linear workflow, that problem (and others) doesn't happen.

I guess another way to put it: this hacked shader configuration is motivated by concerns about conservation of energy, but it is not an "energy conserving shader". It's a hack.

The straightforward solution is to stop using linear arithmetic with non-linear values.