MOSAIC progress report on BBB related changes

Greetings all,

The good fellows over at Aqsis have put forth a rather daunting challenge... to render at least a frame if not a small animation of the Blender Foundations "Big Buck Bunny" movie. At first I wasn't very keen on the idea but after considering it for a while I decided it would be the perfect project to really push MOSAIC's integration with Blender and its ability to efficiently export a large animation. Most of the work over the last few months have been related to getting MOSAIC and Aqsis capable of rendering BBB but because of the nature of MOSAIC's RenderMan design and its goals to do all things non-renderer specific these improvements will benefit all RenderMan renderer's using MOSAIC :-)

One of the first big challenges required rewriting key sections of MOSAIC to better handle large scenes and objects with large amounts of data. In particular MOSAIC was dying a horrible death when exporting large numbers of particles, hair strands or high density meshes. The problem was MOSAIC was storing all generated RIB archives in memory before writing to file, now MOSAIC generates and exports the RIB one line at a time (managing archive interactions through open file handles) thus file size is now only limited by the OS. I've also optimized many areas of MOSAIC related to instancing and RIBset passes making occlusion map animations as well as much larger scene animations possible (or at least not as painfully slow as before).

One of the next big challenges has been dealing with the painfully slow export times in Python when dealing with millions of strands of hair :-( I'm still planning experimenting with Python wrappers in the near future to squeeze faster export directly out of MOSAIC, although I'm not keen on complicating compilation and installation of MOSAIC for the user. A far more RenderMan like way of dealing with the problem is to use DSO's (dynamic shared objects) for generating any procedural like object such as hair. A DSO is C library object that can be dynamically loaded and executed by the renderer. These DSO's are capable of accessing the render state as well as calling functions from within the render and can use this information to generate and return RIB code to be rendered (such as growing hair on another object). The advantages of this approach are huge not only because MOSAIC doesn't need handle these large amounts of data but also because neither does the RIB files. This is a big deal for render farms since several hundreds of megs for a single hair RIB for a single character for a single frame will kinda slow down traffic on the network for a large animation :-s The down side to DSO's is they have to be properly compiled to use (something non-programmers will be intimidated by) and often times they call on renderer specific functions making them often times non-universal to other renderer's (unless carefully designed). In either case I have added a new series of controls so that code fragments can now be attached to individual particles systems and geometry materials indices's as well as a toggle to determine if the code fragment "replaces" the exported RIB. So in the case of the BBB hair problem you just make a code fragment to call a hair DSO, select the body mesh of the character and finally attach the code fragment to the particles system (toggling "R" on to not export any hair from MOSAIC). Chris (c42f) over at Aqsis is in the process of writing an excellent hair DSO that will eventually mimic enough of Blender's hair behavior to properly render several of the hairy characters, although I think it may be useful for grass or other such things with tweaking and maybe some modifications :-)

There are also several new modifications related to the DSO stuff mentioned previously. The exporter now always export particle and geometry RIB into a cache file that is always generated regardless of the archiving type of the object. This was originally done so DSO's that require a RIB of the geometry are always guaranteed one, but has several side benefits such as improved export times of motion blur and more efficient sharing or geometry data throughout the export system :-) The geometry cache RIB path/file name can be returned in a code fragment using the new <GeometryCache_S> token and particles cache RIB path/file name can be returned using the new <ParticleCache_S> token. Also there are some improvements to the token system for more flexibility in the returned token string. Originally the tokens were only designed for return values inside shader calls that are always in square brackets but this isn't very useful when in a code fragment. Now its possible to leave the type off to return a straight value or use the "_Q" type to return a quoted value. So for instance <Test_F> = [ 1.0 ], <Test> = 1.0, <Test_Q> = "1.0". Another big new feature added to help with DSO's in MOSAIC is the inclusion of what I'm calling Python tokens. A Python token is just a token including the name of a Python text loaded in Blender that writes RIB text into a global variable tokenReturn that MOSAIC then places in the export stream. So if you made a Blender text called "test.py" and put tokenReturn = "[ \"Hello World!\" ]" in it and then created a fragment and put a token <test.py>, then "Hello World" would be placed in the RIB that the fragment was attached to. This is mainly helpful for accessing data in Blender through Python that MOSAIC doesn't have a token for, such as accessing a control for a parameter to a DSO that MOSAIC doesn't have, it could also be very handy for procedurally generating RIB with python in Blender (although if doing something intense it would be better to use a DSO).

There are a few small changes made to MOSAIC to help with managing larger more complex projects. The "Generate Shader Fragment" utility now only lists shader source files instead of all shader sources and library shaders. This is because when dealing with a lot of shaders the menu was becoming to large to use. Instead I've added a "Fragment" button to each shader library in the "MOSAIC Settings" tab that allows you to create fragments for only those shaders in each library. This has not only the advantage of making the menus smaller but makes it possible to deal with shaders in logical groups. I've also added a "list all tokens" utility that will generate a text file called "tokens.txt" in Blender that automatically lists all MOSAIC tokens grouped according to there datablock and type using there full format, this is not only handy for seeing what tokens are available outside the shader editor but is great for copy/pasting tokens into code fragments ;-) I've also had to make several changes to how MOSAIC interprets dupli systems, in particular how it manages dupli groups conected to empties. This is important to how Blender manages content linked to external libraries in large projects and such.

Another big problem is how to deal with complex characters with multiple materials applied to the same mesh. Since standard RiSpec doesn't have a method for dealing with this in the past MOSAIC just separated the mesh where each material is applied however this process is slow to export and when dealing with SDS it is still required to export the entire mesh for each material (using hole tags so curvature matches between materials) making for very large RIB file sizes. MOSAIC now supports three different methods for separating materials using a control called "Material Set Mathod" located in the Geometry tab, the first two methods will work with all renderer's however the most efficient and elegant method will only work in Aqsis or Gelato, heres a breakdown of the pros and cons of each:

Separate Geometry
Separates the geometry per material either using Os 0/1 values for polygons or hole tags for SDS.
PROS:

• the only benefit of this approach is it guarantees that all renderers and shaders will work with multiple materials.

CONS:

• Since the geometry is copied for every material this can produce massive project sizes- Since the geometry is re-processed for every material this can be very slow to export
• All that data ends up needing to be loaded into the render which consume large amounts of memory and will render slowly

Multipass Materials
Calls the cache with read archives per material using a user parameter in the geometry to adjust Os values in the shader per face.
PROS:

• Requires the geometry only be processed once greatly increasing export times
• Produces far less overall RIB size since geometry's only used once (unless datablock is set to "Inline Code")

CONS:

• Requires that all shaders be modified to recognize the geometries user parameters, however this only effects polygons (particles are still separated)
• Depending on the renderer still consumes large amounts of memory for each copy of the mesh per material
• Still very slow to render since each material has a complete mesh even if its not visible per material

Layered Materials
This elegant approach will only work in Aqsis or Gelato and uses the user parameter in the geometry to shade or skip each face in a chain or layered shaders.
PROS:

• Only requires the geometry to be exported once, so exports fast
• Only requires the geometry to be loaded into the renderer once, so uses less memory
• Only requires one geometry for all materials, so renders faster

CONS:

• Will only work in Aqsis or Gelato
• Requires all shaders be modified to recognize the geometries user parameters, and unlike the previous method will mess up both particles and geometry shading if not.

The last method required adding Aqsis/Gelato style layered shading support to the internal structure of MOSAIC so it was a small step to add user control of layered shading to materials. MOSAIC is using the concept of "chaining" Blender materials together to create layered shading for surface and displacement shaders. How this works is fairly straightforward, open up the materials tab and select the material you want to be the "root" material in the chain then select a material with "Next Material Layer" menu to link to, then goto that material and select another material to link to, so of so forth... All materials in a chain are exported together into each materials archive separately so multiple objects can intercept different parts of the chain.
You can also use the "Surf Output Variables" and "Disp Output Variables" to specify surface and displace output variables to use for the current materials shaders. If more then one variable is entered (separated by spaces) then separate connect calls are chained together for each so for example...

if Material.001 "layer1" used "a1 a2 a3" and called Material.002 and
if Material.002 "layer2" used "b1 b2 b3" then MOSAIC would export
ConnectShaderLayers "surface" "layer1" "a1" "layer2" "b1"
ConnectShaderLayers "surface" "layer1" "a2" "layer2" "b2"
ConnectShaderLayers "surface" "layer1" "a3" "layer2" "b3"

Also note that you can have varying numbers of parameters per control and can use None selections to disable export of certain shaders in a chain (such as only building a displace chain, or skipping a surface shader in a long chain).

Here's a simple example using all these features together. In particular this is demonstrating combining highly refined or integrated shader (such as MOSAIC's integrated shaders to Blender) with fast customized shaders (such as procedural shaders). This in my mind is a key benefit of layered shading because you don't have to re-create the shaders for every new surface (such as having to be sure every new shader can use occlusion, or env maps, or SSS).




At this point in development I'm finally at the point that I've begun to work on re-writing the built in shaders for more complete support of Blender's material system. I'm currently working on adding support for multiple layered textures using some if not all blending modes and UV layers. This is important because currently I can export the characters geometry into RenderMan (even using linked libraries) but without layered textures, alpha and layered UV's it won't be possible to get accurate renders of the charaters :-( The trickiest part wont be putting this together but getting the top 5 RenderMan renderer's compiling the shaders without problems :-s
Anyway I'm hoping this will only take a few weeks to do and if all goes well I also hope to add some fancy techniques such as better SSS support for skin and faked soft shadows using depth maps (should be considerably faster then raytracing).

Thanks for reading, WHiTeRaBBiT