Help me understand how blender calls cycles

Hello there,
I have asked a similar question on blender stack exchange but sadly didn’t get an answer so I am trying my luck here. (https://blender.stackexchange.com/questions/202783/help-me-understand-the-viewport-render-pipeline-with-cycles)

Specifically I am interested in viewport rendering with cycles. As I understand it right now, the flow when updating the viewport is something like this:

  • draw_manager.c#DRW_draw_view ->
  • draw_manager.c#DRW_draw_render_loop_ex ->
  • draw_manager.c#drw_engines_init ->
  • external_engine.c#external_engine_init (cycles counts as an external engine?) ->
  • draw_manager.c#drw_engines_draw_scene ->
  • external_engine.c#external_draw_scene -> … ?RNA? … ->
  • blender_sync.cpp? (sync data?) ->
  • blender_session.cpp#draw (draw call in cycles)

I am struggeling to understand the parts in between this. How blender code calls cycles code. I can’t figure out the exact point in the code where blender calls cycles. If someone could give me an overview how blender and cycles interact with each other or could point me in the right direction, specific classes/files for example, that would be greatly appreciated.

Thank you!

Welcome to the board.

I suggest taking a less coupled view - there is a ‘separation of concerns’ which strives to keep drawing apart from rendering, and render engines play in that abstraction. You have probably noticed that there are a number of render engines, one for overlay indicia, one for workbench rendering, etc. Perhaps this page on the role that the dependency graph plays will help. This pointer may seem removed from your question, but the generation of imagery for both viewports and rendering relies on first the construction and then the evaluation of a dependency graph (‘depsgraph’). Render engines of various stripes (including cycles) then reference the depsgraph for evaluated data. Roughly then, the depsgraph sits close to the top of the data pipeline that render engines hook into; thus the depsgraph is the 800 lb. gorilla sitting in the middle of things that render engines reckon with - and influences their construction.

  1. Blender 2.8: Dependency Graph

There is a lot more nitty gritty, but I found the depsgraph discussion a useful backdrop when spelunking on this bug, about a year ago, in the overlay drawing manager. My bug reports notes are a bit raw, but perhaps will cast a little more light for you.

  1. T72490: Collections: Exclude From View toggle causes segment violation.

This bug report also does not address your question on cycles directly; it is a traversal through drawing engine code - specifically for overlays - but I am thinking that if you get a feel for drawing engines generally, you will be then better prepared with dealing with the cycles engine in the sweet fullness of time.

Hope this helps. I’m sure others will have bits on this topic.

To implement the feature you want (updating only a relevant part of the render), you only need to edit the Cycles code. Probably not even the Blender - Cycles integration should be modified.

Cycles knows which objects and geometry in the scene were modified, and has the code for clearing the render buffer. I guess you would have to add support for only partial clearing of render buffers between changes, and then apply some kind of automatic border rendering based on the bounding box of modified geometry.

That being said, I don’t think this feature is likely to be accepted in main Cycles. It’s not practical to predict the indirect effects of changing geometry and the different noise levels for different parts of the images might be rather distracting.

Thank you for your input. Its okay if its not accepted in main cycles. It’s for a university project that includes a study at the end if these changes are practical. If at the end it turns out to be impractical as you say than thats just how it is.

Thank you for the reply!

I already had a look at the Depsgrah doc, but I will study it again and have a look at that other link you provided.