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

[Lukas Stockner]

Hi,

I'll just answer the questions here in case someone else also wants to know.


On 05/20/2018 06:49 PM, Leonardo E. Segovia wrote:
> Questions
>
> This is mostly for the sake of documentation, I'm planning to publish
> some time later a sort of "Anatomy of a Shader":
>
> -   What is the meaning of RNA and DNA in Cycles? I understand that it
>     integrates the shader's parameters with the UI. I'll be revisiting
>     this in the last weeks.
DNA and RNA are Blender-side concepts of how data is stored and
accessed. To be specific, DNA covers how the data is stored in memory
and on disk, while RNA is a layer on top of DNA that provides more
convenient access to data (for example, the type of microfacet
distribution used in the Glossy BSDF node is stored as an integer in
DNA, but is exposed as an enumeration with named entries in RNA).
In this case, the relevant types are nodes. The DNA type that's used to
store nodes is bNode (defined in DNA_node_types.h). Most of the stuff in
it doesn't really matter if you're just defining new Cycles shader
nodes, the relevant parts are custom1 to custom4 which you can use to
store properties of the Node (for example, the aforementioned Glossy
BSDF stores its microfacet distribution in custom1). If that is not
enough, you can define a custom storage struct that contains more data
(for example, the UV Map node uses a storage struct called
NodeShaderUVMap to store the name of the UV layer that it's referring to).
While all nodes are a bNode in DNA, each node has its own RNA type.
These are defined in rna_nodetree.c. Here, the high-level structure and
properties are defined and connected to the DNA equivalent. For example,
here the Glossy BSDF type is defined in def_glossy, where it creates its
"distribution" enum.
For nodes, these RNA properties are used in two places - on the one
hand, they're used to draw the node in the Node Editor (see drawnode.c
for that), and they're used to generate the C++ API that Cycles then
uses to access the node data when syncing the materials.

In the case of nodes, it's also important to mention that input/output
sockets do *not* need their own RNA/DNA properties!
> -   What is the registering flow of a shader in Cycles? I should re-read
>     {{GitCommit|rB40bc1a5cddf261bdb428a3d07819487b376a6151}} to better
>     understand it.
Cycles nodes are defined in nodes.cpp and nodes.h. Each node class
inherits from ShaderNode and defines its properties and sockets in a
static NODE_DEFINE function. Then, when syncing the materials, code in
blender_shader.cpp turns Blender nodes (accessed through the C++ RNA
API) into Cycles nodes. Cycles then runs its shader finalization
(including some cleanups, transformations and optimization passes)
before it calls the shader backend (SVM or OSL), which then compiles the
shader.
> -   What is the control flow of the sampling process in Cycles? This
>     should give me a clue on where and how our closure is being
>     Diffuse'd.
After hitting geometry, Cycles calls shader_eval_surface which executes
the relevant shader (I'll assume the SVM backend is used here). This
then calls the SVM interpreter in svm.h, which executes the compiled
shader. This shader will set values, read from textures etc. and
eventually run Closure instructions that are processed in
svm_node_closure_bsdf. There, the corresponding closure is allocated and
initialized.
This shader evaluation results in a list of closures. Then, Cycles will
sample a lamp/meshlight and evaluate the value of all closures for the
outgoing direction towards the lamp (bsdf_eval). After that, Cycles will
pick a random closure according to their weights (shader_bsdf_pick),
sample it (bsdf_sample) to get an outgoing direction and then evaluate
all additional closures to get the total BSDF value for the sampled
direction.
The control flow for branched path tracing is a bit more complex, but if
the regular case works, BPT should work as well.

- Lukas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pEpkey.asc
Type: application/pgp-keys
Size: 1774 bytes
Desc: not available
URL: <http://lists.blender.org/pipermail/soc-2018-dev/attachments/20180520/713c0f31/attachment.key>