The ball starts rolling

Since the last post there has been quite a bit of activity on the net in relation to the Blender to RenderMan projects, chatter on websites and our group has seen a very large increase of posts. Seems that we are bigger than we thought, that our collective efforts are starting to get noticed and paying off. I for one can say that I have underestimated the effect and reach this website has. So I am taking this time to inform people some of the things that are going on around the world.








Animux
http://www.animux.org

This is a newer Linux distribution that I only recently found, why I only just found it I can't say, however from what I have seen on the website this seems to be much like my idea of having a Blender to Renderman Linux distro. Not only is this available NOW but they have been following this site. This is right up our alley! This is exactly what we've been trying to influence! Best part is that I don't have to do the hard part as I have never even tried to make my own Linux distro and I wouldn't know where to start. This is here now and only getting better.

So.... I am making an unofficial statement of which Animux would be considered as the Blender to RenderMan "primary" Linux distro. The reason is that they have established quite a bit to make it workable for artists and TD's alike, for all skill levels not just the Linux guru's. That was one of the main issues I felt was important. They also have quite a roster of people that are either developing it or advising, some of these people are very important to the success of the open source 3D movement.

One of the coolest things I have seen is their IKEA renderfarm how-to! This is something anyone could, and SHOULD build.

http://www.animux.org/wiki/index.php?title=Animux_Caseless_%22Ikea%22_Rackmount_Renderfarm



One aspect of the Blender to RenderMan pipeline that kind of got overlooked was Digital Asset Management, something of which is VERY important for any kind of studio. They are working on what is known as ADAM, short for Animation Digital Asset Management. They seem to be well on their way to something very special for us 3D artists.

That is all I can say about that right now ;)

"Project Widow"

This is very much an early announcement (something I was going to hold back for a little longer but got excited tonight over the Animux finding). Though if anyone has been in the forum group section, this really is not much of a surprise. This is a short 1-2 minute "test" that some of us have been pulling together, something that has taken off quite fast. This was started as a Blenderartist forum topic discussion where the debate over whether or not Aqsis was being used to render the new Blender Foundation Open Movie "Durian". Well no is that answer. Either way over the next week the subject kept coming up and somehow a test was thought up. But it is not like any normal test, this is a short story, very short but it is still a story and not just some walk cycle. I felt it was more important to use an original story to make our statement heard and that is Blender to RenderMan WORKS.

Over the next couple of weeks a LOT of progress has been made. We have Paul Gregory and Chris Foster from the Aqsis team backing us up, we are also using Aqsis 1.5.0 development builds to be the test bed for that version. They are helping us with the technical issues, we are helping them find some obscure bugs. We also have the help of WhiteRabbit (Eric Back) who is furiously busy writing the next version of Mosaic, again we are going to test that version out as well. We have a talented modeller, Daniel Wray, that has built the vast majority of our assets so far, including the main character model. We also have the help from Cedric, an animator. Not only that but we also have the help from a couple of concept artists and a sound fx engineer. We are still on the lookout for some more animators and RenderMan users. This week I am busy with my local film friend punch out the final storyboard so we can start blocking out camera shots. My own tasks are quite varied but it's been in the shading and TD area, writing the pipeline documentation and testing things in both Blender and Aqsis to make sure when we get to that stage - it will work without too much trouble.

The short is being done to test the pipeline, to put it through a real world situation that involves a number of people working together on different parts of the "production". The nice part about this short is that we are doing this over the internet, which also has made it very challenging.

For more information and to watch our progress as we plug along on this here is the website.

http://projectwidow.wikidot.com/


Things seem to be starting here and I have been wishing for this day for a very very long time, so it is nice to see a little progress here.

"It's a very exciting time!" - a quote from one of my favorite movies.

Blender to Renderman Artist Tools v 0.5 Released! (UPDATE!!!!)

(EDIT: UPDATE! See below original post for more info!!!)

Finally this LONG awaited release has come! Sorry for such a long delay everyone, it has been a hectic year for me. Over the past 2 months I have been working hard on testing Blender 2.48 and the recent versions of Aqsis and Pixie to make sure that it can be considered "production stable", I have been on and off with making this ISO over the past year (to many people's dismay - sorry again) but so far with latest developments this looks good. Most of the tests I have done have been successful and I decided to finally put together this ISO for everyone to use, previous versions were not so bug free. I am listing it as version 0.5 because this is the fifth time I have undertaken such a task, the first time was just for my own use and each time since marked another "version" of this toolkit.

Anywho...... on to the goods!!!!

In this release are:

Compiled and sources of Blender 2.48, Aqsis 1.4.2, Pixie 2.2.5
Mosaic 0.2 Beta
Python 2.5.4 (installation for Windows - Linux already has it)
CGKit 2.0
Shaderman 0.7 and ShadermanNEXT
SLer
Shader sources (hundreds of them!!)
Shaderman shader projects
OpenEXR 1.4.0 (Windows install, Windows and Linux source)
OpenEXR 1.4.0 sample images
Dr. Queue (compiled and source)
Cutter
GIMP
Cinepaint (Linux only!! There is no recent Windows build)
Documentation from Pixars Online Research library as well as SIGGRAPH papers
Crimson Editor (Windows code editor)
Dev C++ and MinGW (Windows only, Linux has gcc which is the basis for all Linux builds)
Python scripts for Blender (various usefull ones not released with Blender)
Voodoo (for visual effects camera matchmoving)
Blender files (examples and test files)
Some usefull textures

This ISO is available HERE and we are also working on having it hosted elsewhere on a more permanent basis. This ISO is available free of charge, nobody is making money off of this at all, we have included all the required licenses (such as GPL and BSD). You are free to host this ISO and redistribute it as we have done so, we only require you to credit Blendertorenderman.org as original source since it has taken quite a number of man hours to test the software and put together the ISO. Please note that Pixar and ILM do have copyright information that MUST be included with the package, we do NOT want to upset these guys and it is only respectful that we do this since they pretty much influenced the industry and provided us with the means to do all of this.

Please note that while this is a "production stable" release, that there may be unforeseen bugs. Due to the nature of programming on different operating systems there is always the chance that something might be wrong. While this has been tested on Linux and Windows by myself personally, I have experienced some bugs here and there. That is the nature of the game, sometimes things get broken in the mix and there is a lot of code between all of the software. For the most part, and I mean %95 of the time, this release is stable enough for production, be it small studio or individual.

Also I am posting my updated Blender to Renderman Pipeline document originally posted in 2006. This has been revised to reflect current developments but is still being worked on and should be complete by late May, at most.

All the Development software for Windows like MinGW and DevC++ are to be considered AS IS! Like I said I am not a programmer but have included these into the ISO anyway, it is up to the end user to collect the necessary libraries and tools. I have not included any Linux libraries because it is easier to download them as needed from a repository, thus ensuring proper compiling of code. Any Linux programmer will be well versed in the trials of finding the right source if not found in repositories.

Lastly I want to thank the following people for their work and contributions towards this (of course not listed in any order).

Temujin
Eric Beck
Ildar Ahmetgaleev
Ton Roosendaal
Paul Gregory and the entire Aqsis development team
Okan Arikan
Alexei Puzikov (ShaderMan!)
Bobby Parker
Malcolm Kesson
Syoyo Fujita
Andrew Silke (for the original Generi Rig!!)
Larry Gritz
Saty Raghavachary
Tal L. Lancaster
Florian Kainz (for developing OpenEXR)
Robin Rowe

And everyone else who has joined our project, offered advice, testing and support!! Without everyone's encouragement none of this would be possible.

Oh yeah and thank you Google for developing superb software to host our site!!

UPDATE

Due to some oversight an update was required. Sorry for that and promise to not make the same mistake!

Changes :

Code:Blocks added to replace Dev C++
GIMP source added
Python source added
CGKit 2.0 source added
Blend files removed (plan to add it next update with BRAT stable models, some required too much initial setup and didn't render right)

Hosting update

For now a torrent file has been created for this update but we are still hosting the original ISO as well since not everyone uses torrent programs.

BRAT 0.5rc1 (original host)

BRAT Release Update 0.5rc2



RenderMan is a registered trademark of Pixar.
All other products mentioned are registered trademarks of their respective holders.
© 2009 Lucas Digital Ltd. LLC. OpenEXR, Industrial Light & Magic and ILM are trademarks and service marks of Lucasfilm Ltd.; all associated intellectual property is protected by the laws of the United States and other countries. All rights reserved.

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