No problem Baggins.  I just get a little sensitive when ppl compare my shaders with theirs.  Most of the time they use favourable light and renders settings for their shader, which is not fair.

Cool. Everybody should understand I was testing 3 shaders of mine, each built using different techniques, two of which I did not invent. But they are my implementations, and if they suck it's my shaders that suck, not incidence shaders in general. Maybe I didn't build mine same as yours. Maybe yours doesn't blow up under different light conditions. I don't know - I don't have any of your shaders and have never seen the shader trees.

However, I was comparing shaders fairly. Each row is a single render with four figures - therefore they have identical render settings and lighting conditions. And the four rows was deliberately trying to examine how the appearance evolves as the lighting is changed. Again, a single render yielded whatever results it yielded for all four. There was no tampering.

*Anyway...Any SSS technique that does not take into account the positioning of the main light source is going to compromise realism. *

I agree, but why did you feel the need to point that out? I ask, because all three shaders do take the lights into account. Additionally, the toon and cosine technique take IBL into account. They also take into account other lights, not just the main light. Every time you introduce another light, change any of the intensities, change light types (spot, inf, point), apply AO, or move any light, the toon and cosine techniques produce a different distribution of red. The incidence one doesn't do as much tracking of the lighting as the other two techniques. I've also built a multi-light incidence shader that tracks any number of lights. I've also built one that uses a point-by-point recalculation of the vector-to-the-light that works much better than the single vector technique for point lights and spot lights. But in all my side-by-side tests, I felt that the cosine technique pretty well matched the results.

I think your issue with the Incidence technique is that you need to run the shader again if you move the main light. 

Actually that is a concern, but not my main issue. Since I wrote Parmatic (dynamic shader parameters), the callback thing is easy. I haven't released any of this yet, but I'm adding stuff to Matmatic to allow it to create shaders in memory, not just write a file, and Parmatic can call it. So I have the ability to create new nodes, rewire nodes, change parameters, etc when you add a light, or move the camera or move a prop and so on, in real time. 

No, my main issue is that the incidence technique, in order to take all my lights into account, including point lights close to the figure, is way more complicated than the cosine technique, while at the same time the cosine generally produces equal or even better results and runs faster. The cosine is also more predictable and requires less adjustment. Once it's set right for a given texture, it seems to do a good job in any lighting. And with only 4 easy-to-understand dials, I've been able to make it very easily adjustable.

*If you want more realism, I think /simplifying/ the SSS model is going in the wrong direction. *

Simplifying at the expense of results is wrong. However, given two systems that do the same function equaly well, I choose the simpler one.

In this case, my question wasn't about simplicity, it was "does the cosine work better than the incidence, all other things being equal?" That's why I did the comparison the way I did it. Given one lighting condition (50/50), I adjusted the techniques to produce good and nearly identical results. The first row is that. Then I varied the lighting amount only and they became different. 

My question to the forum was, which of the three has evolved in a way you expect/find pleasing. The fact is at any of those light levels, I can make all three look identicial by adjusting parameters. But if the concensus was that the cosine one was the desired result, then why bother making adjustments to the incidence or toon, or worse, try to find even more algorithmic structures to force them to behave like the cosine one.

It's funny you mention "unfair comparison." I actually started off aligning the three results with the 90/0 light combo, and then leaving all the dials alone, rendered with the 50/50. The incidence shader, adjusted to look like the cosine at 90/0, went completely berzerk at 50/50, going wildly red. I figured people (especially you) would cry foul, so I started the demo at 50/50, giving the incidence shader the best adjustment in its worst scenario. I bet with some more work I could get it to stop behaving like that, but what's the point, if cosine is good enough?

My next step was going to be to keep the light intensities the same, but move them around to produce various extreme lighting angles, and again query the forum to see which technique produces a response that is most expected/pleasing. Again, if the answer is cosine, then I'm done. If it's not, then I'm not and will keep studying the matter.

You need to be building a shader than takes into account MORE of the scene information, not LESS.

Yes, well, that was already my point. The part of the shader that produces front-side SSS needs to work for all lights, of any kind. My question to the forum was, which of these is doing that best?

Finally, of course I know that skin imperfections, soft reflections, global illumination, back-lit SSS, yada yada are necessary for realism. All that stuff is in the mix too, and when I "fire for effect" it will be there, just not for this test of front-side SSS. I've got those pretty well producing predictable, reliable, flexible results. It was this SSS that still bugged me.

 

---

Renderosity forum reply notifications are wonky. If I read a follow-up in a thread, but I don't myself reply, then notifications no longer happen AT ALL on that thread. So if I seem to be ignoring a question, that's why. (Updated September 23, 2019)