[Bf-cycles] Cycles development newbie

Lukas Stockner lukas.stockner at freenet.de
Mon Feb 12 03:38:09 CET 2018


Actually, yes, I do have some suggestions for that :)

First, you'll want to add a Shader node to Blender itself. The general 
way to do that is:
- 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.
- Add your new file in source/blender/nodes/CMakeLists.txt
- Call the register_node_* function of your new node from 
source/blender/blenkernel/intern/node.c
- Add its prototype to source/blender/nodes/NOD_shader.h
- Allocate a Node ID for it in source/blender/blenkernel/BKE_node.h
- If you have some custom element like a checkbox of an enum in addition 
to the regular node inputs:
   * Define the RNA type of your node in 
source/blender/makesrna/intern/rna_nodetree.c
   * Define a drawing function in 
source/blender/editors/space_node/drawnode.c
- Connect everything by adding a line for your node in 
source/blender/nodes/NOD_static_types.h
- Add the node to the Node editor menu in 
release/scripts/startup/nodeitems_builtins.py

Now for the node in Cycles:
- Define the node in intern/cycles/nodes.h and nodes.cpp
- Sync the node in intern/cycles/blender/blender_shader.cpp

I'd recommend to focus on the SVM implementation first and only worry 
about OSL once that works.

And of course, the actual BSDF in the kernel:
- Add a closure ID in intern/cycles/kernel/svm/svm_types.h
- Add the BSDF implementation in intern/cycles/kernel/closure/ (the 
shader seems somewhat complex, so a new file probably is best)
- Include your new BSDF file in intern/cycles/kernel/closure/bsdf.h
- Add the eval and sample functions in the switch statements in 
intern/cycles/kernel/closure/bsdf.h
- Add closure setup in the SVM interpreter in 
intern/cycles/kernel/svm/svm_closure.h

Oh, and three notes on closure implementation:
- 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.)
- The I vector in evaluation/sampling is what's usually referred to as 
wo in other renderers.
- 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.

- Lukas

On 12.02.2018 03:09, Bob Geller wrote:
> 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!
>
> Regards,
> Bob
>
> On 11 February 2018 at 19:21, Lukas Stockner 
> <lukas.stockner at freenet.de <mailto:lukas.stockner at freenet.de>> wrote:
>
>     Hi,
>
>     regarding the overall layout, there is a Wiki article
>     (https://wiki.blender.org/index.php/Dev:Source/Render/Cycles/SourceLayout
>     <https://wiki.blender.org/index.php/Dev:Source/Render/Cycles/SourceLayout>)
>     but it doesn't really say much, so here's my attempt on an overview:
>
>     Overall, Cycles can be divided into four layers:
>     - Kernel code - the computations that are executed on the chosen
>     device, doing the actual rendering
>     - Device code - handles memory management and is able to execute
>     tasks on the different compute devices by calling the kernel
>     - "Host" code - handles data synchronization to the device and
>     control flow during rendering, exposes an API
>     - Blender code - Glue logic between Blender and Cycles,
>     synchronizes data from Blender into the Cycles-specific formats
>     Of those four, the first three are independent of Blender and also
>     used in e.g. the standalone renderer.
>
>     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).
>
>     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).
>
>     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.
>
>     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.
>
>     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.
>
>     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.
>     Also, here's the wiki article on the kernel language (a bit
>     outdated unfortunately):
>     https://wiki.blender.org/index.php/Dev:Source/Render/Cycles/Kernel
>     <https://wiki.blender.org/index.php/Dev:Source/Render/Cycles/Kernel>
>
>     Generally, to get an overview of the control flow, I'd recommend
>     looking at:
>     - BlenderSession::create_session, BlenderSession::reset_session,
>     BlenderSession::render
>     - BlenderSync in general
>     - Session::run_cpu
>     - Scene::device_update
>     - CPUDevice::thread_render
>     - Session::acquire_tile
>     - kernel_path_trace
>
>     And ultimately, the best approach for figuring out control flow of
>     course always is searching and a debugger.
>
>     Hope this helps :)
>
>     - Lukas
>
>
>     On 11.02.2018 13:09, Bob Geller wrote:
>>     Hi,
>>
>>     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.
>>
>>     Regards,
>>     Bob
>>
>>
>>     _______________________________________________
>>     Bf-cycles mailing list
>>     Bf-cycles at blender.org <mailto:Bf-cycles at blender.org>
>>     https://lists.blender.org/mailman/listinfo/bf-cycles
>>     <https://lists.blender.org/mailman/listinfo/bf-cycles>
>
>
>     _______________________________________________
>     Bf-cycles mailing list
>     Bf-cycles at blender.org <mailto:Bf-cycles at blender.org>
>     https://lists.blender.org/mailman/listinfo/bf-cycles
>     <https://lists.blender.org/mailman/listinfo/bf-cycles>
>
>
>
>
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> https://lists.blender.org/mailman/listinfo/bf-cycles

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/bf-cycles/attachments/20180212/63a393b9/attachment.html>


More information about the Bf-cycles mailing list