Dev:Ref/Design docs/Render API/UI

From BlenderWiki

[edit] Multiple renderers, from a user's perspective

As well as providing access to a Render API from a programmer's perspective, there also needs to be a usable, standardised and reliable way of accessing these tools for artists. The point of the whole Render API exercise is integration with Blender, for Blender using artists, and this requires a seamless user experience, which the current situation of stand-alone Python scripts do not provide.

Not only are the current completely custom Python exporter GUIs completely non-standardised, with no common user interface conventions and confusing behaviour and interaction with Blender's material buttons, but technical issues plague them too such as installation procedures, problems with undo, interactivity between the 3D scene selections, visual display in a material preview or textured/shaded in the 3D View. This has a large part to play in why external renderers are currently not as heavily used as they could be with a more usable approach. The integration must be within Blender, adherent to Blender's conventions, and seamless for Blender artists to take advantage of.

[edit] Requirements

Two cases must be supported:

• Making it easy for artists to take existing scenes set for Blender's material/render system and render it in a different renderer
• Allowing artists to take advantage of the unique features of each renderer

This can be done by introducing the concept of different material/lamp/camera types. These would involve:

• A 'Blender Standard' material type - basically the Blender internal renderer's material type, and that is used in external renderers with conversion
• Renderer-specific materials, such as 'Yafray Material', 'RenderMan Material', 'RenderMan Custom Shader' that expose settings that aren't relevant to the Blender internal renderer, that are only possible to use in the specific renderer that it's designed for, and that let users fully exploit that possibilities of those renderers.

In order to support a renderer with Blender's Render API, plugin developers must support both the Blender Standard material and their own specific material types. In the case of the Blender Standard material being rendered in an external renderer, a 'Blender shader' can be written for that renderer that mimics the Blender internal renderer as closely as possible (eg. see Yafray's blendershader, or previous renderman export efforts by Jonathan Merrit).

[edit] Blender Material Conversion

Although this may possibly seem like a duplication of effort, or boring to plugin developers mainly interested in the specific features of their respective renderers, it's very important for Blender artists, especially in practical production usage.

Why?

• It provides a lowest common denominator between Blender-supporting renderers, a standard that guarantees a base level of support.
• It provides a smooth learning curve and low barrier-to-entry, for Blender artists wanting to start using a different renderer. They can re-use their knowledge of Blender's material system to a point where they're getting some results, and then as they decide to probe deeper, they can learn more about the specific features of said renderer. This is a lot easier for people to transition and experiment with than if they have to throw away all their existing knowledge and start from scratch.
• It allows artists to easily take existing scenes they've already made, library materials and setups, imported, downloaded or purchased files, and easily get them working at a reasonable level in other renderers (of course some tweaking may need to be done, but it's much better than starting from scratch)
• It allows easy transferral of scenes not only between Blender and external renderers, but also between different external renderers themselves. Even when using external renderers, for simple non-'hero' objects such as set dressing, background props with simple needs, it can be sufficient to use a Blender Standard material and rely on the conversion.

This allows easy test renders in Blender itself, either for more final things like scene composition or even things mid-project such as checking texture mapping. This can be very useful, especially if you're using a much slower renderer, eg. Indigo.

It also allows you to change between different external renderers without too much hassle. For a contrived example: you've been working on a project in Sunflow, using mostly Blender Standard materials with only a few Sunflow specific materials, and midway through, you run into some kind of bug or limitation that is blocking your work, and you make the decision to change to Yafray. In this case, you would only have to re-make the Sunflow specific materials and convert them to Yafray materials, rather than the entire scene.

In my experience working in a studio that uses Max with Vray, this is what's often done - using Max Standard materials for a lot of things, with Vray materials when wanting to take advantage of Vray features such as blurry reflections.

[edit] Crude Mockup

Here's a graphical demonstration of the UI. First, when adding a material, users can select what sort of material should be added. This could also do things like greying out materials for renderers that aren't selected to render from in the scene level menu:

For Blender standard materials, not much would look different to now. A menu would allow to convert Blender materials to other material types, trying to transfer as much info as possible (i.e. diffuse colour, shininess, etc.)

Adding a different material type would present options relevant to that renderer. It would be best for external-renderer-materials to mimic the layout of the Blender material as much as possible, to smooth the learning curve, though this isn't always possible. Whether this is implemented in C via a plugin API or Python or stored as IDProperties or whatever isn't the point here, the point is of how it should work, seamlessly integrated for artists to use.

Another possible example of an external renderer material - a completely custom renderman shader stored in a text file:

[Edit by ShortWave] Great first stab, but note that you'll have to actually support 3 (and some people would say 4, for internal/external "atmosphere") different shaders to achieve a full "Renderman material definition". Each of these individual shaders should support a preview of just that shader's effects, and the ability to list, modify, and update shader parameters for that given shader. That being said, totally on board with the idea. See this Neqsus screenshot for a partial example of this in action.