[Bf-cycles] build with OSL support

[Yasuhiro Fujii]

Please wait merging. Current version has the wrong parameter region of
roughness, sorry.
I read the original O-N paper, I think it is natural to be [0, 2pi].
http://www1.cs.columbia.edu/CAVE/publications/pdfs/Oren_SIGGRAPH94.pdf
sigma means the deviation of \theta_a (See Figure 4).

By the way, the constant factors of O-N:
  0 <= sigma <= 2pi
  A = 1.0f - 0.5f * (sigma * sigma) / (sigma * sigma + 0.33f);
  B = 0.45f * (sigma * sigma) / (sigma * sigma + 0.09f);
are practically less useful for me. I want to propose simpler ones:
  0<= sigma <= 1
  A = 1.0f - 0.5f * sigma;
  B = 0.5f * sigma;
which are much more useful for me. they have no magic numbers and
behave straightforwardly.
Of course, this form is artificial. however, original form also
doesn't seem to have strong theoretical reason. It seems to be chosen
by numerical experiment, not by the straight approximation.

What do you think about it?


On Fri, Nov 11, 2011 at 2:00 AM, Brecht Van Lommel
<brechtvanlommel at pandora.be> wrote:
> Thanks, this looks good, I should be able to commit it soon.
>
> Brecht.
>
> On Thu, Nov 10, 2011 at 4:47 PM, Yasuhiro Fujii
> <y-fujii at mimosa-pudica.net> wrote:
>> The patch is updated (Patch updating information is not automatically mailed?).
>>
>> 0. Adapted for trunk.
>> 1. Diffuse and O-N node are unified.
>> http://projects.blender.org/tracker/index.php?func=detail&aid=29193&group_id=9&atid=127
>>
>>
>> On Thu, Nov 10, 2011 at 6:10 PM, Yasuhiro Fujii
>> <y-fujii at mimosa-pudica.net> wrote:
>>> Additionally, there is a reason to use uniform sampler, not
>>> cos-weighted sampler.
>>> For example, when
>>>    (eye vector) == (light vector) && (eye vector) dot (surface normal) == 0,
>>> lambert value is 0.0 but O-N value is not 0.0.
>>> Therefore, I think O-N cannot be sampled correctly with cos-weighted sampler.
>>> We can write a advanced O-N specific sampler, but I think it is
>>> overkill for the 1st implementation.
>>>
>>> I'm not a renderer expert, suggestions are welcome.
>>>
>>>
>>> On Thu, Nov 10, 2011 at 12:22 PM, Yasuhiro Fujii
>>> <y-fujii at mimosa-pudica.net> wrote:
>>>> Yes, they converge to the same value. however, difffuse() uses
>>>> cosine-weighted importance sampler while my oren_nayar() currently
>>>> uses uniform sampler, they have different variances. (Sorry for my
>>>> poor English skill...)
>>>>
>>>> After night's sleep, I started to think that it is a technical detail,
>>>> it can be resolved later when it becomes a problem.
>>>> OK, I will change the patch to unify diffuse() and oren_nayar().
>>>>
>>>>
>>>> On Thu, Nov 10, 2011 at 2:23 AM, Brecht Van Lommel
>>>> <brechtvanlommel at pandora.be> wrote:
>>>>> I think it should converge to the same result when roughness is zero?
>>>>> At least in blender internal this seems to be the case. Also, looking
>>>>> at your code: when sigma = 0, we get m_a = 1 and m_b = 0. As a result,
>>>>> all that is left is nl/M_PI, i.e. a regular diffuse BSDF?
>>>>>
>>>>> Brecht.
>>>>>
>>>>> On Wed, Nov 9, 2011 at 4:27 PM, Yasuhiro Fujii
>>>>> <y-fujii at mimosa-pudica.net> wrote:
>>>>>> pros:
>>>>>> + Simplify the UI.
>>>>>> + Simplify the code.
>>>>>>
>>>>>> cons:
>>>>>> + oren_nayar() and diffuse() have different convergence behavior even
>>>>>> if roughness == 0.0, yield very different looks if convergence is not
>>>>>> sufficient. In some scene, designers may want to choose oren_nayar()
>>>>>> even if roughness == 0.0.
>>>>>> + Thus users must know roughness = 0.0 is specialized.
>>>>>>
>>>>>> I can't decide it because of my poor experience, especially designer's side.
>>>>>> What do you think about their cons?
>>>>>>
>>>>>>
>>>>>> On Wed, Nov 9, 2011 at 11:37 PM, Brecht Van Lommel
>>>>>> <brechtvanlommel at pandora.be> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> What do you think about implement this as a Roughness input for the
>>>>>>> Diffuse BSDF node, instead of a separate one? Internally it can still
>>>>>>> be a separate closure/BSDF, but it could just check if(roughness ==
>>>>>>> 0.0) diffuse() else oren_nayar().
>>>>>>>
>>>>>>> Brecht.
>>>>>>>
>>>>>>> On Wed, Nov 9, 2011 at 6:55 AM, Yasuhiro Fujii
>>>>>>> <y-fujii at mimosa-pudica.net> wrote:
>>>>>>>> The O-N patch must be updated, however, the compile errors don't seem
>>>>>>>> to be caused by this patch. I guess that they are due to tomato branch
>>>>>>>> merged.
>>>>>>>>
>>>>>>>> Blender's source (including cycles) will be changed a lot this week,
>>>>>>>> due to a Branch Merger hurricane week:
>>>>>>>> http://www.blendernation.com/2011/11/07/developer-meeting-notes-november-6-2011/
>>>>>>>>
>>>>>>>> I will update the patch when cycles get to be able to compile again.
>>>>>>>>
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Bf-cycles mailing list
>>>>>>> Bf-cycles at blender.org
>>>>>>> http://lists.blender.org/mailman/listinfo/bf-cycles
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Bf-cycles mailing list
>>>>>> Bf-cycles at blender.org
>>>>>> http://lists.blender.org/mailman/listinfo/bf-cycles
>>>>>>
>>>>> _______________________________________________
>>>>> Bf-cycles mailing list
>>>>> Bf-cycles at blender.org
>>>>> http://lists.blender.org/mailman/listinfo/bf-cycles
>>>>>
>>>>
>>>
>> _______________________________________________
>> Bf-cycles mailing list
>> Bf-cycles at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-cycles
>>
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> http://lists.blender.org/mailman/listinfo/bf-cycles
>