Dev:Ref/Requests/Render API

Introduction

During project Orange, pretty much all of the old rendercode was rewritten from scratch, resulting in a much better/more coherent framework. However, this also meant that the YafRay integration code (that was pretty much "hacked" on top of Blender) had to go.

Now it seems like a good API for external renderers is in place, especially since people have been experimenting with a whole bunch of external renderers (after YafRay was wrongfully declared dead by some). Here's a list of some renderers that got a lot of attention lately:

• POVRay - Good old POV-Ray got a lot of attention because Ramon Carlos Ruiz (RCRuiz) integrated POV-Ray into 2.41, using the YafRay integration code as a base for his work. elYsiun thread but, of course, the old Povanim script exporter worked also since five long years with Megapov 0.7, Megapov1.0 and POV-Sub too. elYsiun thread.
• YafRay - Contrary to popular believe, YafRay is not dead. Actually, 0.0.8-2 (these guys need to get better versioning :o)) is a very good renderer. Lynx3D started working on his own renderer, which might or might not become the new YafRay. Still a very popular renderer mostly because of it's integration with Blender in the past. forum
• Aqsis - RenderMan compliant renderer. ShortWave is working on a python script that uses a custom GUI library to be able to export from Blender. BtoR project page
• Indigo - Pretty new, unbiased renderer by Nicholas Chapman (windows only atm). Ewout and several others have been working on a simple python export script. forum
• Sunflow - Java based GI rendering system. Has quite a good python exporter (with many options, that is). elYsiun thread
• Kerkythea Standalone renderer, very fast GI. Available for Linux & Windows. script exporter, Blender2KT exporter forum, elYsiun thread

Render API wishlist

All of these renderers have to export their meshes, rendersettings & materials one way or another. Currently the only way to do this is via a python script. This is not at all optimal - the Draw function (GUI programming) is very buggy, and still the integration is a bit primitive. What is needed is a good level of abstraction that can be utilised by an external plugin. It also seems that mesh exporting is the smallest problem to overcome (even though there's a lot of room for improvement here! Try exporting a mesh that's subdivided at renderlevel WITH all other things like bone deformation, modifiers etc. applied!). The biggest challenge here is the material system, and being able to give meaning to some renderer specific features inside blender (DOF, special lamp types etc.).

I've tried to make a list of what I think is needed for a good render API:

• Proper level of abstraction - communication between renderer (or render-exporter) and Blender should be straightforward (unlike the way textureplugins are currently implemented, for example)
• C-API - In a lot of cases, a python script is not very convenient. Integration on the level YafRay used to be is what we should aim for (if not better), but this is difficult at best. If YafRay was updated in the past, Blender could not be adjusted to that untill the next Blender release. This makes third parties too much dependent on Blender itself. If it was a plugin, you could just update the dll and continue happily. Updating (and maintaining!) becomes much easier this way.
• Custom properties - to be able to save render & material settings (and more), it's very important to have a good definition of some kind of 3rd party storage place. Attaching renderer specific properties to any element inside Blender should be possible.
• Enabling/disabling GUI panels - In some cases (especially Aqsis), Blender's material system has no meaning at all for an external renderer. This should be reflected in the UI by some kind of change. It would be ideal if the renderer could 'create' new panels in the UI, with it's own settings, but also disabling non-relevant panels AND options. For example, there's no point in having a 'threads' button if this function is not available for that renderer. This goes to a certain level of course, you can't expect Blender to fully adapt to the abilities of an external renderer, but at least panel creation/hiding should be supported. This doesn't mean all these settings are lost btw, they are just switched off (or on) when the user switches renderer. This means an object could contain a material in Blender Internal that's completely different from a material in Aqsis for example!
• Support for custom lamp types (and perhaps other custom objects/primitives too!) - Not every renderer supports every lamp type Blender has, but sometimes a renderer even has more lamp types. The plugin should be able to add something like this to the UI (and the scenedata of course), and give it some meaning. DOF representation was already mentioned, but there are many other types of things. This is an extendability problem that perhaps surpasses the current scope of things...
• Previewrender by the external renderer - especially useful for materials that are completely different from Blender's.

Of course, ideally Blender's internal renderer would be treated the same way the external renderers are treated: with the same api & abstract communication. This would force Blender to be a framework that's less dependent on the renderer and this would indeed make Blender much more suitable for integration in existing production pipelines!!! --Ewout 12:53, 8 April 2006 (CEST)