[Bf-committers] Re: Minnaert shader

[Jonathan Merritt]

Jean-Luc Peuriere wrote:

> Your own links say that k=1 ==> Lambert.


Yes, but who decided that k=1 should be Lambertian?  I had to modify the
limb darkening in order to avoid having the shader generate rim
artifacts.  I also decided that I thought k=0 as Lambertian would make
more sense.  Why do you object to one of those decisions but not the
other?  I would have thought that the method of adjusting the limb
darkening was a far more important modification to the original shader
than changing the range of k?  I'm not sure that either are "correct";
they're just "what I did".  As I said, the original shader just doesn't
work!

It made more sense to me to have k in the range I chose.  Maybe an
example will help to explain why:
    http://www.warpax.com/temp/minnaert-example.png
When k goes negative, the rim is brightened ("negative darkening"), when
k is zero you have Lambertian lighting, and finally when k goes
positive, the rim is darkened ("positive darkening").  What's wrong or
counter-intuitive about that?

Consider how confusing it would be if the "zero point", where the switch
between limb darkening and limb-brightening occurs, were at 1.0 rather
than at 0.0.  That's *all* I've changed in the k value.

> Jorge said you mixed the 2 versions, it appears it is only base one.


That was just a miscommunication I think.  I achieved the overall "look"
of both versions by modifying the limb darkening.  I spent quite a lot
of time investigating the Minneart rim artifacts.

> the issue is not silly at all, but leads to confuse an user who would
> try to follow some documentation or tutorial on the net.


What documentation or tutorial?

I think I've referenced most of the documentation that people have
pointed to on the net, and established that those implementations are
flawed.  They generate rim artifacts, and hence are simply not usable. 
Sure, my interpretation of the "k" value has changed, but so has
everything else!  Putting "k" back to normal *still* won't get people
the same results as any of the online stuff that has been discussed here.

> There is 2 solutions to correct that :
>
> - changing the parameter name to something else (eg obscuring) while
> stating in the doc the relation with k
> - using the same range as the others.


In Tuhopuu, the "k" value has always been called "Dark" in the UI,
following Jorge's original implementation.  In the code, the value is
called "darkness".  I've only been talking about "k" because it was
brought up in the context of the original emails.  In that respect, your
first suggestion has always been the case anyway.  "k" never appears in
the UI, the code, or my comments in the code.

I completely agree that the whole thing needs documenting if it's
accepted in to bf-blender.  I also agree that if other software (or
online tutorials) talk about a different Minnaert shader then we should
match their implementation.  However, all the online stuff I've been
pointed at so far has rim artifacts, and hence *can't* be used without
modification.  I made some changes to get rid of those artifacts.  I'm
not saying that my changes are somehow authoritative (there are surely
many other possibilities), but what you seem to be asking for (ie: match
the existing online stuff that's been discussed so far) isn't possible
for reasons that go deeper that just the meaning of "k".

I said it was silly only because it's as though you're comparing apples
and oranges when I'm holding a mango! :-)

-- 
Jonathan Merritt BE(Mech)/BSc
PhD Student - Equine Biomechanics
The University of Melbourne
Veterinary Clinical Centre, Werribee