<p dir="ltr">This effort should be formatted for the Wiki.</p>
<p dir="ltr">With respect,<br>
TJS</p>
<br><div class="gmail_quote"><div dir="ltr">On Sun, Feb 11, 2018, 6:40 PM Lukas Stockner <<a href="mailto:lukas.stockner@freenet.de">lukas.stockner@freenet.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<p>Actually, yes, I do have some suggestions for that :)</p>
<p>First, you'll want to add a Shader node to Blender itself. The
general way to do that is:<br>
- Add a file for your node in source/blender/nodes/shader/nodes/ -
just copy the file of some other BSDF node that is somewhat
similar and adapt it. I'd suggest to ignore the GPU/GLSL stuff for
the first test, you can always add that later.<br>
- Add your new file in source/blender/nodes/CMakeLists.txt<br>
- Call the register_node_* function of your new node from
source/blender/blenkernel/intern/node.c<br>
- Add its prototype to source/blender/nodes/NOD_shader.h<br>
- Allocate a Node ID for it in
source/blender/blenkernel/BKE_node.h<br>
- If you have some custom element like a checkbox of an enum in
addition to the regular node inputs:<br>
* Define the RNA type of your node in
source/blender/makesrna/intern/rna_nodetree.c<br>
* Define a drawing function in
source/blender/editors/space_node/drawnode.c<br>
- Connect everything by adding a line for your node in
source/blender/nodes/NOD_static_types.h<br>
- Add the node to the Node editor menu in
release/scripts/startup/nodeitems_builtins.py</p>
<p>Now for the node in Cycles:<br>
- Define the node in intern/cycles/nodes.h and nodes.cpp<br>
- Sync the node in intern/cycles/blender/blender_shader.cpp</p>
<p>I'd recommend to focus on the SVM implementation first and only
worry about OSL once that works.</p>
<p>And of course, the actual BSDF in the kernel:<br>
- Add a closure ID in intern/cycles/kernel/svm/svm_types.h<br>
- Add the BSDF implementation in intern/cycles/kernel/closure/
(the shader seems somewhat complex, so a new file probably is
best)<br>
- Include your new BSDF file in
intern/cycles/kernel/closure/bsdf.h<br>
- Add the eval and sample functions in the switch statements in
intern/cycles/kernel/closure/bsdf.h<br>
- Add closure setup in the SVM interpreter in
intern/cycles/kernel/svm/svm_closure.h<br>
</p>
<p>Oh, and three notes on closure implementation:<br>
- Closures in Cycles return f(wo, wi)*cos_theta_i, not just f(wo,
wi) as it's done in most other renderers I've seen so far (pbrt,
Mitsuba etc.)<br>
- The I vector in evaluation/sampling is what's usually referred
to as wo in other renderers.<br>
- For debugging, you can just not return SD_BSDF_HAS_EVAL from the
setup, this will cause Cycles to not call your eval function and
not do any light-sampling/bsdf-sampling MIS. Of course, that might
cause excessive noise with diffuseish materials and sharp lights.<br>
</p></div><div text="#000000" bgcolor="#FFFFFF">
<p>- Lukas<br>
</p></div><div text="#000000" bgcolor="#FFFFFF">
<div class="m_3460790945256124640moz-cite-prefix">On 12.02.2018 03:09, Bob Geller wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Thank you so much Lukas for the detailed email. It
has definitely helped clear up a few things. Using a debugger
was going to the next option but I thought I'd ask the experts
first. I will do so anyway and pop any questions on this group
if I need any more help. I'm looking to add more BSDFs to the
Cycles engine as that forms most of the interest like the Irawan
& Marschner woven cloth shader that I see is missing. Any
suggestions on adding BSDFs other than the normal closure and
osl shader additions? Anyway, hopefully I can get a handle of
the code-base quickly and get cracking. Hope you have a great
day! Thanks again!
<div><br>
</div>
<div>Regards,</div>
<div>Bob</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 11 February 2018 at 19:21, Lukas
Stockner <span dir="ltr"><<a href="mailto:lukas.stockner@freenet.de" target="_blank">lukas.stockner@freenet.de</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"> Hi,<br>
<br>
regarding the overall layout, there is a Wiki article
(<a class="m_3460790945256124640m_-4473188139278102874moz-txt-link-freetext" href="https://wiki.blender.org/index.php/Dev:Source/Render/Cycles/SourceLayout" target="_blank">https://wiki.blender.org/index.php/Dev:Source/Render/Cycles/SourceLayout</a>)
but it doesn't really say much, so here's my attempt on an
overview:<br>
<br>
Overall, Cycles can be divided into four layers:<br>
- Kernel code - the computations that are executed on the
chosen device, doing the actual rendering<br>
- Device code - handles memory management and is able to
execute tasks on the different compute devices by calling
the kernel<br>
- "Host" code - handles data synchronization to the device
and control flow during rendering, exposes an API<br>
- Blender code - Glue logic between Blender and Cycles,
synchronizes data from Blender into the Cycles-specific
formats<br>
Of those four, the first three are independent of Blender
and also used in e.g. the standalone renderer.<br>
<br>
When you hit F12, Blender internally starts a rendering
job (not going into details here). Effectively, it ends up
calling functions in the Cycles addon (blender/addon/, all
paths relative to intern/cycles/). These in turn call the
Cycles Python API (as defined in
blender/blender_python.cpp), which wraps the
BlenderSession (in blender/blender_session.cpp).<br>
<br>
This Blender session allocates a Cycles Session
(render/session.cpp) and Scene (render/scene.cpp) and then
fills the Cycles-internal scene representation (consisting
of Shaders, Meshes, Lights etc., all defined in render/
and part of the Scene class) from Blender-internal data
through the code in BlenderSync
(blender/blender_sync.cpp).<br>
<br>
Then, it calls the Session to start the rendering. The
Session in turn calls the internal Scene synchronization,
which then loops over all the components of a Scene and
calls their device_update functions, which are responsible
for converting the internal host representation into the
format that the kernel expects. Once that is done, it
divides the image into tiles (render/tile.cpp) and then
starts a DeviceTask (device/device_task.cpp) for
rendering.<br>
<br>
The device (device/device_{cpu, cuda, opencl, multi}.cpp)
then calls the acquire_tile callback of the task, which
makes the Session return tiles to render. Then, it calls
the rendering kernel for that particular device until the
tile is finished, and goes back to acquiring another tile
until they're all rendered.<br>
<br>
In the kernel, most of the code is shared between devices,
which means that we can only use the common subset of C++,
CUDA and OpenCL (which is generally the limiting factor).
To archieve this, whenever any language needs a particular
keyword, a ccl_ keyword is defined. Then, for each of the
three languages, these ccl_keywords are #defined to the
proper keywords in kernel/kernel_compat_<device>.h.
For example, CUDA requires each function that's supposed
to be executed on the GPU to be prefixed by __device__.
Therefore, we have the ccl_device keyword, which gets
#defined to __device__ for CUDA and to nothing for CPU and
OpenCL. This is all there is to the "cycles compute
language" - it's essentially just a bunch of defines that
allows to write code that compiles in all three languages.<br>
<br>
As a result, for many changes you can completely ignore
the fact that your code will also be compiled on GPUs. The
main downside is that it completely screws up code
completion in most IDEs.<br>
Also, here's the wiki article on the kernel language (a
bit outdated unfortunately): <a class="m_3460790945256124640m_-4473188139278102874moz-txt-link-freetext" href="https://wiki.blender.org/index.php/Dev:Source/Render/Cycles/Kernel" target="_blank">https://wiki.blender.org/index.php/Dev:Source/Render/Cycles/Kernel</a><br>
<br>
Generally, to get an overview of the control flow, I'd
recommend looking at:<br>
- BlenderSession::create_session,
BlenderSession::reset_session, BlenderSession::render<br>
- BlenderSync in general<br>
- Session::run_cpu<br>
- Scene::device_update<br>
- CPUDevice::thread_render<br>
- Session::acquire_tile<br>
- kernel_path_trace<br>
<br>
And ultimately, the best approach for figuring out control
flow of course always is searching and a debugger.<br>
<br>
Hope this helps :)<br>
<br>
- Lukas
<div>
<div class="m_3460790945256124640h5"><br>
<br>
<div class="m_3460790945256124640m_-4473188139278102874moz-cite-prefix">On
11.02.2018 13:09, Bob Geller wrote:<br>
</div>
</div>
</div>
<blockquote type="cite">
<div>
<div class="m_3460790945256124640h5">
<div dir="ltr">Hi,
<div><br>
</div>
<div>My name is Bob and I'm trying to get into
cycles development to hopefully contribute in
the future. Is there any documentation to
understand the system better and especially
understand the flow of control in the renderer?
Also, I'm struggling to find enough info about
cycles kernel development and the cycles compute
language. I would appreciate if someone can
point me in the right direction to help
understand this better. Thank you for your time
and sorry for mailing the whole group, I wasn't
sure who to contact. </div>
<div><br>
</div>
<div>Regards,</div>
<div>Bob</div>
</div>
<br>
<fieldset class="m_3460790945256124640m_-4473188139278102874mimeAttachmentHeader"></fieldset>
<br>
</div>
</div>
<pre>_______________________________________________
Bf-cycles mailing list
<a class="m_3460790945256124640m_-4473188139278102874moz-txt-link-abbreviated" href="mailto:Bf-cycles@blender.org" target="_blank">Bf-cycles@blender.org</a>
<a class="m_3460790945256124640m_-4473188139278102874moz-txt-link-freetext" href="https://lists.blender.org/mailman/listinfo/bf-cycles" target="_blank">https://lists.blender.org/mailman/listinfo/bf-cycles</a>
</pre>
</blockquote>
<br>
</div>
<br>
_______________________________________________<br>
Bf-cycles mailing list<br>
<a href="mailto:Bf-cycles@blender.org" target="_blank">Bf-cycles@blender.org</a><br>
<a href="https://lists.blender.org/mailman/listinfo/bf-cycles" rel="noreferrer" target="_blank">https://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
<br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="m_3460790945256124640mimeAttachmentHeader"></fieldset>
<br>
<pre>_______________________________________________
Bf-cycles mailing list
<a class="m_3460790945256124640moz-txt-link-abbreviated" href="mailto:Bf-cycles@blender.org" target="_blank">Bf-cycles@blender.org</a>
<a class="m_3460790945256124640moz-txt-link-freetext" href="https://lists.blender.org/mailman/listinfo/bf-cycles" target="_blank">https://lists.blender.org/mailman/listinfo/bf-cycles</a>
</pre>
</blockquote>
<br>
</div>
_______________________________________________<br>
Bf-cycles mailing list<br>
<a href="mailto:Bf-cycles@blender.org" target="_blank">Bf-cycles@blender.org</a><br>
<a href="https://lists.blender.org/mailman/listinfo/bf-cycles" rel="noreferrer" target="_blank">https://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
</blockquote></div>