[Soc-2018-dev] Weekly report #10 - Implementing a Hair Shader for Cycles

Sun Jul 29 18:23:56 CEST 2018

Thanks for testing. I don't immediately have good ideas on how to solve
that noise if there is no obvious cause.

You could try disabling Russian roulette in
path_state_continuation_probability() (always return 1.0) and see how much
that is responsible for the noise. Though we can't really render hair
efficiently without that.

On Fri, Jul 27, 2018 at 3:06 PM Leonardo E. Segovia <
leonardo.segovia at cs.uns.edu.ar> wrote:

> Hey all, hey Brecht,
>
> I spent the whole day yesterday dissecting the shader. I tried:
> - selectively removing modes (azimuthal only, longitudinal only,  both)
> - changing BSDF path labelling
> - manual calculation of the alpha and attenuation angles
> - whether the Bessel function / logarithm approximation was introducing
> additional noise
> - whether Lukas's changes in the logarithm approximation were the source
> of the above
>
> None of the above helped me figure out what causes the noise, only narrow
> down where and when it happens:
>
> - It only affects the TT mode of the shader
> - It only affects the Glossy Indirect illumination pass
> - It affects the whole hair length, not just those parts which are away
> from the light source
>
> I've uploaded a multi-layer EXR example at
> https://framadrop.org/r/09_50tz4sM#1PkFSGOaENlBkpROKrLrjjy8HVi1pg4GqnfR1mqTkz8=
> . You'll see that the Gloss Ind pass is absolutely noisy.
>
> Best regards,
> Leonardo
>
> El mié., 25 de jul. de 2018 a la(s) 10:42, Leonardo E. Segovia (
> leonardo.segovia at cs.uns.edu.ar) escribió:
>
>> Hey all,
>>
>> Brecht: sadly, it is expected. I did more tests and it turns out that
>> multiplying Radial Roughness by 3 gets a more similar look to the "before"
>> render. Now, I think it'll be better to start separating the render into
>> modes to see where the noise is actually coming from.
>>
>> Best regards,
>> Leonardo
>>
>> El mié., 25 de jul. de 2018 a la(s) 09:45, Brecht Van Lommel (
>> brechtvanlommel at gmail.com) escribió:
>>
>>> Thanks for the tests. To me the before renders still look better? While
>>> 3x gives similar noise levels, the results are less accurate, the hair is
>>> noticeably brighter.
>>>
>>> On Tue, Jul 24, 2018 at 10:40 PM Leonardo E. Segovia <
>>> leonardo.segovia at cs.uns.edu.ar> wrote:
>>>
>>>> Hey all, hi Brecht,
>>>>
>>>> As regards noise and fireflies, they come from basically two places:
>>>> - Low Roughness. This compress (longitudinally) the glints so much,
>>>> they look like fireflies.
>>>> - Low Radial Roughness. These make the hair look SO soft!
>>>> - Very lightly colored hair (this one is non fixeable by us)
>>>>
>>>> Possible mitigations include:
>>>> - Raising the clamp from 0.001 to 0.01 to at least have a reasonable
>>>> glint when Roughness < 0.1
>>>> - Filter Glossy
>>>>
>>>> I've already uploaded a fix for the former. I'd like to discuss the
>>>> behavior of Filter Glossy.
>>>>
>>>> When doing the CPU profiling that you requested, I realised that Filter
>>>> Glossy is executed after the closure setup (before closure setup =
>>>> roughness, after = logistic parameters), which means it isn't affecting the
>>>> roughness properly.
>>>> rB52a0e67fe005
>>>> <https://developer.blender.org/rB52a0e67fe0050683a888d6643ec2035bd2b3ea1c>
>>>> is the commit that includes both mitigations, however, the new
>>>> implementation is noticeably less effective. I've obtained decent results
>>>> when applying fmaxf(3*roughness to both Roughness and Radial
>>>> Roughness; you'll find a visual comparison of the fixes below. (The
>>>> original picture is up at
>>>> https://framapic.org/ksZ7ftOaGvqk/gS2Cv0cjrdUg.jpg.)
>>>>
>>>>
>>>>
>>>> I'm not sure if there is any need to strengthen Filter Glossy wrt.
>>>> Radial Roughness in this way; please let me know what you think.
>>>>
>>>> Best regards,
>>>> Leonardo
>>>>
>>>> El lun., 23 de jul. de 2018 a la(s) 08:16, Brecht Van Lommel (
>>>> brechtvanlommel at gmail.com) escribió:
>>>>
>>>>> Hi,
>>>>>
>>>>>
>>>>>>    - The regression test suite has not been uploaded yet to SVN.
>>>>>>
>>>>>
>>>>> I've committed these as well now.
>>>>>
>>>>>
>>>>>>    - It's been asked in the BA thread if I have extra objectives for
>>>>>> the
>>>>>>    shaders. Do you feel that more features/controls should be added?
>>>>>>
>>>>>
>>>>> More features could be good, but also part of the GSoC plan was to
>>>>> investigate optimizations for the shader, since it still is relatively slow
>>>>> / noisy.
>>>>>
>>>>> So I think you should at least profile the shader, and look into
>>>>> fireflies to see where they come from and if they are expected or not. I
>>>>> don't know if there is anything major to find, but it's worth investigating.
>>>>>
>>>>>       - I came up with controls for each of the modes (R, TT, TRT,
>>>>>> TRRT+).
>>>>>>       - It's been also suggested to prune the UI into a "Basic" and
>>>>>>       "Advanced" mode.
>>>>>>
>>>>>
>>>>> I'd be hesitant to add features to break physical correctness and
>>>>> energy conservation so early, before people have really tested the shader.
>>>>> I rather users test it and then give us feedback saying they can't achieve
>>>>> this or that look, and then we see what the best solution is.
>>>>>
>>>>> Maybe commit it to your branch and then we can always add it later if
>>>>> there is a need for it.
>>>>>
>>>>>
>>>>>> About the GSoC project deliverables:
>>>>>>
>>>>>>    - If I read the mail correctly, Google wants us students to
>>>>>> summarize
>>>>>>    and show off our work in a single place e.g. a blog post. How does
>>>>>> Blender
>>>>>>    handle this?
>>>>>>       - My preference would be to add a page (similar to when one
>>>>>> publishes
>>>>>>       a paper) in amyspark.me explaining the work we did. We could
>>>>>> embed
>>>>>>       the resulting pictures, credits, etc. and the demonstration
>>>>>> video from
>>>>>>       Youtube.
>>>>>>       - As for "Get the code", perhaps I could add links to the
>>>>>> relevant
>>>>>>       commits?
>>>>>>
>>>>>
>>>>> A webpage is fine, for the code you can link to the git branch.
>>>>>
>>>>> Thanks,
>>>>> Brecht.
>>>>>
>>>>>
>>>>> --
>>>>> Soc-2018-dev mailing list
>>>>> Soc-2018-dev at blender.org
>>>>> https://lists.blender.org/mailman/listinfo/soc-2018-dev
>>>>>
>>>>
>>>>
>>>> --
>>>> Lic. Leonardo E. Segovia
>>>> Departamento de Ciencias e Ingeniería de la Computación
>>>> Universidad Nacional del Sur
>>>> San Andrés 800 - Campus Palihue, B8000 Bahía Blanca, Argentina
>>>> --
>>>> Soc-2018-dev mailing list
>>>> Soc-2018-dev at blender.org
>>>> https://lists.blender.org/mailman/listinfo/soc-2018-dev
>>>>
>>> --
>>> Soc-2018-dev mailing list
>>> Soc-2018-dev at blender.org
>>> https://lists.blender.org/mailman/listinfo/soc-2018-dev
>>>
>>
>>
>> --
>> Lic. Leonardo E. Segovia
>> Departamento de Ciencias e Ingeniería de la Computación
>> Universidad Nacional del Sur
>> San Andrés 800 - Campus Palihue, B8000 Bahía Blanca, Argentina
>>
>
>
> --
> Lic. Leonardo E. Segovia
> Departamento de Ciencias e Ingeniería de la Computación
> Universidad Nacional del Sur
> San Andrés 800 - Campus Palihue, B8000 Bahía Blanca, Argentina
> --
> Soc-2018-dev mailing list
> Soc-2018-dev at blender.org
> https://lists.blender.org/mailman/listinfo/soc-2018-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/soc-2018-dev/attachments/20180729/82b1b7b3/attachment-0001.html>