Hi,<br><br>On Friday, March 14, 2014, Paulo Perbone <<a href="mailto:pauloperbone@yahoo.com">pauloperbone@yahoo.com</a>> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> Right, we basically need a C++ SDK if external renderers want good<br>
> export performance.<br>
<br>Great! Any restriction on C++11? Blender is moving towards VS2013 right?</blockquote><div> </div><div>I'm not sure about this, might be OK but I would be careful about using still obscure C++ features in an API.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> It would be good to support a plugin interface with support for<br>
> loading dynamic libraries. However this is not necessarily needed to<br>
> start, it is also possible to use Python scripts and let those scripts<br>
> load Python extensions that then access the Blender API. Without this<br>
> Python bridge the code would be cleaner though.<br>
<br>
I think it's better to start with dynamic libraries. If ok with you<br>
I'll try to keep pure C++ and avoid Python as much as possible.</blockquote><div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I understand what you mean but I still don't get it. How can we make<br>
the SDK the only dependency for the plug-in to compile if we are going to use<br>
RNA types? I mean, they are located in the Blender's source code tree, right?</blockquote><div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Just to be clear, I'm talking about for example cycles/blender/blender_session.h<br>
It uses lots of RNA types (BL::RenderEngine, BL::UserPreferences, etc)<br>
<br>
Can we refactor Blender's source code and move all commons types into the SDK?<br>
By common I mean types that both Blender and plug-ins depends on to compile.</blockquote><div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I see. Let me try to put this differently. Currently in the User Preferences we can<br>
choose for example the type of Compute Device we want to use. This choice is sent way<br>
down to Cycles so it can give us the list of compatible devices available. Finally<br>
this list is displayed in the UI (It's not that simple I know but bear with me).<br>
<br>
If I'm not mistaken this is a kind of cyclic dependency where both parts has great<br>
knowledge of each other. With that in mind, how can we initialize both parts of the<br>
plug-in (UI and the engine) without knowing about this cyclic dependency?</blockquote><div><br></div><div>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.</div>
<div> </div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Simple put I would like to have no dependency at all between them (not explicit I mean)<br>
and somehow Blender+SDK can make the IPC happens.</blockquote><div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I completely understand what you mean. I just think that it all depends on how<br>
the UI vs engine dependency thing (as put above) will works out. Am I wrong?<br>
<br>
So... If you're willing to we can keep this mentoring but I would like to start<br>
coding. I'm thinking some thing like this for the repository tree:</blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
blender-sdk.git<br>
cycles.git (refactored from blender tree)<br>
blender.git (refactoring branch)</blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'll need some place to stage all the code. For the time being I'll use my<br>
Github repository. Is that ok with you?</blockquote><div><br></div><div>Sure.</div><div><br></div><div>Brecht. </div>