Table of Contents

Blender to Renderman Pipeline

Blender RenderMan Artist Tools

Blender Renderman Artist Tools (or also BRAT) is a description of a suite of freely available tools to create a Blender to Renderman Pipeline in a personal or workplace environment. Highly experimental yet functional. Below are the exact specs to create this pipeline that can run optimality, assume all references to Blender is at least version 2.42.

This project is 2 years in the making and a lot of progress has been made over this time period. As of right now there the main hub of this project is located at http://blendertorenderman.org. Most recent news is posted at this location, while this wiki page is a WIP to document and compile a complete source to make a functional BtoR pipeline.

The purpose of this pipeline is not to replace existing pipelines in a full scale production environment, rather it is to compliment it and is fairly easy to incorporate into existing systems. For the most part Linux is used by these large scale houses such as Pixar, so the ability to just plug all the required tools and software would be painless. This pipeline also works for smaller houses as well as single workstation use. This also would benefit people who are interested in learning RiSpec without having to fork over thousands of dollars just yet for commercial software. Since the RiSpec is designed in such a way it is also possible to use open source along side commercial software with little effort, thus making it more appealing to the big guys.

As of time of this writing the Blender to Renderman effort has been busy developing a more solid plugin to export Blender data to RiSpec, including features like Hair (Fur) and particle data export, as well as optimizing MOSAIC to be more efficiant for faster export times. Using real test cases like content from the Big Buck Bunny movie. Small studio development in basements. Downloadable ISO with complete packages and shader sources. All towards that time when we can show the world “We can do this now too, and so can you”.

This wiki page is also intended to be the beginning of the BRAT documentation.

Base

Artist Tools

Support Tools

Developer Tools

Renderfarms

Documentation

Known issues

  1. You may encounter issues with CgKit and PyProtocols on Linux and MacOS.
  2. Neqsus is stable with everything here except Aqsis 1.2 where some new bugs have been encountered. Use the last Aqsis 1.1 build.
  3. MOSAIC is compatible with Blender 2.45+

So this is saying that you can either work with one version of Blender or another depending on the plugin you want to use.

Shader Creation tools

Shaderman, SLer and even an old tool called Shrimp can be used to visually create shaders with little effort, for those of us who do not posses great programming skills. Once your source code is exported, transfer both the source and compiled code into either the Renderman shader directory or the project directory. The choice is yours, but in some cases having mass amounts of shaders in one directory can become tedious and from within Neqsus it can become very frustrating. The need to have BOTH source and compiled shaders is required because Neqsus uses the source to access shader parameters, plus it makes it easier to edit or fix for multiple renderer's.

With MOSAIC shader compilation, all that is required is that the shader directory path is set to the correct location and you can compile all shaders within Blender.

NOTE:

Shaderman 0.7 is a Windows based shader authoring tool that is no longer maintained.

Shaderman 0.7http://www.dream.com.ua/theoldtool.html.

Shaderman.NEXThttp://www.dream.com.ua/thetool.html is the latest version that is written in Python and open source as well.

BRAT Pipeline

The BRAT pipeline works with free or open source software of course, but can run alongside commercial applications as well. This pipeline can be distributed over many workstations, or on a single computer. The key to this is centralized file storage, or at the very least easy to get to. In this case all the models, scenes, shaders and rib files are centralized and each program has paths laid out to this master directory, with the exception of the Renderman paths which point to each renderer's shader directory. This can easily be changed by making a root shader directory and pointing each renderer to that, if that is what you wish.

img0hn8.jpg

NOTE: The above image was created in 2007, before major updates and changes. The Neqsus box is now refered as the “RMAN-plugin”. A more complete and in depth graphic is in the works.

Neqsus

This is a real working Blender to Renderman pipeline that can be implemented for hobby or professional use. While the current release of Neqsus is limited to stills, work is underway for animation support and this pipeline might well be rendered obsolete then. In the meantime this pipeline can be installed on Windows and Linux, depending on what environment you are working on. Keep in mind that this is a very experimental project I am working on, there are still issues with Neqsus, the process is an involved process and in some cases certain UNIX type operating systems have problems with compiling support libraries like PyProtocols. But despite the limits this does work and it can work on different systems with a bit of tweeking.

The Blender file path should be set to the project in question, and can have any directory you wish but making a directory for models and scenes should be essential. If using textures you should place those textures into the shader directory of the project, this way when making RSL shaders these textures are easy to access and you do not have to do much to get them to work with Blender as well as Renderman. The textures should be in two formats, tiff and compiled, this way you can still use the textures in Blender for reference (as well as UV mapping) and have the same results when rendering the final frame.

pipeline_windowsfiles.jpg

Neqsus is pretty easy to get to work once all the potential installation issues have been smoothed out (Using Aqsis with Blender), and you can easily set up search paths for the shaders and textures you want to use.

pipeline_blender_001.jpg

Edited: 4/30/2007 by ShortWave/Bobby Parker

A word about shader management. It's helpful (but again not required) to manage your shaders by placing them in different directories, segregated by, for example, purpose or type. I seperate shaders based on type myself, since that's most helpful to me to keep metal shaders in one place, plastic shaders in another place, ground and/or sitework shaders (like gravel, asphalt, etc.) in another, so forth, so on. I keep all of these in a C:\Shaders or /shaders/ subdirectory on my drive, so for metal shaders, I have c:\Shaders\Metal\. To use this effectively with Neqsus, you only need to configure a extra shader search path (but don't remove the one for the renderer's bundled shaders) and check the “Recurse” checkbox. Then, when you're assigning shaders later, you'll be presented with a list of search paths to choose from, which is a very handy method of maintaining organization. Also, take note that Neqsus will include all of those search paths that you've configured from Global Settings, and put them in the .RIB file, so keep track of your shader NAMES as well, since you may have multiple “plastic.slx” files, and end up loading the wrong one due to shader path precedence.

pipeline_shaderman_001.jpg

Cutter is used often in this pipeline simply because at the moment Neqsus is buggy and often does not export light information correctly. Using Cutter you can edit the light data directly provided you are versed enough in XYZ coord values, plus you can insert any RIB functions allowed as well as edit shader values and get quick results since Cutter is linked to pretty much every well known Renderman compliant renderer available today. This also serves as an R+D tool, as you can test out different shaders, lighting placements and if you know enough about RIB syntax can create short animations.

pipeline_cutter004.jpg

The work flow is something like this. Create 3D model in Blender, then place within a set, or scene. Export the scene as is using Neqsus, no lighting data other than the default lamp. Open Cutter and start placing lights individually, all the while making quick renders making sure they are going where they are supposed to. Since Neqsus save models as Archive RIB files, the main file exported is actually quite small, this also serves for future use. Open up say Shaderman and start creating shaders for that scene in particular. Now Cutter is able to also compile shaders from within so the choice is yours to either compile by hand in command line, or open it in Cutter where if you need to change the source you have that option at hand rather than doing the process all over again in Shaderman. It depends on your skill level at sl code, but either way will result the same. This makes it easy for new users to just create, and advanced users to fine tune and improve upon. Once you get some good results within Cutter you can either render the final frame from there or you can replicate it in Blender and Neqsus.

Here is a custom RIB file for testing shaders for example. Fairly easy to use and modify should you decide to. 

# -change search paths
Option "searchpath" "shader" "C:/AQSIS/shaders:../shaders:C:/projectdata/"
Option "searchpath" "texture" "../textures"
Option "searchpath" "archive" "../archives:Cutter_Help/templates/Rib:custom_templates/Rib"
Option "searchpath" "archive" ["C:/projectfolder/CG/archives"]
Display "shadertest" "framebuffer" "rgb"
#Display "shadertest.tif" "file" "rgb"
Option "limits" "bucketsize" [32 32]
Option "limits" "gridsize" [256]
Option "statistics" "endofframe" [1]
 
 
#Format 1280 1024 1
Format 800 600 1
 
Projection "perspective" "fov" 40
ShadingRate 1
 
LightSource "distantlight" 1 "intensity" 0.1 "from" [-20 5 -10] "to" [0 0 1]
 
Translate  0 0 5
Rotate -30 1 0 0
Rotate 0   0 1 0
Scale 1 1 -1
 
WorldBegin
	LightSource "pointlight" 1
		"intensity" [1]
			"lightcolor" [1 1 1]
			"from" [10 0 0]
 
	LightSource "pointlight" 1 "intensity" 25 "from" [5 4 -1]
 
	# - Activate the next line to raytrace all objects
	# Attribute "visibility" "trace" [1]
 
	# - Activate the next line to raytrace shadows - transmission can be "transparent", "Os" or "shader"
	# Attribute "visibility" "transmission" ["opaque"]
 
	TransformBegin
		Surface "plastic"
		#Displacement "test" "Km" 0.1
		#Attribute "bound" "displacement" [0.1]
 
		#Scale 0.2 0.2 0.2
		Rotate 45.0  -20 20 0
 
		# - These are objects below, multiple kinds already coded, just commented out
 
		#Disk 0 1 360
		#ReadArchive "C:/projectfolder/CG/archives/Mesh.rib"
		ReadArchive "C:/projectfolder/CG/archives/Suzanne.rib"
 
	TransformEnd
WorldEnd

Should you choose to sort of import the settings into Blender, open the master RIB file into a Text window. There you have all the data you need, in pretty much clear format, and just start plugging in numbers in Neqsus. You don't even need to have any other window open other than those two. In Neqsus you can specify option search paths, render settings and export paths. This allows you to export all the data within a project or somewhere else on the drive. You can either export to framebuffer, or to file and then let the renderer do it's thing, or to just export the file and if you so happen to have a renderfarm, using a renderfarm manager like DrQueue you can render multiple files on a variety of machines. This will become more useful when Neqsus provides animation.

Other tools are perfectly able to help with the creation process. Ayam is a very good example of this, as it can be used to model, animate and render using a Renderman renderer. In this pipeline it could be used as an advanced shader tester, environment lighting research or procedural model creation. It is available on many platforms like Windows, Linux, IRIX, FreeBSD and OSX which allows cross platform development.

This took about a year to build, test, retest and test again. Sometimes it is quite tedious, but it does work, and can work for all skill levels. There is no automation in this process like there is with Renderman for Maya, and there might never be, but this is a start. While this exact pipeline might not serve as useful to some, such as production studios who have their own pipeline built, this is geared toward the average user or small studio with limited funds and experience.

MOSAIC

mosaic.jpg

The MOSAIC python script plugin is the newest addition to the BtoR pipeline built for Blender 2.45 and up. While the Neqsus plugin has it's own GUI system built in, the MOSAIC plugin uses Blender's GUI system instead which makes it faster to use, though it does take up a lot of screen space when all options are expanded.

The plugin is farily simple to use, as long as you have previous experiance with RiSpec, though it is also easy to learn as well. The pipeline itself is similar to the previous Neqsus pipeline, however the Cutter tool is not needed so much during the process since Cutter was originally added to aid in the shader development and not so much with final production. MOSAIC also supports animation which Neqsus does not (as far as I know), so creating a fully animated scene and rendering it with Aqsis or Pixie is possible. Animation renders should be rendered using Dr. Queue or some other renderfarm tool, though it is possible to render short scenes manually one frame at a time within Blender.

One of the best features of MOSAIC are RSL Blender shaders, which really is a shader that is functionally similar to Blenders internal shaders. In other words you can use Blender's materials and have similar results in the RenderMan render. Here is a test done to show the similarities as well as the differences.

Aqsis render.

600_450.jpg

Blender render.

600_450.jpg

One of the latest developments in MOSAIC is fur and hair, which up until recently has been impossible to export from Blender due to the limitations of the Python API retrieving particle data. The Aqsis team has been busy working on a custom DSO shadeop that works alongside MOSAIC that is able to export the particle fur almost exactly as it would be in Blender. An example of this can be seen at the top of this page.

OpenEXR

exr_logo2.jpg

http://www.openexr.com

Using OpenEXR through this whole process is an advantage, as Blender, Aqsis and Pixie can save frames in this format. Now to implement this in the pipeline in Windows as well as UNIX, we can achieve greater results in post processing, which is the main goal. Blender, Aqsis and Pixie can also save AOV information, which again in the post processing allows greater control. In the end whatever compositing application chosen is up to you.

OpenEXR's features include:

  • Higher dynamic range and color precision than existing 8- and 10-bit image file formats.
  • Support for 16-bit floating-point, 32-bit floating-point, and 32-bit integer pixels. The 16-bit floating-point format, called “half”, is compatible with the half data type in NVIDIA's Cg graphics language and is supported natively on their new GeForce FX and Quadro FX 3D graphics solutions.
  • Multiple lossless image compression algorithms. Some of the included codecs can achieve 2:1 lossless compression ratios on images with film grain.
  • Extensibility. New compression codecs and image types can easily be added by extending the C++ classes included in the OpenEXR software distribution. New image attributes (strings, vectors, integers, etc.) can be added to OpenEXR image headers without affecting backward compatibility with existing OpenEXR applications.

ILM has released OpenEXR as free software. The OpenEXR software distribution includes:

  • IlmImf, a library that reads and writes OpenEXR images.
  • Half, a C++ class for manipulating half values as if they were a built-in C++ data type.
  • Imath, a math library with support for matrices, 2d- and 3d-transformations, solvers for linear/quadratic/cubic equations, and more.
  • exrdisplay, a sample application for viewing OpenEXR images on a display at various exposure settings

pipeline_openexr_001.jpg

Cinepaint in Linux is able to work with OpenEXR files as is the Windows version called 'Glasgow'.

Working with Particles

As of right now there is no way to render animated particle systems via this pipeline, though it is possible to render points. The only way we have been able to bypass this is to render the RMan renders seperately and then use Blender to render the particle systems and then composite them in post. This has NOT been fully tested as of yet, and there are still possible issues with this method but there have been positive results rendered (just not published on the net).

Advanced RenderMan

Many new additions to the RiSpec has been done since Pixar released the specification in the late 1980's. Many of the newer features are in Pixar's PRMan and other commercial renderers like 3Delight and AIR, as well as the open source software like Pixie and Lucille. Mainly the topics of Global Illumination, Ambient Occlusion, Ray Tracing and Sub Surface Scattering.

As of right now there is the ability to ray trace in these open source renderers, though it is harder to use with the BtoR pipeline and in the long run require users to dedicate a lot of time to get to work right. These topics will not be fully covered here, one because Aqsis does NOT support ray tracing yet and the only other open source software that does is Pixie, which has it's own wiki pages devoted to these methods. SSS and AO are possible in Aqsis using tricks described by Pixar and other users of RiSpec, though again these methods are not meant for new users and are geared for users well versed in the workings of RiSpec.

It is highly recommended to read how to use these advanced methods using the tutorials found on the net and then try to incorporate them into the BtoR pipeline on your own.


Personal Tools