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.

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.

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.

This is the Helios “hero image”. Having a soft spot in my heart for volcanic things, a personal goal in building Helios was to have all sorts of clouds, not just those that float in the sky. In Vue, creating thunderheads has been just as hard as creating a realistic plume of smoke. Having seen various volcano “burps” - and with having QuadSpinner’s co-founder, Cynthia Najim, living right next door to the youngest and most active volcano in Central America - we had more than enough visual reference to take on this beast of a task.

The final image of a trailer has to be a finale in every sense of the word. We were searching for the perfect piece to end the Helios trailer with. It needed to represent the core values of the software. But the volcano was never in mind for that finale. The volcano started as an experiment in just how far we could push the clouds in Helios. The image below shows the first incarnation of the smoke.

Created using the same logic that was powering normal Cumulonimbus (Cb) in the library, this Plume cloud (Pl) was extrapolated as a new type. Instead of focusing on lateral movement like a Cb, the Pl goes upwards and expands. Normally, you work with multiple settings to scale different features of the plume, but with the Pl Cloud Type in Helios, you simply have a command called “Grow”. This takes care of growth in terms of height, thickness, subvapor light intensity, detailing of cloud features, and more.

Rather than using a one-size-fits-all approach, we divided each Cloud Type (read more about the types on the Helios website) into separate logic sets. In other words, we don’t apply the same settings or the same rules to all the cloud types. Cloud types (in nature) are diverse and their uniqueness needs to be captured accurately in the type of settings we expose for them.

The darker image above represents a fully formed Plume (Pl) cloud type. The coloration and Subvapor Lighting are treated differently without having to apply a new color tone.

To experiment with this new cloud type, I took it into a volcano scene where it was placed in the center of the cone and expanded as the volcano was erupting. The color hue was changed to look like smoke/ash and mud particles instead of an intense black smoke. You can also notice how the Pl cloud is interacting with the EcoSystem instances at the base by softly engulfing them.

The animation was working out quite well, but the setting needed a deeper dramatic tone. The volcano was made completely barren instead of having some vegetation on it. The visual toning went from bright blue day skies to a dark overcast night, with intense reds and browns controlling the entire palette. New explosive lighting and details were added to the Pl cloud by setting up a large number of Quadratic Omni lights in the cone of the volcano.

If you hover over the image below, you can see an original 3000 pixel wide isolated mask of the volcano plume. This is a Vue Multipass image.

Dark cloud cover was added to complete the mood of the image – at least for the pure 3D portion. Certain final lighting changes were made to make the image easier to work with in post-production. Once all the elements looked good, the scene was rendered in multipass to isolate the cloudy sky (Cs), the erupting volcano plume (Pl), and the volcano terrain itself. In post-production, video footage of colored particles was overlaid.

Finally, a color correction pass and some lighting effects were added to complete the animation.

This entire process was finished in a few hours. It was apparent to everyone on the team that this would be the defining image of the trailer. Large modifications were made to the trailer itself to have the impact of the volcano deeply integrated into the sequences. The particles took on a more prominent role as intro and outro for the trailer. We also re-sequenced the order of shots to flow better in terms of motion and color as the viewer was taken from one image to the next, resulting in an intense eruption at the end.

A video breakdown of this process is available on the Helios website in the Compositing section. The finished product can be seen at the end of the Helios preview video.

The volcano scene was too powerful and exciting to not expand upon. Currently, the scene is being extended to include more visuals and will eventually end up as a key pivotal shot in a future animation project. Keep checking back for updates.

Dogfood does not always taste good and you are always a little concerned right before you test out something is not yet complete, but a couple of nights ago, my friend Marek Mihok and I got a pleasant surprise.

Yesterday, we released a small teaser for HELIOS, our new cloud technology for e-on software’s Vue platform. The complete website with videos and examples, not to mention actual details of the product, will be released this Friday. But we had so many fans clamoring for something that we decided to do a quick animation. And it was almost an afterthought!

If you are unfamiliar with cloud rendering in Vue, a nice atmospheric render with heavy clouds can take 30 minutes or so for each 720p frame. Designing great looking clouds can be an elusive and cumbersome process too. We set out with a heavy goal for Helios to get rid of all of that: easy to create, quick to render. This is where the dogfood got tasty.

While still several months from release, the current alpha build of Helios, has a great library of handcrafted fractal clouds that look and behave very much like their real world counterparts. We have most of the internal logic down for features such as Subvapor Lighting (think SSS for clouds).

Using Helios’ cloud animation features, it took about 20 minutes to set up a great looking high altitude scene with majestic clouds that slowly animated (when you watch the animation, keep a close eye on how subtly the clouds transform) as the camera passed through them in early morning light. The original plan for this was not to use as a teaser but as an example for the product. The actual teaser was going to be just a simple static render. With 36 hours left before the teaser’s launch time, who would be crazy enough to decide to a brand new 1 minute animation!

It was rendering at 1280x545 (720p letterboxed Panavision in the end) with Helios’ render settings which cost less than a minute per frame and did not have any noise or grain! And this is on a single machine (i7 990X), NOT a render farm.

While the big render was running, I showed Marek a smaller resolution test render. He saw it and we both loved it, but he said “We need it to be slower! It will look great!”. At this point, I’m starting to sweat bullets. We were rendering 240 frames. It was going to take a while to do it and I was already thinking of what music to use on it and make it into a quick teaser for the weekend release of the actual site. If we were to double the length (or more, as the music demanded) then it would take even longer! No way was it going to be ready for tomorrow’s release!!

Thankfully, as usual, Marek was ready to help with his powerful dual Xeon. That machine can equal a typical 4 computer render farm. A frame that took 48 seconds on my i7 990X, took under 30 on Marek’s Xeon.

We stopped the previous 10 second animation that was already well into rendering. I went back and elongated the animation from 10 seconds to 45 seconds and send it to Marek to render. My projection showed it would be between 18 to 20 hours for the render to complete.

To get everything else ready, I did a 640x272 render of the same animation which finished in 2 hours and 30 minutes. I resampled it to 1280x545 and dropped it into After Effects so I can do all the additional post-processing and effects on it. Then it was laid down to music with timed titles. In a matter of 4 hours, everything was done and the trailer was ready. The only thing missing was the actual full resolution animation itself.

In a total of 8 hours and 30 minutes, the Xeon had finished the 545p animation render! All of this was 10 hours ahead of the projected “earliest” time. Helios was rendering each frame in under 30 seconds.

Best dogfood I’ve ever tasted!

The rest was just a simple matter of replacing the footage in After Effects and re-rendering the teaser video. The teaser, fondly titled “I am Thunderhead”, went online yesterday. You can watch it online or download the 95mb HD file at http://www.quadspinner.com/HELIOS/

Check the website this Friday (Feb 17) for the full release of the Helios website.