Glimpse of Distributed Bucket Rendering (DBR)

After busy few weeks, recently I have stumbled upon a render that really pushed my workstation to its limit. It had nearly 20 high detailed tree geometry that are animated. With some RnD I found out that rendering time per one frame in acceptable quality is around 40 to 50 mins; in mental ray. With 250 frames to render, the waiting is going to be so long. But then I decided to switch to distributed bucket rendering. Which the idea is to directly use mental ray satellite services installed in my spare workstation and laptop to add their computing power to the total rendering.

Unlike in backburner like software based network rendering, where the 'job' is divided by frames and are sent to each render node to render an one whole frame, distributed bucket rendering gets the 'help' of other render slaves to render a 'bucket' or a small portion of the rendered frame. (The size if this 'bucket' can be manually set in both vray and mentalray.) Setting up a distributed bucket rendering setup is fairly easy. All we have to do is assign static i.p adresses to all the slave nodes and write them down, and put them under ip list in “Distributed Bucket Rendering” rollout in mentalray render settings- processing tab. And its recommended to check use placeholder objects and use mental ray map manager ticks before we hit render. The reason for this can be found here.

So after all, we just have to hit render and if all goes well you will see that render window showing up with number of buckets more than you see when rendering with your hosting workstation. This number of buckets is directly linked with the number of processing units (physical or logical) you have in your workstation and render slaves. So if you are using better hardware, you will end up with high number of buckets rendering your frame. But keep in mind that this method is not the suitable method for all the scenarios. For an example, in a situation with less per frame time, but large amount of frames, this method can even increase your render times. This is because even though your frame is simple, mental ray have to send and receive data/ communicate with its render slaves in order to render out that frame. So in situations like this, methods like backburner become more effective.

Why I was inactive and what is going on

For last few months, I been asked by so many people that why I am silent and why there is no update in my blog. Actually, this is mainly because of some personal reasons and I was unable to pull my mind together to create something new. At the same time, I was busy with my showreel and working big time on moving out of the country for some big reason. But later, this 'big reason' moved out from my life and.. how can I put it.. I came upon the real reason that all my life was pointing towards. So basically I had a huge turning point in my life and that is why I was silent :-) . So hopefully, now I'm back on my track, continuing to do what I do best. So for a memorabilia for my silent days, here is my solo showreel for year 2014 and 15.

CGI Generalist | Solo Showreel 2013-14 Ravihara Weerathunge from Ravihara Weerathunge on Vimeo.

http://www.ravihara.com
Soundtrack © Coldplay - Yellow (K.Solis Trap Remix)
© Ravihara Weerathunge 2015
CGI Generalist
ravihara@live.com
+94718339579

Learning Rendering; a sensible approach

Once I heard some veteran in the CGI industry states that render engines are like religions. It’s where you seriously communicate with your software/ workstation, in order to get your intended output. Selecting a render engine takes practice, and intensive studying on each aspect of it, but unfortunately most of the render engines are packed up with technical jargons that may be difficult for an ordinary user to understand. Because of the attractive nature of the productions done with these big render engines, ordinary users tend to ‘jump’ straight on to these big render engines without studying concepts of lighting or shading; thus ending with poor quality renders or unusually long render times.

‘Best universal settings to render’ is a myth.

I have seen many people just asking ‘what are the best settings to render using v-ray’ or mental ray. Unfortunately, there is no specific, magical set of settings called ‘best settings to render’; cause depending on your scene, your render settings is going to change in a huge range. Best render is subject to interpretation : it can be either about image quality, or speed. So basically, your scene’s best render settings lies somewhere within the maximum amount of time you wish to spend per one frame and your intended render quality. This notion change when you are testing and when you are producing your final images.

First step - start from the basics

If you are a beginner, the best playground to learn rendering is your software’s default render engine. Of course, it will have lots of constraints, but you will be forced to study lighting methods and how to ‘fake’ things like indirect illumination and make your ‘stuff’ ‘beautiful’ with the limited resources.

Second step - migrating (only) when needed

As you get deeper and deeper using a ‘primitive’ render engine in rendering, you will come up to a point where you understand what is missing in them; it may be a cool sub surface scattering material or a kind of light with some qualities that are missing from the lights from the basic renderer.
Then that is the best time to start migrating to a semi-professional render engine like Mental Ray that still is available within most of the commercial 3d packages. From my point of view, Mental Ray is a really great place to start learning these technical terms like ray tracing, antialiasing, interpolation and whatnot.

Also, when you get into using renderer like Mental Ray, you will understand the constraints they impose compared to basic renderers. I have seen people who prefer basic render engines like 3ds Max default scanline over other renderers when it comes to rendering some passes and even effects like hair and fur. You will most probably find professional and semiprofessional renderers are not your best friend when it comes to ‘quick and dirty’ gigs.
However, this migration period will be really interesting for you, for you will learn a lots about the advantages and disadvantages of both worlds.

Third step - go further, and know what you do.

After the crucial second step, you will find yourself surprisingly comfortable using your new render engine. If you are serious about what you are doing, don’t stop. Take the next step; go for a commercial render engine like VRay. And when doing, compare your current render engine’s features with their substitute features in V-Ray. Don`t just learn, but understand the advantages/ disadvantages of both. A successful third-party professional render engine migration may take a few weeks to a few months, and you will find it’s totally worth it. Read user reference and articles that will directly answer the questions in your brain. I find that tutorials are not helping that much when it comes to understand rendering. Because most of the tutorials I found, are targeted at getting a certain output, and the tutor will most probably adjust one parameter to a certain level and will just briefly tell you what it does. I find written reference material is clearer and can give you in-depth details of the parameter you are referring.

So eventually, you will be up to a point, where you can understand what is happening behind the parameter you are adjusting, and predict the result that you are going to get; it is where you really going to start to enjoy rendering. :-)

Art of creating custom installers for your maxscripts. pt.2

A common custom maxscript installer can use basic maxscript commands such as getdir , copyfile, deletefile. You can get an idea about how max can interact with external files, if you look up “external file commands” in maxscript reference. As I mentioned earlier, it’s best to hook up the custom installer script with a self-extracting max zip (.mzp) file.
As soon as you drag and drop an .mzp file in to max window, max will extract its content to its temp directory. And start following the instructions we set inside “mzp.run” file.  Actually, you can just install your package with only using the instructions inside this “mzp.run” file, but as I mentioned in the early blog post, you will not be able to present your user a GUI, possibly with uninstall function and installation progress and etc.
So let’s begin with the folder structure of the archive. We will be using separate folders for each type of elements we hope to install. Separate directories for icons, macro scripts, scripts and other common elements that we can find in a common 3ds Max script package.
In context, the functioning of the installer script is this simple;

• It will get all the path variables that it needs to place/ install each type of elements that are related to the script.
• Check if the script is already installed and create and set the GUI accordingly, with options for the user to install/uninstall
• If user press install, copies/ installs the script elements to corresponding paths.
• If user press uninstall, removes all the script elements from the corresponding paths.
• Give visual feedback/ notifications on the installation/ uninstallation process.

As a flow chart, we can put it like this;

Art of creating custom installers for your maxscripts. pt.1

3dsmax is a great application with great features. Arguably its greatest strength is ease of adding more features to it via plugins and scripts written with its inbuilt language- maxscript and, C++. Recently, Autodesk took this ability of making max even bigger and better via programming, to the next level; with Integration of python scripting. While its new, max based python scripted plugins are rare, scripts, written with its native language (as I mentioned earlier, maxscript) is still the most popular way of expanding max (among the ordinary users).

And the other great thing about these scripts is the ease of adding them to 3dsmax. Most of the time, if the script is independent, that it doesn’t need any external resources to run (ex: icons, settings stored in INI files) it’s just a matter of dragging and dropping the script on to max window. And for the scripts that have dependency on external resources, max have another solution, a specially prepared zip archive with a modified extension named .mzp.  It gives the developer the ability to archive the script and its dependence on to a one mzp file and distribute it easily. And on the other end, end user just have to drag and drop the mzp file on to their max window, as they did with an independent script, and contents of the .mzp gets extracted to the right locations and, script gets added to their package easily.

If we look closely, what is happening inside a mzp file, we can see it’s just an ordinary zip file, but with guidance to its extraction in a special file called “mzp.run” . In other words, anyone can create these self-extracting script packages, with a software that can create zip archives, and simple knowledge of how to code this “mzp.run” file.

As a fresh coder, the best way to improve coding is by making people use your code and give feedback; in other words, distribute them among people who are willing to use them and evaluate them.

So making scripts easy to install, run and of course- easy to uninstall is an essential part as I see. .mzp format does a decent job in installing and running scripts, but when it comes to uninstalling, mzp with default instructions doesn't help at all.

So the options are to create .exe installer for our scripts using third party software or go for a custom installer coded in maxscript.

First option, an exe installer is surely not the best solution here. Though it is the best solution for commercial plugins that may require special runtime environments or license services installed, here when it comes to just intermediate or simple level scripts that may be independent or depending on few external resources, the best solution is to go for a custom installer, coded in maxscript.

So I started writing a one. The plan is to archive the custom installer inside a .mzp file and when the mzp file is dragged and dropped to the max window, it extracts all the contents to 3ds Max temp folder, and run the custom installer script- and custom installer takes the task from there, presenting the user an interface to choose to install or uninstall the script.

With the next post on this topic, we will look in to a structure for this custom installer.