During the time I worked on the integration of Golaem Crowd with Mental Ray as a shader plugin, I had two recurrent thoughts :

• When I was on the geometry shader, it was something like : “damn this Developper Manual rocks: all is well documented, there are some inspiring samples, some tips… This is a real pleasure to develop stuff for this rendering engine…”
• Then, I had to work on the material shader and it was more something like : “#@%! how the hell am I suppose to do that !!? This is a real nightmare to developp stuff for this rendering engine...”

How to write/read userdata? How to dynamically create a material and call it (if like me, you would expect that mi_call_material would do that, do not even think about it)? Add some silent crashing function calls and weird behaviors to the whole and you almost got it. Now, I better understand why Shader Writer is a real job: it requires a lot of patience, tenacity, courage and puzzle solving skills. Those guys are heroes…

What about internet and forums? Well, too many often for my poor nerves, I felt in this classic situation:
 

Wisdom of the ancients

Source: http://xkcd.com/979/

Thus, as I now consider myself as an ancient, I feel this need to share my knowledge with the next generations of Mental Ray sorcerer apprentices. Please sons, spead the good word around you and never let another soul wander in the darkness again…
 

MRay Implementation

In this post, I’ll answer my first question : How to store user data in an object and read/write it in a shader ? In mental ray, arbitrary user data can be attached to any element in the scene, or stand by itself, for usage by a shader. User data can be attached to instances, objects, lights, instance groups… to extend the scene entity with extra data or attributes.

Why would you use them? Well, it could be efficient for varying the look of large numbers of object instances, adding simulation data usable by parallel jobs running in mental ray or sharing huge data between several shaders (e.g. data which could not get through the shading network)…

In my example, I considered two plugins :

• myPluginOne writes data of type myStructData in the hit object (miObject);
•  myPluginTwo reads this data and displays it.

//------------------------------------------------------------------------- // myStructData – data struct to share //------------------------------------------------------------------------- struct myStructData {   int importantData; };      //------------------------------------------------------------------------- // myPluginOne – writes user data of type myStructData in the hit object //------------------------------------------------------------------------- miBoolean myPluginOne(miColor* result, miState* state, void* paras) {   // get the hit object (which stores the userdata)   miTag objectTag;   if(mi_query(miQ_INST_ITEM, state, state->instance, &objectTag))   {     miObject* object((miObject*)mi_db_access(objectTag));     // allocate your data struct     // NOTE: it is important to dynamically allocate your struct data, else     // mi_api_data_byte_copy will crash. As far as I can understand without     // seeing the actual code, it is because it is deallocating the pointer     // it receives upon exit.     int data_size (sizeof(struct myStructData));     struct myStructData* myData (((myStructData*)mi_mem_allocate(data_size)));     // fill it     myData->importantData = 42;                  // build a MRay data block     // the first param of mi_api_data_begin corresponds to the name of the     // block. If an already existing name is used, mi_api_data_byte_copy will     // override its content     mi_api_data_begin(mi_mem_strdup("myDataBlockName"), 0, (void*)data_size);     mi_api_data_byte_copy(data_size, (miUchar*)myData);     miTag userdataTag(mi_api_data_end());     // append with the existing data (just in case)     miTag appendUserdataTag(mi_api_data_append(userdataTag, object->userdata));     // add it to the shader userdata block     object->userdata = appendUserdataTag;     return miTRUE;   }   return miFALSE; } //------------------------------------------------------------------------- // myPluginTwo – reads user data of type myStructData in the hit object //------------------------------------------------------------------------- miBoolean myPluginTwo(miColor* result, miState* state, void* paras) {   // get the hit object (which stores the userdata)   miTag objectTag, userdataTag;   if(mi_query(miQ_INST_ITEM, state, state->instance, &objectTag) &&      mi_query(miQ_OBJ_DATA, NULL, objectTag, &userdataTag))   {     // get & check userdata     int userdataSize(0);     struct myStructData* myData(NULL);     if(mi_query(miQ_DATA_PARAM_SIZE, state, userdataTag, &userdataSize) &&        mi_query(miQ_DATA_PARAM, state, userdataTag, &myData) &&        (userdataSize == sizeof(struct myStructData)))     {       // here you go       std::cout << "What's the answer ? " << myData->importantData;       return miTRUE;     }   }   return miFALSE; }

As always, any question, improvement suggestion, bug report is welcome and will help me to access perfection and all-wisdom. Finally I’d like to thank the LAMRUG (Los Angeles Mental Ray User Group) which website is a bible and whose owners are prophets!

Pixar announced today the availability of their new cloud rendering service called "RenderMan® On Demand™." (see their press release). Developed in collaboration with pioneering cloud services provider GreenButton, this service is now available on Microsoft's Windows® Azure with Linux availability following later in 2012.

The good news is that, as we were lucky enough to beta-test it, Golaem Crowd is readily available with this service! See our complete use case showing how easy and powerful it is.

Quoted in Pixar's press release, Nicolas Chaverou, Golaem Crowd Product Manager, confirms how convenient and powerful RenderMan® On Demand™ is: "Working within a tight deadline has always been difficult especially when rendering animation at the very last minute. In spite of the time difference, the process was very straightforward, asset upload and distribution on the Cloud, and 54 minutes of Cloud Rendering later it was in a wrap instead of the 20 days it would have otherwise required. Magic! In addition, GreenButton provided great support including feedback about improving our pipeline."

Last but not least, the video we made to demonstrate the service was chosen by CG Channel (here) and fxguide (here) to illustrate their article about Pixar annoucement . Thanks guys!

Working within a tight deadline has always been a bad idea, especially when dealing with rendering: even if your demo is ready decades before your D-Day, you cannot be safe until you've made some rendering tests... and not even talking about crowd to render... So when we realized that each image of our 40sec crowd demo for Siggraph Asia would require 30 minutes of computation, that we only had one node available for rendering and that there were only 10 days before us, we thought something like "oh oh, it's looking pretty bad".

Well, don't misunderstand me, as Golaem Crowd relies on procedural rendering, generating the crowd geometry at render time is really fast and efficient. But you know, rendering engines have always lots to do and increasing the amount of geometry to render, has consequences. Here's an illustration of the apportioning of the rendering time for a frame of our crowd demo (2000 characters, 1080p, motion blur...):

Fortunately for us and for the sake of Siggraph Asia, we have some great partners. While we were preparing ourselves a slipknot, the guys from Pixar Renderman had a brilliant idea: what about sending our demo on the beta Pixar Renderman cloud rendering solution (powered by the great guys at Green Button using Windows Azure)?

54minutes of Cloud Rendering later, it was in a wrap: magic!

On top of that, we were lucky enough to be invited to tell about our epic story and share our experience at the SIGGRAPH Asia 2011 Renderman User Group Meeting (thanks Dylan!). Here are the slides (with some funny pictures and more information about GreenButton Cloud & process). Enjoy it:

Previously in Golaem Crowd Procedural Rendering…
- John: Mike, we all gonna die! We have two 1000 characters crowd shots to render by 6pm!
- Mike: Don’t worry John, there is necessary an appropriate export options in Golaem Crowd, we’ll get out of here…
- John: Should I use the FBX export?
- Mike: No, it’s a job for Procedural Rendering!

Procedural Rendering

After such a teaser, you may wonder what Procedural rendering is! Well it’s the ability for a rendering engine to call an helper program which generates geometry on-the-fly in response to specific procedural primitive requests in its scene description language (i.e. RIB for Renderman, vrScene for VRay…). Any rendering engine worthy of the name provides this functionality: it’s called DSO (in Renderman) or Geometry Shaders (in Mental Ray) but it always works the same way : inputs parameters, outputs geometry, black box inside.



As you can guess, it’s a very efficient way to generate lot of objects of pretty similar geometries. Mhm, wait a minute! Lot of objects? Objects of pretty similar geometry? Well, that’s exactly what crowd is! So, what do we need as input parameters?

• Reference Geometries: for each type of characters, the TPose skinned geometry and all usable props;
• Asset Repartition: for each character, the name of the props, shaders to use and their parameters;
• Posture: for each frame, for each character, the position/orientation of each bone;

How does it looks like in Golaem Crowd?

Here’s where those different parameters come from in Golaem Crowd:



To store our simulation results (e.g. postures), we rely on the Disney Partio particle file format. In addition to high performances (both in terms of disk space and access times), it supports several common particle file formats (Houdini’s GEO, Maya’s PDB & PDA...). What if we take our previous example of 100 frames of 100 characters and get some numbers? Well, it rocks: 37Mo on the disk and 2min to load (instead of 1.5Go and 16min with FBX). Nice, isn’t it?

So, let’s take the workflow above and adapt it to our needs:



But the most awesome feature about Procedural Rendering is to come: as reference geometry and asset repartition are only read at rendering time and are independent to what has been computed during the simulation, they can be changed as many time you want for free.
Damn, a bare-chested guy in the foreground of my 10k characters snowy scene? No problem! Open the Asset Manager tool in Maya, edit the shirt repartition, save your file and render again. Yes you read it, as simple as that: you don’t need to launch the simulation again! If you’d like more information about how to tweak asset repartition and therefore visual appearance, you should definitely have a look of our mesmerizing tutorial.

And as I know that you guys love numbers, here are some more for you: rendering the following image of 10k characters with Pixar Renderman and our procedural only took 9min (i.e. computing the workflow above 10k times). Of course the image is 1080p and is motion blurred.



Ok, let sum it up: fast rendering, light files, customizable at render-time… Sounds like the Messiah, right? Well, almost. The counterpart is that we need to write/update/upgrade as many procedural plugins as rendering engines we’d like to be compatible with. For now, Golaem Crowd is compatible with Pixar’s Renderman, VRay, 3Delight, Air, Guerilla Render. Mental Ray is coming soon.