Aqsis/Air Depth-Mapped Occlusion using multiple light rigs

Hey gang :-)

The short version of this post...

I decided to do a 35 second video demonstrating multiple Depth-Mapped Occlusion maps using Aqsis :-D

Here's the low quality YouTube version...


Or you can download a 25meg high quality version here: http://www.dreamscapearts.com/Public/MultiOccDemo.mp4

The long version of this post...

I noticed a post last week over at Aqsis asking how to use multiple occlusion maps in large scenes or animations. This is something thats has crossed my mind several times while designing MOSAIC's render pass system but not something I've actually tested. Since the BBB shader work is going to be a lot of work and I've needed a little distraction (not to mention just wanting to use MOSAIC at least a little) I decided to do a little 35 second movie using multiple occlusion maps :-D For those of you who don't know ambient occlusion lighting is simply indirect ambient lighting usually from hemispherical directions such as the sky. In RenderMan there are several ways of achieving ambient occlusion depending on your renderer such as irradiance caching, photon mapping, point clouds (usually with in combination with other techniques), depth-mapped occlusion, and plain old light arrays. Depth-Mapped Occlusion is a technique specific to Air and Aqsis similar to a light array however the depth maps are combined into a single file and the file is fed into a shaderop that uses the depth data to figure occlusion shading on the surface. I'm particularly interested in this technique because I'm looking into very, very high resolution renders on a farm that require highly "parallel" techniques, that is the image is broken into many tiles but the tiles can't be rendered until the support data is calculated but usually only by one computer holding up the whole farm. With Depth-Mapped Occlusion each depth pass can be distributed to the farm so the entire farm can contribute to the occlusion data as well as rendering tiles which is more "parallel" in nature ;-)

I decided a good simple scene to demonstrate multiple maps would be a fly through of a city scape broken into blocks with a central subject. The objects of the scene would then be attached to groups and multiple occlusion passes would be generated filtering for each group. The reason large scenes need to be broken down into multiple occlusion maps is because of there scale, it becomes impractical to use a single really high resolution occlusion map for everything (to long to calculate not to mention file sizes). Its also beneficial to break them up for greater controls, such as baking the occlusion maps on the first frame in the background and only calculating occlusion for animation on the subject in the foreground, ect.

As a result of doing this project I've added several new features as well as tweaked several things in MOSAIC, however they are currently only in my developer copy and won't be available to CVS until I finish the shader work :-( Some of the things done for this project are:

• Added the ability to use the "Enable Occlusion Mapping" utility in the "Scene Setup" tab to generate occlusion passes with user defined names.
• The occlusion passes are now using the pass names for the outputted occlusion file so the user can know what its name will be for the shader parameter.
• Made each occlusion rig in the occlusion passes unique so they can be edited separately, before MOSAIC only expected one occlusion pass for each beauty scene so the rigs where all the same :-s
• Added the occlusion specific controls in the occlusion utility dialog to the "Scene Setup" tab so the occlusion setting can be edited form within the pass (since the occlusion utility can't be used for user named passes after there generated).
• Added the ability to hide groups of controls in MOSAIC with toggles in the GUI so I could hide the automap controls to make the Scene Setup tab less cluttered
  

With these modifications its now possible to use any of the autopass utilities to generate custom user defined passes that can later be edited directly by hand, such as a env map pass thats used for multiple objects or a depth map pass used for multiple lights... the only drawback to doing it this way is the shader parameters have to be hand edited since MOSAIC uses the pass names to figure out how to hook pass display data to tokens in shaders :-s

To setup this project I created a plane and used the "discombobulator" script to quickly subdivide and extrude it into a city block. I then instance the block 3 times to create 4 side by side city blocks, each assigned to a different object group. I then created a cube and stretched it into a tower and instanced it twice to create 3 towers in the middle of the city and placed 3 instanced suzanne heads atop each tower, assigning the towers and heads to another group. Next I gave each city block a unique material and used a single unique material for the towers and suzannes shared (this is because each group will need separate occlusion file entries applied to the surface shader of each material). Then in I ran the "Enable Occlusion Mapping" dialog 5 times from the main scene, changing the "Pass Name" and assigning a different object group to the "Select Group" filter for each object group. I named the passes City1.om, City2.om, City3.om, City4.om, Suzannes.om using the object group for each. Once each pass was generated I them switched to each scene and adjusted the occlusion rig to properly surround the objects filter to each pass. Next I used the shader editors "C" button to copy the standard built-in ss_MOSAICsurface shader fragment into 5 new fragments called ss_City1, ss_City2, ss_City3, ss_City4, ss_Suzannes. Then I selected each fragment in the editor and changed the "OccMap" parameter of each from the standard <GetOccMap_S> token to the name of each occlusion file, the occlusion file names are created from the name of its pass with the frame number appended... so for the pass City1.om and its shader ss_City1 on frame one then the parameter should be "[ F1City1.om ]" or if you wanted to do animation you could use the frame token "[ F<#>City1.om ]". Finally I selected each of the 5 materials assigned to the objects and selected the appropriate suface shader for each, such as selecting the material for the first city block and selecting ss_City1 for its surface shader, ect. Then of course I added animation, motion blur, dof and intro-outro graphics to the video sequencer :-D

Anyway heres some screen shots of the basic setup:

the complete beuty scene...





















here the City1.om occlusion rig...





















here the City2.om occlusion rig...





















here the City3.om occlusion rig...





















here the City4.om occlusion rig...





















here the Suzannes.om occlusion rig...





















If anybodies wants to mess with this yourselves you can download the complete project here: http://www.dreamscapearts.com/Public/MultiOccDemo.zip

This zip contains the intro/outro graphics, blend file for Blender 2.48a and a developer copy of MOSAIC pre-loaded in the text editor (WARNING this developer copy of MOSAIC has broken texture support as it is not complete yet and you should NOT overwrite your own copy of MOSAIC with this one!!). To render the project execute the text copy of MOSAIC in the text editor, click "Render Animation" to render out all shadow, occlusion and animation passes (this took 4 days straight on my Core2 Duo 2.8 duel core 8gig ram). Once all frames are rendered into the /tmp/MultiOccPass folder then in Blender click ANIM to composite all tif frames, insert intro/outro and compile them into a mp4 in /tmp ;-)

Thats it... thanks for reading,
WHiTeRaBBiT

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

Unexpected archive from the past

While surfing the net tonight I ran across an old article that was archived on some server somewhere in the vast cyberspace. It caught my eye since I actually used to read this publication as a child so I clicked the link from Google and was reminded at how much time has changed the computer industry. Sometimes we forget the "good ol' days" and even I have to remind myself of this. Recently I was sort of griping about my "old" 1.6 Ghz system with 512 MB RAM running Linux, this page tonight kind of snapped me back into shape and despite it's shortcomings this little system built from spare parts isn't that bad....

For a little chuckle check this out.

http://www.atarimagazines.com/compute/issue135/88_Start_your_own_carto.php