The purpose if analyzing Cycles is to understand if its approach to adding a new renderer in Blender can be used for BEER as well.
The main purpose of the analysis right now is to understand how this code is integrated into Blender itself, i.e how it is called and how it is able to access the data about the current scene in Blender and how to render it.
Secondary objective is to understand how it sets up its own data to be able to have them saved together with a .blend file
A quick overview of its source layout is available here http://wiki.blender.org/index.php/Dev:2.6/Source/Render/Cycles/SourceLayout
- Cycles is written in C++
- it consists mostly of a bunch of classes that descrive the Scene and its data and can act on it
- since it must work with CPU, GPU and network renderer codes, it has a Shader Virtual Machine that virtualizes away the rendering environment
- to be able to run across a network as a distributed renderer it seems to need (or maybe, it needed) a standalone interface, defined in intern/cycles/app/cycles_standalone.cpp that can optionally have a GUI. I don’t know if this is still current however
- the invocation of Cycles from a running Blender instance is done in intern/cycles/blender/blender_session.cpp
- Data from Blender in-memory structure is ‘converted’ to Cycles objects of class BlenderSync, using functions defined in intern/cycles/blender/blender_sync.cpp that are able to use Blender RNA structure objects to set up Cycles objects.
From existing docs on the Internal Renderer stored here http://wiki.blender.org/index.php/Dev:2.5/Source/Render/RenderBranch/CodeChanges it’s clear that this “each renderer defines its own internal data structures starting from the generic Blender ones” is standard («Conversion from Blender data structures is now usually in the same file, i.e. camera.c contains the code to convert a blender camera into a render camera.»)