[Bf-cycles] Render API

[Paulo Perbone]

Hi Brecht,

On Friday 14 March 2014 12:18:21 Brecht Van Lommel wrote:
>>> Right, we basically need a C++ SDK if external renderers want good
>>> export performance.
>>
>> Great! Any restriction on C++11? Blender is moving towards VS2013 right?
> 
> I'm not sure about this, might be OK but I would be careful about using still 
> obscure C++ features in an API.

Agreed no obscure features should be used.

>> I think it's better to start with dynamic libraries. If ok with you
>> I'll try to keep pure C++ and avoid Python as much as possible.
>
> A Pythonless C++ plugin system adds a lot of difficult design issues to work out.
> I don't need necessarily mind but the design for that would needs to be very carefully
> thought out and should match bpy where if makes sense.

I think I don't have enough knowledge of Blender's architecture to make my case here.
We can discuss further when some of my code can be used as example.

>> I understand what you mean but I still don't get it. How can we make
>> the SDK the only dependency for the plug-in to compile if we are going to use
>> RNA types? I mean, they are located in the Blender's source code tree, right?
> 
> Not really, the header file with these types is generated by makesrna from the RNA
> definitions, it is not a file in the repository. This is only used by Cycles at 
> the moment, no other Blender code uses it.

The SDK will abstract and provide all the features used here. I'm assuming this
features are kind of standards for any Renderer. But again let see how things go.

>> Just to be clear, I'm talking about for example cycles/blender/blender_session.h
>> It uses lots of RNA types (BL::RenderEngine, BL::UserPreferences, etc)
>>
>> Can we refactor Blender's source code and move all commons types into the SDK?
>> By common I mean types that both Blender and plug-ins depends on to compile.
>
> There would indeed be a few common files. I'm not sure about the exact code 
> structure, but some code refactoring could happen here to make sharing some 
> files work.

Refactoring can be trick on large code bases. Let's approach this with caution.

>> I see. Let me try to put this differently. Currently in the User Preferences we can
>> choose for example the type of Compute Device we want to use. This choice is sent way
>> down to Cycles so it can give us the list of compatible devices available. Finally
>> this list is displayed in the UI (It's not that simple I know but bear with me).
>> 
>> If I'm not mistaken this is a kind of cyclic dependency where both parts has great
>> knowledge of each other. With that in mind, how can we initialize both parts of the
>> plug-in (UI and the engine) without knowing about this cyclic dependency?
>
> It's not a dependency thing. At the time that was implemented the bpy did not support
> creating the right kind of properties, but it does now I think. Just a matter of
> Blender being sufficiently extensible.
>  
> Maybe what you mean is that any Pythonless C++ API would need the equivalent of 
> the bpy register() and unregister() functions to register types into Blender. 
> I imagine that would be called once on load, after which Blender calls into the plugin
> through functions in the subclassed RenderEngine, Operator, Panel, ... etc, just like
> the bpy does now.

The plug-in architecture I'm thinking will support service life cycle like initialize,
load/update settings, run/idle/stop/resume and shutdown (just examples). The cyclic
dependency I have in my head is difficult to explain right now. I'll come back to this
discussion later.

>> Simply put I would like to have no dependency at all between them (not explicit I
>> mean) and somehow Blender+SDK can make the IPC happens.
> 
> I'm not sure about having no dependency between them, what that means exactly. 
> IPC does not need to be a part of the API I think, that's a trick commercial 
> renderers can use to work around license issues but does not need to be a part 
> of the API itself.

I used the acronym IPC to describe the concept, the flow of information between
the plug-in and its UI. Sorry for the confusion.

> I can keep giving design advice and reviewing code as with anyone working on 
> Cycles code, not sure I would call that mentoring since I don't have the time 
> to do any summer of code kind of mentoring, but OK.

Again, just a case of poor choice of words. I wasn't talking about mentoring
as in GSoC.

>> blender-sdk.git
>> cycles.git (refactored from blender tree)
>> blender.git (refactoring branch)
> 
> I don't think we can put the SDK in a separate repository, it seems quit 
> inconvenient for commits, keeping track of this in two repositories while things 
> are in fact tightly coupled between Blender and any SDK.

Git submodules inside blender.git will do, agreed?

>> I'll need some place to stage all the code. For the time being I'll use my
>> Github repository. Is that ok with you?

> Sure.

Github for the project will be https://github.com/perbone/blender-sdk

I wish you have great vacations.
Paulo Perbone