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

[Leonardo E. Segovia]

Hey Brecht,

Thanks for the fixes.

The remaining avenues for crashes now are:

- "Non-finite sum in path_radiance_clamp_and_sum!" (strange, as our shader
is protected from NaNs now)
- kernel_assert(fabsf(h) < 1.0f + 1e-4f) (some strands seem to have width >
2. Is everything normalized?)
- kernel_assert(fabsf(dot(X, Y)) < 1e-4f); (what is/was the derivative
dPdCD?)

About ribbons - I've got my PBRT book (Section 3.7 is the relevant one) and
Pharr's implementation notes here.
If I understood them correctly, for ribbons (and any primitive in general)
all they need to get h was intersection->v. This is because under their
coordinate system v is in [0, 1] and orthogonal to their curve's axis, i.e.
v measures the hit coord along the curve's width. It seems that this is not
the case with Blender, because using it yields all-black hairs (line
segments) or nothing (cardinal B-splines).

Can anyone tell me more about Blender's coord system? If necessary, I'll
cross-post in bf-cycles.

Best regards,
Leonardo

2018-05-26 20:50 GMT-03:00 Brecht Van Lommel <brechtvanlommel at gmail.com>:

> I committed a couple cleanups and fixes now. The biggest change is not
> using curve_core_distance at all, which as far as I can tell is not
> really needed.
>
> This fixes the asserts that I found in a couple simple tests here, but
> maybe you found other cases.
>
> On Sat, May 26, 2018 at 2:57 PM, Brecht Van Lommel <
> brechtvanlommel at gmail.com> wrote:
>
>> I suggest to carefully check each part of the shader is working
>> correctly. For that you can create a simple scene with a single hair with a
>> big radius. Then you can light that with just a white background or a
>> single point light, without any indirect light bounces. If that's correct,
>> add more samples, more bounces, more hair, etc.
>>
>> That way you can see if the results looks correct, compare with existing
>> BSDFs, and see where exactly it is more noisy or wrong. Getting some tests
>> builds for users is good, but I suggest to mainly focus on verifying the
>> correctness in an organised way at this point.
>>
>> I'll have a look at the NaNs and assertions this weekend.
>>
>>
>> On Fri, May 25, 2018 at 9:46 PM, Leonardo E. Segovia <
>> leonardo.segovia at cs.uns.edu.ar> wrote:
>>
>>> WEEK 2
>>>
>>>
>>> Hi everyone! The second week is gone, and this is my report.
>>>
>>>
>>> Objectives
>>>
>>> With the shader in place, I could move on to the following (Weeks 4-5):
>>>
>>> -   Test shader functionality. If working, release test build.
>>> -   Evaluate received feedback. Start bug fixes.
>>>
>>>
>>> What's been done
>>>
>>> Admittedly, not much [image: 😢]
>>>
>>> -   Lukas added a Diffuse override for using the shader with non-hair
>>>     geometry, in bsdf_principled_hair_setup. When using it with hair,
>>>     however, Blender didn't render anything _at all_. This was because
>>>     the ID of the shader was outside the range of CLOSURE_IS_BSDF. Our
>>>     shader is now treated as BSDF and transmissive
>>>     {{GitCommit|rBc4174a44dc311d2fd65ca74c4387bbc6f529df95}}
>>>
>>> -   With the BSDF in place, I tried to get reference renders. The main
>>>     problem is that Blender's hair primitive is returning NaNs in any or
>>>     all of the following:
>>>
>>>     -   the ray distance t
>>>     -   the intersection calculation, somewhere deep within
>>>         cardinal_curve_intersect or curve_intersect
>>>     -   the curve distance h (this one usually comes from the above)
>>>
>>>     Which results in one or more of the following:
>>>
>>>     -   crash when integrating indirect radiance
>>>         ("Non-finite sum in path_radiance_clamp_and_sum!")
>>>     -   crash when obtaining azimuthal_scattering (I have a scene to
>>>         obtain this exact crash)
>>>     -   assert(fabsf(dot(sd->dPdu, dPdCD)) < 1e-5f);. I do not know
>>>         (yet) what this one means.
>>>
>>>     I ring-fenced the shader from most of those
>>>     {{GitCommit|rB92030f83362fe567f78e519e0acca0700287a933}}}. Brecht
>>>     agreed to have a look at those weird NaNs, since they come from
>>>     outside our shader.
>>>
>>> -   In Phabricator's task for this project, Ronan Ducluzeau could get a
>>>     reference render without crashing. The shader returns a lot of noise
>>>     and fireflies.
>>>
>>>
>>> Next up
>>>
>>> Once we figure out why we receive bogus data from the ray intersection
>>> (and fix it), I'll be able to continue revising the shader.
>>>
>>> If possible, I'd like to get a dev build out in BlenderArtists for
>>> people to test. I don't expect to get great results yet, but it'd be
>>> great if we can ensure the hair primitive works properly. I don't have
>>> good enough bandwidth (3Mb) to upload a 200MB+ build unless I go to the
>>> uni, so I may ask either Lukas or bzztploink in IRC if they can upload
>>> them.
>>>
>>>
>>> Questions
>>>
>>> -   In re assertion above - what does it mean?
>>> -   What could be possible sources of noise in our shader? Compared with
>>>     a Diffuse shader (which doesn't use the hair primitive data), it's
>>>     obviously not working properly. I wonder if this and the other
>>>     issues are related.
>>>
>>> --
>>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/soc-2018-dev/attachments/20180527/a4cf4d91/attachment.html>