The rate that Pixar is modernizing the engine is nothing short of impressive, and it might actually be poised to retake the crown it lost to Arnold many years back (considering that the old legacy language and reyes architecture is more or less history now).
On that, it would be wise for Autodesk to move fast if they want to protect their investment, as each new feature from Pixar would give less and less reason to spend the additional cash for it. It seems like the rendering market in general is becoming very competitive now. I can see Cycles surviving simply because it’s free for any use, but releases like this make you wonder regarding the eventual fate of solutions offered by smaller vendors (such as Indigo, Maxwell, and Thea).
You can always count on Pixar to be at the cutting edge of render research, with the added bonus of sharing some of their algorithms via online papers (so maybe some more of their technology will trickle down to Cycles).
I like how they have premade shaders and lights. It’s great to learn how to make your own, but if you’re just one guy and more an artist than a programmer, it’s a difficult thing. You can only really learn one thing at a time.
Would it be possible sometime to achieve rendered view for preview with Renderman in Blender? Do you know if this feature is planned?
I find hard to work with engines that don’t have rendered view in viewport for fast previewing.
We have a live rendered preview in “IT” the external framebuffer. I understand the desire for in Blender view, but it was not responsive enough in testing. And the benefit here is you get the viewport in one display and have the IT framebuffer in another.
Ugg you don’t need IT. it will render in Blender and the render can be saved as png etc.
Hope this render engine addon will work in Blender with out error in the future with out Maya support as that product already has support for rendering. Render to a OpenExr file, to be read back into Blender’s render result.
Cycles isn’t native to Blender, either. It takes some shortcuts, because the renderer interface is a bit poor, but at least in theory you should be able to provide the same user experience with any other external renderer.
Non-native renderers are the standard in the CG industry. Renderman isn’t native to any application and the internal renderers of Maya and Max are very poor.
It’s the other way around most people use non native render engines with other programs. Even though we don’t have a full on render api to allow for better integration once you choose Lux, Cycles, Yafaray or PRMan as you render engine in Blender it’s really painless to use and at that moment native or non-native doesn’t really matter.
In that case, it is still possible to achieve the same sort of interaction, just not at quite the same level of latency, because you need to communicate through the network or the filesystem.
Yep. There used to be a project to port the Modo renderer to Maya called Moma or something. It used TCPIP to send data back and fourth between Maya and the command line version of Modo. He even go the interactive preview to run in real time. The only latency issues were when you made drastic changes to the scene like adding objects and lights but it always recovered gracefully. Really, I think it’s totally possible to go this rout but I think a lot of developers don’t even think of it.
And yes, Cycles is a Python module just like Luxrender. I’m sure it helps that it was coded primarily by Brecht, one of the guys who knows Blender’s API the best.
Except that Cycles actually uses an API written in C, not Python (look at the commit logs for Cycles-related stuff and there’s not one .py file outside of the interface code).
