Dax Pandhi is a CG environment specialist and co-founder of QuadSpinner. He has contributed to a variety of AAA titles for film and games, including the critically acclaimed Battlestar Galactica: Blood and Chrome. He is also a teacher and author with 18 years of experience in CGI. Read more ...

Understanding Helios - #1

In this first of a series of blog posts, I will take you through the conception of Helios, the thinking behind its creation, and a glimpse at how the core light processing logic was born.

Helios can be said to have started, technically, two years ago when I created a bunch of clouds that I kept reusing across my scenes. They were starting points to which I applied specific settings – predefined formulae for achieving a distinct look for the type of cloud I wanted. But Helios really took form in a hotel room in Los Angeles last year after the Master Class. It wasn’t a moment of inspiration where everything suddenly appeared right in front of my eyes. Nothing that glamorous. But it became apparent that instead of figuring out how to make the cloud library reusable for everyone else inside Vue, a better solution is to create a handling utility.

The first Helios prototype rendering a large cloudscape.

When you create a reusable solution – something that people might use in unexpected ways and in unimaginable scenarios – there is always a chance they may use settings that you don’t want them to use (because it may break a fractal function, for example). To overcome this, a plugin – a utility application that handles the special tasks that the host was not originally designed for – becomes the best logical choice.

Helios is a two-part piece of software that works inside of e-on software’s Vue Infinite. When used via Vue’s xStream plugins, it can work inside 3dsmax, C4D, LightWave, Maya, and XSI. The first part is the Python plugin that serves as a communication node between Vue and the Helios software. The second is the Helios UI, a Windows application that handles all the logic and the interface for working with the Helios library.

 

Why a separate interface?

There is a complex combination of settings that go into every Helios cloud – in fact, they are different for each individual cloud type.

Let me explain that in two parts: For a cumulus cloud, the density settings are in a specific range than what may be useful for, say, a cirrus cloud. This becomes more complicated when you factor in relative settings such as opacity. Opacity for a cloud type is not always the same – it depends on multiple factors, including density.

Now think of distinctive features of each cloud type: a cumulus or cumulonimbus will churn and grow; a cirrus or stratus will drift without changing shape too much; aurora will bend and shimmer like ribbons; virga will drift and curve.

If you look at Vue’s interface for creating and managing clouds, providing control for the above mentioned qualities is quite a difficult task. It can be done, no doubt about that, but it is comparable to creating your own motherboard instead of buying one.

So, as mentioned before, there are complex combinations of settings for each cloud type. To provide easy access with a minimal learning curve, the most logical course of action was to create our own UI that handled things in a different way. Technically, when you compare the Helios UI to the Vue Atmosphere Editor, we are providing a deceptively simpler set of controls that provide methods of creating the desired visuals, without the user engaging in a perpetual cycle of trial and error.

We intend to ship a library of hundreds of clouds, each with unique settings. To handle that sort of data, we created our own cloud format that stores these settings. Processing and loading them all in a fast manner was going beyond Python’s capabilities so we started putting all of that code into a Windows WPF application, which is now the Helios UI and logic center.

oldUI

A very early Helios UI prototype – these controls helped shape the current version which will be revealed soon. The majority of the controls shown here were depreciated into more precise control sets.

In practical terms, Helios is launched as a separate window. Users with two monitors can take extra advantage of this, obviously, but it works well on a single monitor as well. When using Helios clouds, it is required that all cloud matters are handled in that UI and not the Atmosphere Editor.

 

Subvapor Thinking

The image below shows how Subsurface Scattering looks. The sphere on the left is translucent using SSS; the middle sphere is the same material with SSS disabled. The right sphere uses a clever combination of coloration and light angles to imitate SSS. While not as detailed as the ‘real’ thing, the effect is believable. And, the render time is about 1/15 compared to real SSS!

 

Helios’ clouds use this same mechanism. As a result, they appear fluffier than Vue’s normal clouds.

In Helios this feature is exposed in the form of Subvapor controls. The image below shows two different levels of Subvapor Lighting. The Helios website has a comparison to Vue default clouds.

Compare2Compare1

Subvapor Lighting strengths: Low (Top), Medium-High (Bottom)

 

The Subvapor controls represent a full third of the settings available for Helios clouds. The Subvapor presets library represents over 18,000 weather and lighting conditions based on field research across several continents. Subvapor methodology has been a primary focus in our R&D, and I’ll be writing more on how this will change the way you work with clouds.

 

In the next post...

I will talk about the immense role that motion plays in Helios clouds. We made a strong distinction between shape and motion, which will be apparent in the UI itself. The biggest difference you see when using Helios, is that the interface transforms as you manage different types of clouds. I will also show examples of how Helios clouds interact with objects, lights, and other clouds.