Sunday, October 25, 2009

Krakatoa 1.5 - Confusing Changes For The Better

Once again, while most of this is already covered in the online documentation, I feel that spelling it out for the few people reading my blog might be a Very Good Idea. I will probably have to update the FAQ or just link to this Blog or something like that.

First, the default lights handling.
When designing Krakatoa 1.0.0, we discovered that particle rendering with default scene lights never looked good. This was mainly because the default mode for default lights in Max is a "headlight" right behind the camera, which does not produce very good looking shadows. The alternative mode is two lights which works even worse with volumetric rendering, and requires one more light sorting/attenuation map generation pass...
So we made the decision back then to render particles as self-illuminated if no actual light node was detected in the scene. As result, one could just create some particles, hit render and get an idea where the particles were. On top of that, it worked great with Additive Mode where lighting was usually not desired (although Additive Mode + Lighting was somewhat supported).

When the Krakatoa version which ended up being released as 1.5.0 (it was initially developed as 1.2.0 and nearly shipped as 2.0.0 due to the amount of features added, but that's another story) added support for an Emission channel and an Absorption channel in addition to the Color (Scattering) channel, we had to revise this design decision. In short, having a per-particle Emission channel meant that it would be a Very Bad Idea to render particles as fully self-illuminated when no lights are found in the scene. At the same time, rendering Default Lighting was still as unusable as it was two years earlier - we looked into it again and finally decided to bite the bullet and render particles as not illuminated if there are no explicit lights in the scene.

What does this mean? In short, if you open a Krakatoa 1.1.x scene without scene lights in Krakatoa 1.5.x or just start a new Max scene, add some particles and hit render, you get... nothing. Or so it seems. Looking at the Alpha channel, the particles are there (and the log / progress dialog show that they are actually being loaded and processed). It is just that self-illumination is not applied implicitly, no scene lighting is applied either and you end up with black particles on black background (changing the background color to a brighter color shows that, too).

As you can imagine, this is one of the main problems new users of 1.5.x encounter and report on the forums and in support emails. The possible solutions are
  • Check >Override Emission and >Use checkbuttons in the Global Render Values rollout (or alternatively check >Use Emission and >Override Emission in the Main Controls rollout). The default Emission Override color is set to white, so your particles will render as white by default.
  • You can also add a Map to the Color Override in the Global Render Values if you want more interesting results.
  • If you want to emulate somewhat the Krakatoa 1.1.x behavior where each particle renders the Color as Self-Illumination, you could also add a Global Channels Override KCM and set it to Color Input>Emission Output, then check ">Use Emission" without enabling the >Emission Override option - this will copy the Color of the particle into its Emission channel. PRT Loaders and PRT Volumes will render in their actual color.
  • Alternatively, adding a Vertex Color Map to the Emission Override slot will render the Color channel and put it into the Emission channel, but this approach is generally slower compared to using a Global KCM.
  • You could of course also create a Light in the scene to illuminate the particles, but this will cause longer render times due to the illumination pass when rendering in Particle Mode.
While I admit that this seems like a step backwards, the ability to specify Emission per particle means more flexibility (as we will see later). Flipping two checkboxes or creating a light shouldn't be a big price to pay...

The second large change made to the main controls of Krakatoa was the replacement of the big >USE LIGHTING button with a much smaller >Ignore Scene Lights button. We wanted the lighting mode to be the default state of the UI and the underlying renderer, not a special mode one would have to activate. In light of (pun intended) the above discussion about emission and default / scene lights, this was the only logical way to go. On top of that, the >Ignore Scene Lights option does not switch the renderer into a different mode, it simply assumes any existing scene lights are actually turned off. (you could do that with the Light Lister, but it would be a PITA). At a certain point in the development, that option was nearly removed from the system, but it was deemed necessary to quickly produce Self-Illuminated particles using the Emission channel without taking scene lights into account.

And here we come to the third major change - Additve Rendering in Krakatoa v1.1.x used to be a distinct rendering state as opposed to Volumetric Rendering. But Krakatoa v1.5.0 implemented the full volumetric shading equation with Scattering (Color), Absorption and Emission terms, making it possible to control how much color is scattered into the eye, how much is absorbed from each color component as light passes through the particles and how much light is emitted by the particles. Additive rendering is simply fully Emissive rendering lacking Scattering and Absorption, which means that now we can define PER PARTICLE whether it should be rendered volumetrically or additively (or somewhere in between).
You can find more info here.

Knowing that our users will still want to be able to render particles additively without much clicking around the UI (Krakatoa has been doing additive rendering long before it even had that name, since around 2004), we decided to add a special option called  >Force Additive Mode. What this option does is this: it copies the Color channel into the Emission channel, while setting both Color and Absorption to black. Thus, particles do not absorb light, do not scatter any light into the eye, they just emit light and accumulate into the pixels as desired. To illustrate what is going on, the >Use Emission and >Use Absorption options are getting grayed out in that mode. In this case, scene lights are also ignored completely even if >Ignore Scene Lights is not checked - particles with black Color and Absorption would produce no lighting effects at all, while wasting time sorting for attenuation map drawing that would not be used anyway...

As you can see, we wanted to make Krakatoa a lot more flexible by providing per-particle channels for the main shading values, but this required some changes to be made to both the default behavior of the renderer and to the controls in its User Interface.


Understanding the processes going on inside the renderer and the logic behind these changes should help you master the new version and lose your old habits built in the less advanced environment of Krakatoa 1.1.x.

I have the feeling I will continue this post in the near future with some more notes on feature and UI changes, so stay tuned!...

Friday, October 23, 2009

Krakatoa Icons Are There To Make Your Life Easier

Over two years ago Krakatoa 1.0.0 shipped to customers, packaged with some useful MacroScripts (even including pictures of volcanoes). To this day, I shake my head in disbelief when I see that nobody is using them.

As usual, some back story.

Krakatoa was implemented as a .DLR, a Render Plugin like most other 3rd party renderers. Normally, a Max-compliant renderer provides one or more tabs with one or more rollouts inside the Render Dialog. But designing User Interfaces using a resource editor in Visual Studio is a task nobody really enjoys. It is so last millennium, and a real PITA. Before Krakatoa, another renderer (or rather, bridge to a renderer) was under development by the same team - Amaretto. In both cases, the decision was made to split the UI and the core code and implement as many controls as possible using MAXScript. This had several positive implications:
  • The UI could be developed A LOT faster.
  • Fixes to UI bugs could be made without even restarting Max.
  • Fixes to UI bugs could be distributed to customers by simply replacing an .MS file without recompiling the DLR, often the same HOUR the bug was reported. In fact, some fixes during Beta were even distributed by telling the user what line to edit or remark (Do It Yourself fixing!)
  • Customers could replace portions of the code or modify the UI if desired, as well  as read the UI scripts and learn how to access all internal properties of the renderer. All scripted components ship unprotected.
  • Last but not least, the UI design and implementation could be taken over by someone outside of the RnD team, someone who uses the software in production and knows a bit of MAXScript... That's how I got involved.
This design decision for Amaretto carried over to Krakatoa. In fact, the original UI of Krakatoa written by Mark Wiebe, the "father" and "godfather" of the volumetric particle renderer, was an edited version of the Amaretto UI script file. Krakatoa was already in early Beta when I tried to use that UI and immediately felt the desire to modify it.

One negative side effect of all this was the inability to display the UI inside the Renderer tab of the Render Scene dialog. It is simply not possible to add scripted rollouts to that tab. So the solution was to add a big fat button to that rollout which would then open the scripted UI of the renderer. This was, of course, a slightly inconvenient and quite untypical workflow.

At this point in time, Max 6 had come and gone and the Production/Draft slots of the renderer were replaced by Production only and the ability to save/load render presets. We started discussing ways to keep Krakatoa assigned as the renderer while being able to switch to Scanline, mental ray, VRay, Brazil, you name it. We did not want to lose the current settings of Krakatoa, but the fact that Krakatoa required cooperation with another renderer to produce the final image (including casting shadows from particles onto geometry) meant that we had to make it easy for the user to swap back and forth.

To my surprise, the Render Presets turned out to work great with Krakatoa despite the fact Krakatoa doesn't even use Parameter Blocks like any other Max plugin (our developers found Parameter Blocks clunky and not very stable when changing their structure between versions, so both Amaretto and Krakatoa use a custom string-based storage for all non-animatable / non-object-related properties). So saving and loading a Render Preset with Krakatoa restored everything perfectly.

As result, I decided to create two MacroScripts that would:
  • Assign Krakatoa as the current renderer if it isn't the current renderer yet when the "Toggle GUI On/Off" is checked, while storing the last renderer's settings in a Render Preset before assigning Krakatoa.
  • Toggle the Krakatoa UI on and off when the main icon is checked/unchecked.
  • Load the last renderer's settings from that preset if the "Remove Krakatoa" button is pressed, while saving the current Krakatoa settings to another Render Preset
  • Load back Krakatoa via that Render Preset if the Toggle button was checked again.
  • Provide a prompt to let the user reset Krakatoa to factory defaults instead of loading a previous Render Preset if desired.
These MacroScripts can be found along with a dozen other useful buttons in the Krakatoa category of the Customize User Interface. They are the MAIN BUTTONS to access Krakatoa, much faster and more powerful than the Open Krakatoa GUI and Assign Renderer controls in the Render Scene Dialog.

The fact nobody seems to use them makes me sad. It even makes me write Blogs, as you can see here...

So I beg you, if you are a Krakatoa user, spend 2 minutes to create a Krakatoa toolbar and drag the most vital icons to it. Once you start using them, you will be
  • Orders of magnitude more productive
  • A Happier Person
The available icons are documented here, in the Fine Manual Nobody Reads:
http://software.primefocusworld.com/software/support/krakatoa/macroscripts.php

Some of the other icons provide one-click creation of PRT Loaders, one-click creation of PRT Volumes from any number of selected geometry objects, one-click assignment of KCMs to any number of selected supported objects, as well as buttons to access the Krakatoa Log Window, the Shadows On Geometry utility, and the ONLY way to access the Krakatoa Schematic Flow tool introduced in v1.5.1.

Obviously, you can even assign these MacroScripts to keyboard shortcuts if you want to be even faster!

This information is already in the Online Documentation, but I hope a Blog will be more effective in spreading the word. To quote a sign that hangs in our office, "Only YOU Can Prevent Render Madness!" Make your life easier. Use the shortcuts!