User:LeonardoSegovia/GSoC 2018/Proposal

= Implementing a Hair Shader for Cycles =

Name
Leonardo Emanuel Segovia

Contact details

 * Email: [mailto:leonardo.segovia@cs.uns.edu.ar leonardo.segovia@cs.uns.edu.ar]
 * IRC: amyspark
 * Website: https://www.amyspark.me

Synopsis
Realistic hair or fur is essential when creating a plausible virtual world. In feature animation, this is often used to define the signature look of characters; examples include Pixar’s Brave (Iben et al. 2013), and Walt Disney Animation Studios’ Tangled (Sadeghi et al. 2010; also Ward et al. 2010) and Zootopia (Chiang et al. 2016).

Currently, Cycles has a working hair shader (wiki page, sources), based on Marschner et al. (2003)’s model. Its several assumptions and simplifications make it inaccurate for light colored hair (d’Eon et al. 2011) as well as for most types of fur (Yan et al. 2015). Furthermore, d’Eon et al. (2011) and Khungurn and Marschner (2017) demonstrated it to not be energy conserving.

This project intends to upgrade Cycles’ hair shader to the aforementioned Zootopia shader by Chiang et al. (2016), by porting Pharr (2017)’s implementation. Lukas Stockner has made available a WIP patch, which may also serve as a basis for this work.

Benefits
By having this functionality, the Blender community will be able to render physically accurate, production-level quality hair without resorting to proprietary engines such as RenderMan.

Deliverables
The delivered shader implementation should be expected to include:


 * the node itself (in SVM as well as OSL)
 * node-UI bindings
 * energy conservation tests i.e. white furnace test
 * formal verification tests i.e. correctness of the mathematical primitives
 * Blender-Wiki documentation
 * developer documentation

Shader Implementation
Cycles shader nodes are implemented using one of the following choices:


 * simply using a custom Open Shading Language node;
 * these are only usable with CPU renders
 * direct C++ implementation via SVM and OSL (in the sections below).
 * these are available for both CPU and GPU

Anatomy of a Shader
The layout of a Cycles node is as follows (guidance taken from here:

General primitives
Cycles’ mathematical primitives are contained in.

Shader closure
Cycles’ BSDF closures are defined in. These define the primitives that will be used later by the chosen shader backend.

Shader implementation
Cycles has two backends available for direct shader implementation.

The first is the Open Shading Language (OSL, ). These kind of shaders are only usable in the CPU. To implement them, the shader’s closure must be registered first in, which makes the necessary functions available for use by the shader itself.

A similar workflow is followed by the Shader Virtual Machine (SVM, ). Shaders implemented using the SVM can be used in both CPU and GPU renders. In this case, the shader’s BSDF components must be registered in, and then the closure is evaluated in the interpreter loop at.

Blender UI registration
New Cycles shader nodes need to be made available to Blender’s UI. This is implemented in the files at, while the general registration calls are available at.

The registration logic includes:


 * implementing node sockets i.e. input and output parameters;
 * registering the shader itself with the GPU kernel.

After implementing the shader, the workflow would be as follows:


 * create and implement the registration logic in ;
 * reserve a new shader ID at  and register it at.
 * declare the new registration function in  and call it from   in.

Verification
Blender employs two types of testing:


 * unit tests, in
 * regression tests, implemented as reproducible scenes

From a technical point of view, Pharr’s implementation already includes:


 * a white furnace test to ensure energy conservation
 * a statistical test to verify correctness of the custom primitives.

These should be easily ported to Cycles’ unit test framework. As an addition, I can also repurpose the existing hair tests to suit the new shader.

Optimization
Pharr’s implementation comes out-of-the-box with several customized, high performance primitives e.g.  and. They are all defined in terms of C++ standard functions, so there should be no need to change them.

Further optimization could be done with flame graphs and Perfview in Windows (the platform I’m most experienced with). For the GPU version, I could profile it with Nvidia Nsight Visual Studio Edition’s Heads-Up Display.

In addition to the above, I should also test the shader’s:


 * compatibility with different types of lights (point, area, etc.)
 * compatibility with importance sampling mechanisms
 * sampling noise results.

I expect to have testing builds available, if possible via Blender’s experimental-buildbot to receive and act on early feedback.

Documentation
We divide the shader documentation in two:


 * developer documentation: I expect the implementation to be self-documented simultaneously with the coding. There is also very little documentation on Blender’s node architecture as well; I can produce blog posts providing further insight on this.
 * Blender-Wiki documentation: apart from the obvious adjustments to the wiki page, I suggest to make the shader’s theoretical background more explicit. A link to the paper, as well as a bit of theoretical background (for those more technically inclined) would suffice.

Project Schedule
Weeks are measured from Mon-Sun to align with GSoC’s Coding Period start date.

These are my university’s holiday dates as well (link in Spanish).

School conflicts
I have the following fixed commitments during the GSoC coding period. The timetable is given in GMT-3:


 * French classes
 * Tue &amp; Thu 1800-2000
 * Postgraduate course “Digital Image Processing”
 * Thu 1230-1400
 * Fri 0800-1000

Any new commitments will be reported and coordinated with my assigned mentor as soon as possible.

Bio
Hi all! My name is Leonardo, and I am a 25-years-old student of the MSc in Computer Science (Spanish: Magister en Ciencias de la Computación), at the Universidad Nacional del Sur in Bahía Blanca, Argentina. Previously, I got my BSc in Computer Science in December 2016 from the same university, with a thesis in collision detection and handling in the Unity engine (see Selzer et al. (2017)).

My coding experience has already involved working with large code bases: I have contributed several patches to the Krita painting suite and the Mitsuba renderer (C++, LaTeX), and Homebrew as well (Ruby). Thanks to these projects, I am familiar with all operating systems in which Blender runs (Linux, MacOS, Windows). I have also picked some knowledge of OpenGL and CUDA from university courses.

I would love to do this project for two reasons. The first one is that, as part of my MSc thesis (started Aug 2017), I planned to implement one of Disney or Pixar’s shaders in an open source rendering engine. I never expected to see this very same idea proposed for GSoC 😂 ! The second reason is that working with people from around the world, in a production-level rendering engine, would be an invaluable experience for me as well as for my university.