[Bf-cycles] Render API

[Brecht Van Lommel]

Hi,

On Friday, March 14, 2014, Paulo Perbone <pauloperbone at yahoo.com> 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.

> It would be good to support a plugin interface with support for
> > loading dynamic libraries. However this is not necessarily needed to
> > start, it is also possible to use Python scripts and let those scripts
> > load Python extensions that then access the Blender API. Without this
> > Python bridge the code would be cleaner though.
>
> 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 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.

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.

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.

Simple 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 completely understand what you mean. I just think that it all depends on
> how
> the UI vs engine dependency thing (as put above) will works out. Am I
> wrong?
>
> So... If you're willing to we can keep this mentoring but I would like to
> start
> coding. I'm thinking some thing like this for the repository tree:


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.


> 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.


> 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.

Brecht.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20140314/e98ff00d/attachment.htm