Well… The title says it. Discuss
Python RenderEngine could use an example of how to draw objects in the viewport preview, like they are seen in regular viewport:
http://www.blender.org/documentation/blender_python_api_2_69_release/bpy.types.RenderEngine.html
i am no lawyer, but as far as I know, anyt plug like that would be required to be under the GPL.
http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#GPLAndPlugins
Pretty sure you can already do this and deposit the rendered image into the material preview window thingie.
On a somewhat sidenote, if one were to implement a renderer exporter in C/C++ on top of cortex-vfx’s IECore::Renderer interface and left it up to the end user to link the cortex libs against against Arnold, 3Delight, whatever, then it shouldn’t be too big a deal to get Cycles level integration for non-BF anointed renderers. This of course assumes the BF would let someone add code that links to a BSD’d lib that links to proprietary code and would almost certainly be a non-default, non-release compile time option for proprietary renderers due to the whole GPL thing.
Oh, and sidenote #2 – blender does indeed have a C++ api around RNA it’s just nobody but Brecht uses it since it’s hidden way down in the generated files inside the makesrna build directory. IIRC trying to use it was partially responsible for The Makefile Incident that completely blew away my /home directory and caused me to lose a bunch of stuff 
Lets for the sake of clarity for this discussion just assume the licensing concerns could be solved. I really genuinely want to know what people want and not get sucked into a licensing discussion.
I think Mikes list is a really good starting point.
- Should blender just try to dlopen .so/dll/dylibs in a plugins directory ?
- How would this impact long term RNA evolution as blender seems to continue to evolve ?
Isn’t the octane version of Blender already a version specialised for 3rd party renderer? Their octane renderer is closed source too and neither Ton nor the FSF said anything againt it, so it’s legal. I’m happy Blender finally gets official 3rd party C++ plugin support, but isn’t the work already done?
As someone who spent the better part of two hours just getting the new BlenderOctane implementation working yesterday, I will point out that this is NOT an acceptable solution to integration. It requires you to download and run two different executables in addition to a special version of Blender (currently stuck at 2.68) just to get any kind of results, and as far as I could tell the integration was still incomplete.
Blender needs a real, robust render API that doesn’t require hacking the code to pieces and headache inducing workarounds or painfully slow python links just to play ball.
All of these things are basically possible, except that you have to do it in Python now. There’s a few limitations and things that could be improved, but in general materials, render buffers, viewport render, detecting changes are all part of the API and being used by Cycles.
Currently the situation is that you would have to create a Python addon and put the glue code in there. In principle it could all be done in C++, but then you do need support for some sort of dynamic library loading system and add the ability to subclass e.g. the RenderEngine class in C++. Passing the pointers from Python to C works but is not particularly elegant. I think dynamic library loading and subclassing is are things that would be nice once the basic API is working.
Compatibility is an issue, and it’s going to be difficult to avoid API breakage entirely as the Blender design changes. There needs to be some plan to deal with this kind of thing, certainly some #defines for the API version but probably more. Part of the problem is that Blender has a quick release cycle compared to other 3D apps and that a lot of users are using the daily builds, so plugins would need frequent updates to keep up.
Regarding the GPL license issue, as far as I know the Blender Foundation has not made any official statement about that.
My personal opinion on that is that it’s just not clear from the GPL license, it’s very much open to interpretation. The FSF interpretation from their FAQ seems to be that you can do it as long as the non-GPL compatible code runs in a separate process. This is what the Octane plugin does I think, sending data back and forth with sockets.
Giving just the API a different license does not help as far as I know (if you could do that you could slap an API on any GPL code and use it however you want, that doesn’t seem right). Making some GPL exception also seems unlikely at this point given the number of contributors you would need to get permission from.
Anyway, I will leave that for others to figure out. From a Blender API design point of view I don’t see much point in trying to implement some system to e.g. send data to another process with sockets. If commercial renderers want to do this they can implement it on top of a C/C++ API, there’s not much reason to let Blender developers do that when their time is already the bottleneck here.
Some better examples showing how to install GLSL shaders into the viewport to try and leverage accelerated rendering.
For example: I want to playblast (OpenGL render) my scene but I want it rendered from the viewport using SSAO. All this without having to launch the game engine.
Having a C++ plugin DLL loaded directly by Blender sounds like a nightmare when I think of how much fuzz we’ve had tracking the Python side of things. At least it’s relatively easy to track API changes with Python, and it avoids us having to do full new builds every week.
It’s been a while since I worked on LuxBlend, but from what I can gather the major time-sinks in the export is getting mesh data out, and render results back. Both of these should be solvable using a Buffer Protocol scheme so that Python can remain the glue, from what I can gather.
In addition, better pynode support would be nice. IIRC there’s still some things we can’t do (such as a custom color ramp-like node).
You’re probably right about licensing. Unfortunately, being stuck with a python bridge is quite painful due to the slowdowns associated with it. A socket or shared mem interface to a separate process actually isn’t all that bad. If you have a good RPC interface, it can be fast, and it also has the advantage that a crashed renderer doesn’t have to take Blender itself down. IIRC that is how Katana works with external renderers, and I think Houdini is pushing to do the same thing. So maybe this isn’t such a bad approach after all.
A separate process approach also could fairly easily be developed without having to bug the Blender developers, but at some point Blender itself has to provide the other side of the connection with plenty of speed, e.g. compiled in. That requires the communication process also be GPL, which is probably just fine. That forces whoever develops the bridge to open source the side of it that lives in Blender, and for the devs to incorporate that interface into Blender itself. If the interface is robust to changes and function/structure availability and handles that in stride, that could also solve the issue of dealing with fast internal Blender changes.
Thoughts?
I agree about the difficulty of keeping parity; I remember trying to update RenderSpud’s python interface for Blender at each version, and it was generally fairly unclear how to match the changes. I had to go look at other renderer integrations to figure out how to make mine match, and it seemed a bit arbitrary. Hopefully things have settled down a bit in that regard.
One reason why this happens is that the DNA/RNA/python bindings are a very close reflection of the Blender internal structures themselves. Generally API design requires that the API become an insulating layer between internal changes and external usage, and API changes that break external usage are relegated to major version updates (this is how Arnold does it, for example, as at its core Arnold is really just an API around the internal renderer).
Creating a more stable interface is a huge project, however. There might be intermediate steps that can go a long way towards API stability without locking down the RNA-like layer, though.
The general idea of doing inter process communication, and having the Blender process part GPL licensed seems right.
However, the way I envisioned it is that the RNA C/C++ API would be finished, which gives fast access to all of this data that is available through Python now. Then addon developers for commercial renderers would be able to build an inter process bridge using that API, instead of built directly into Blender.
If someone steps up to develop or fund such an inter process render API that is built directly into Blender and maintained as part of Blender development, that could work. Without that I think the simpler solution (from the point of view of Blender developers) of reusing the same API that they already maintain is more likely to succeed.
Yeah that sounds like a good way.
I was actually thinking the IPC bridge would actually use the C/C++ RNA API, but maybe do some clever things to make it so that API changes are gracefully handled so as to reduce churn on the renderer side. Now, how to do that properly is probably hard, but then again it might work out okay. I also think having third party renderers state that they are compatible with X and Y versions of Blender, and they update their side of the bridge for version Z when they get around to it is also reasonable. Users of said renderers will apply pressure to stay up-to-date with newer versions of Blender as needed. If the bridge is reasonably resilient with respect to version changes, some of the updates will just work (or mostly work) anyway.
But it remains to be seen how this would all work in practice; I think we’d have to try it out and see what happens.
Renderer1 doesn’t even ask Blender, penetrates Blender’s code and makes a child without approval.
Renderer2 ask kindly a way to communicate, that could lead to many other communication and create a nice ecosystem where artists could be free to choose with which tool they create. Blender says it sounds good but… it’s too hard to be stabil ??? To young or is it time to become an adult?
I’m not entirely sure what I think of this analogy. :rolleyes: Generally speaking interfacing code together doesn’t strike me as very sexual. But point taken. I rather think the consensual, commitment approach is quite superior. 
Sorry if I schocked anyone, but I think it will be better if devs of both sides come to a florishing symbiosis. Thanks Mike for making a step in the right direction.