So lets get it straight:
IF someone touches the C code and also writes an IO for Blender, makes it Open source under GPL,
while getting the Renderman from Pixar SEPARATELY! Would this be ok ?
cannot COMMUNICATE ??? SHIT JUST GOT REAL ? But wait, why not communicate ? I don’t understand…
You mean that a proprietary program cannot COMMUNICATE with a GPL program at all ? If this is true, WTF ? :eek:
This can’t be true… please… :spin:
What is then for example Octane Render in Blender ? It is a proprietary renderer…
Hm … i dont understand …
Maybe some BF members could clarify more ? please…
Again the plugin/code would be open source, and Renderman installed separately from Pixar. NOT included in Blender!
Any scene data must be COMPLETELY exported to a separate format to be used with non-GPL code. NO PART of a non-GPL engine can touch ANY PART of Blender’s code or scene data. Octane gets around this with an incredibly complicated workaround using a local render server which remotely launches Octane and then hijacks the viewport drawing within Blender (thus, no border rendering, etc.). It even requires a special build of Blender. ALL of these hoops just to be able to integrate. This is by far the biggest downside to a project like Blender being GPL, and unfortunately there is absolutely nothing we can do about it short of starting a new Blender from scratch and giving it a new license.
I remember some talk about it, but is blender gonna change its licencing system? This gpl and render api stuff looks quite a problem to me. I mean, I am ignorant on the matter, but isn’t there a better licence that allows to be open source, but have more freedom when it comes to such interactions?
I seem to recall this as well. There was some sort of talk about changing blenders licensing to something better.
It can’t be done. You would have to track down EVERY SINGLE person who has ever contributed code to Blender and ask for their permission to change the license. Then, for every person who said no, you’d have to strip any code they contributed from the code base and then recreate those aspects of Blender in a different way. There have been hundreds of contributors to Blender’s code over the years, and in many cases these people don’t even have a way to contact them after nearly a decade of silence. Additionally, Ton LOVES the GPL, so it’s unlikely to change anyway. Someone with more information than myself could speculate on whether or not JUST the render API could be restructured with an Apache or MIT license (like Cycles was recently), but I’m not 100% sure.
The talk was about moving from GPL to AGPL, but that would still have these same problems or limitations.
Blender cant really move to BSD or Apache, not only because it would require too many people to agree to it but also because Blender would then become susceptible to some form of project Hijacking and Monetization. Cycles can afford to take that risk because there are a lot of healthy alternatives, Blender on the other hand has little competition at the <$300 level.
I see… still, this GPL thing is quite a limitation IMHO. I think that something that blender is lacking compared to other commercial app is the support for really good plugins, that as far as I understand, will never be integrated because of this issue.
I have wondered about that as well. Thinking raw data export and import.
@Bernardo
I don’t think its an issue of “never”, Its just the current state of affairs with how the render API works and how viewport and shader preview is achieved.
Ideally improvements to the API will allow for the integration without violating the GPL in the future.
Here is a solution “MCHammond style”:
We add a “Bake All / Prep for Render” feature to Blender, using Alembic. This data is then stored in the .Blend
We Fork Blender “Hold on, I’m not Crazy!”.
We Strip out everything like animation, modeling, rigging, texturing, everything. We then convert that to BSD/Apache “assuming its a small enough number of contributors and they agree”.
So essentially we are left with a stripped out version of Blender that only contains whats needed to view the .Blend, read the baked cache’s, lights, and shaders.
You then light your scene and render it using this hollowed out forked version of Blender.
Essentially we would be creating a version of The Foundries Katana for .Blend files.
Of course we would not have to fork Blender, someone could write/pay for a new piece of software to read .Blends and render them. It could even be done as part of the collaboration tools planned for Gooseberry. A .Blend render management tool :D.
LOL! There are certain tools I personally thought about building for Blender, but it would be way too much of a hack job to get right. Some things are far easier starting from scratch.
The communication code for the Octane plugin (the Blender side) is fully GPL, no reason that another project couldn’t use it as a starting point. I have the plugin and it’s really fast. I can adjust UV’s and see the texture move on the object in the viewport with no lag. And this is just with an old GTX460, so even with all the problems getting the plugin into Blender it’s still very nice. The Octane plugin is more based on a service model, the Octane server runs in the background (the proprietary side) and talks to the Blender plugin to update the viewport. If these other projects really want to be integrated with Blender then I don’t think there are many technical issues to stop them.
its good news but not that much of a big deal, for personal user, as someone stated before you need know how to code around the Renderman and that’s just the entry ticket, for serious user, you still need to pay for that thing, but the competition is always good, see whats happening in game engine market, who would imagine only need to pay $20 to get a high-end game engine (with complete source code) 10 years ago?
Or…
You could use a third-party lib that sits in the middle which is distributed separately and write an addon which uses this lib to talk to the renderer. I’m kind of half-ass working on a patch that uses cortex-vfx to do just this, cortex uses a combination of blender’s C++ api and boost-python wrapped classes to export and/or (eventually) import data which gets compiled into a python module that is completely independent (relatively speaking, it dynamically links to symbols in the blender binary) of blender proper.
The beauty of this is it uses python as the glue so it doesn’t have to be built into blender (or even committed into git) to work, python imports the module and resolves the missing symbols automagically (on linux at least, winders will need some patching to properly export the needed symbols due to way its linking system works) and the blender-cortex module only needs to link against the core cortex lib which is GPL-compatible. The renderer addon is the one doing the (run-time) tainting of blender with proprietary code which AFAICT is perfectly acceptable as long as it has a license that permits it.
In theory… one builds, links and distributes this blender-cortex module and then uses it to make an addon programmed against the generic cortex interfaces. Then one builds, links and distributes cortex against whichever proprietary renderer they wish to target with their addon. Easy peasy…
Haven’t really gotten around to rebuilding the cortex libs against py-3.4 so haven’t really played around with my patch for a bit but there’s probably enough work done already to get a basic RM-compliant renderer addon working if someone were so inclined.
@Uncle Entity
Hmm. Cortex looks interesting. I did some digging to find some examples and came across the “Gaffer” project. basically doing what I described earlier using the Cortex lib. They even have an example using BBB 
Its BSD so if someone implements the cortex scene cache in Blender we would have an awesome Foss method of organizing a scene ready for render in Arnold and 3Delight.
Cortex/Gaffer defiantly looks like a promising project
Here is an example scene for Elysium inside Gaffer:
Whats your opinion on using a separate program to render a RenderMan project?
Obviously it would only make sense for complex projects in a production environment but then RenderMan only makes sense for complex projects in a production environment.
so after reading this thread… I’m just going to stick with Cycles… less work. I’m not afraid to write a shader in Notepad or whatever, I just would rather not unless I need to. From the perspective of someone doing stills by themselves, it is hard to see how it would be worth it for me to use Renderman…
I want to try Renderman.
I like using octane student version. I do not like the emitters so much.
I skipped cycles I had too many problems animating.
I think having Renderman is great. Maybe it just needs some funding?
Just for some clarity, renderman is perfectly useable without talking to it direct through teh api… it’s not that much of an issue and has no licensing problems it’s why there’s rib and rsl in the first place!!!
Talking to renderman via RIB and RSL files works fine (as it’s an export to an intermediate format) and the output can be displayed in the viewport… it’s how Matt ebbs’ 3delight integration worked…
it’s a little slower than talking directly via the api but hardly a showstopper… and if it took a leaf out of the vray exporter (which also takes the same approach then you wouldn’t need to export all teh geometry every render if just tweaking lights and materials/shaders… so as an end user it’s not that different to having renderman linked natively…
writing the rib file is python and could possibly be faster as a c/c++ based exporter… which the render api could ultimately be extended to do…
the alembic idea isn’t bad either… it’s what Katana uses natively…
Ultimately this is all talk though as someone would have to do the actual work!
from an end user perspective being able to work like in cycles with a node based material renderer (like you can in Maya) that can output your shaders would be a much bigger usability improvement than using teh direct api anyway… in the grand scheme of things…
It should also be possible to get cortex to build against any of the other RM-compliant renderers with a minimum of fuss, part of the motivation behind my cortex-blender project was to get a blender–>pixie exporter going and do some pixie hacking.
Exporting to the cortex scene cache (.cob files I believe they’re called) is fairly simple. Well, until it isn’t I suppose…
Whats your opinion on using a separate program to render a RenderMan project?
Obviously it would only make sense for complex projects in a production environment but then RenderMan only makes sense for complex projects in a production environment.
I’d imagine certain stages of the pipeline wouldn’t need a full-featured 3d program to hack on shaders and/or move around lights so it’s probably a good thing – they seem happy with it at the very least – but I have a hard enough time opening up blender without it devolving into a bug-hunting session so I’m kind of scared to play around with gaffer and its fairly new codebase…