Destruction in Reverse

Understanding Helios - #1

Fri, 24 Feb 2012 09:09:59 -1300

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.

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.

Making of the Helios Volcano

Fri, 17 Feb 2012 04:09:37 -1300

This is an account from the beginning concept to the final compositing of the grand finale of the Helios preview video. This single scene became such a powerful example that the Helios software was rewritten to include a smoke plume cloud type.

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.

I am Thunderhead - Helios Teaser video

Mon, 13 Feb 2012 23:45:17 -1300

The teaser video for Helios, QuadSpinner's new cloud tech, was created literally in one night - including 2 complete renders and one mis-render. I have talked about dogfooding before. When you are constantly making products and techniques, dogfood (i.e., using your own product) is basically a constant part of your diet. But all of that is worth it when it tastes great!!

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.

Balancing the Master Class

Thu, 11 Aug 2011 12:15:00 -1300

How do you pick content to fit in 7 hours that you have experienced over the course of 15,000 hours?

That is the question I’ve been grappling with for the past few weeks since we announced the Master Class. The overall list of items to cover has been ready for several months and keeps on increasing. It is clear that everything cannot be covered, so what should be kept and what should be saved for another class?

Good Vue training is not that hard to find. (In fact, we have some good training videos if you want a head start before the class.) The problem is that large scale animation needed for film and television is vastly different than creating still images. The latter is where most Vue training products excel, but unfortunately the pros can become cons when applied to an animation project. What makes our Master Class different from any other training seminar is that it is built specifically for such large scale animation projects.

My basic formula for the content became:

realism + superior creative control + cost-effective implementation + fast render output

The following is a list of aspects and specific items that are the central pillars of the content of the Class.

Visuals

That is almost a given. First and foremost, everything in the class must count towards the end-goal of excellent visual realism. This thread is richly interwoven throughout the entire presentation.

Interpreting Nature in Vue’s terms

This became the first segment of the class. The majority of attendees are familiar with Vue or at least the general concepts of the software. The core fractal nature of Vue is similar to the hypothesized Higgs boson particle – understanding that most basic element can open you up to all the possibilities of Vue.

The harder part is translating something you see out in nature in Vue terms. This is where all the Vue expeditions come in.

Hundreds of hours spent in the field, interpreting natural patterns into Vue fractal space are merged with an understanding of integrating artistic/creative flexibility. The resulting set of design principles are explained in the primer part of the class and then spread throughout the rest of the content in context-sensitive blocks.

The end-goal being that if you follow these principles, even the most outlandish, alien environments can be made to look real and believable.

Erosion

This is a huge, huge deal! So many people have expressed interest in better terrain design. This is where the Vue-World Machine pipeline comes in. One entire segment of the class is dedicated to integrating World Machine into Vue.

By using complex graphs on top of imported Vue procedural terrains (below), or designed from scratch (above) we redefine the entire process of terrain design.

Great terrains are at the heart of just about any environment you create. The unique techniques presented in the terrain segment of the class are geared towards broader usage of the terrains, and not just simply having the terrain be the goal itself. In other words: material, texture, ecosystem, and other aspects of the scene are taken into consideration when crafting the terrain and then special excerpts and outputs of the terrain are used to achieve both superior realism and incredible creative control.

The procedural nature of this pipeline allows for instant and vastly powerful editing. Allowing for creative direction to alter the design without rupturing the delicately balanced procedural graphs was a key aspect when this pipeline was being built.

Atmosphere + Light

Lighting a scene in Vue often becomes quite different – if you are intent on realism – than in any other 3D package. Lighting is the de facto key element for any environment, and the entire segment on Atmosphere and Lighting in the Master Class focuses on how a 3D artist needs to realign their thinking for Vue.

Economy

This is perhaps the hallmark of this class. A whole segment at the end of the class is called ‘The Economy of Natural Design’ – roughly translated to ‘what you can get away with’.

The entire content of this segment focuses on maintaining a balance between pushing the software for better visuals, while pushing it for faster output.

The most basic result of this is speed in terms of rendering. But at the same time, it also talks about minimizing the effort needed to be applied, cutting corners in crafting the scene, and creating massive scenes without a massive budget.

Blazing Renders

Clicking the image above will bring up a 4000px version. We ran many tests on an i7 laptop, i7 980 Extreme workstation, and thanks to my friend Marek Mihok, a dual Xeon (24 cores, gazillion GBs of RAM, etc.). The Xeon config is roughly equal to 3 or 4 typical render nodes found in any modern render farm.

On the i7 machines we could easily get 720p frames between 10 to 30 minutes per frame. On the Xeon, again equivalent to a very small render farm, we could get it to under 10 minutes.

As one of our focuses in the class is about large scale production, we decided to test frames from the trailer at 4000 pixels wide output. The render times are significantly low for 4k frames, and can still be optimized further.

If the requirement is matte painting where you need an image base as opposed to a full animation, then this opens up the avenue for rendering several thousand pixel tall images.

Matte + Compositing Considerations

Speaking of matte paintings, spread throughout the class is special content for matte painting and compositing considerations. This can be as simple as a set of filtered output techniques, to complex multipass renders where layers and layers of visual data are separated from the overall render for further enhancement and compositing.

Layered output in matte paintings is nothing new, but the class also focuses on structuring scenes specifically for layered output so that if the direction changes or something new needs to be tried, the amount of work is minimized.

I will continue to write more about the class and share some visuals from the content, so stay tuned.

If you still haven’t signed up for the Master Class, I recommend you register before we run out of seats.

Granular Nature - excerpt from the Master Class

Fri, 29 Jul 2011 08:13:00 -1300

This scene is a live exercise I’ll be showing at the Master Class.

One of the key things that helps rocky scenes like the one below is granularity. But that effect is difficult to achieve and sometimes slow to render if you go for good quality. The balanced solution lies in HyperTextures and HyperBlobs.

HyperTextures are common enough in 3D, but in Vue they take on a whole new process which is extended by the HyperBlob feature. The cave in the scene below is constructed entirely of HyperTextures and HyperBlobs. The central rock obelisks are HyperTerrains.

HyperTextures/Blobs can carry granular detail that you can’t accommodate in materials or are just too expensive to render with displacement.

Below is a breakdown of the single HyperTexture material used to power all the blobs in the scene. The essential HyperTexture material is created with a simple Fast Perlin Fractal which is the most economical for render speeds. The resulting untextured output can be seen on the left. That is what will shape the HyperBlob. The granular detail is present in the physical shape rather than simply painted as bumps on the material. On top of this HyperTexture, we have the GeoAffinity “Lavaline” material applied for the coloration and some minor bump texture.

Below is a close up of the left side of the image. You can see that even in indirectly lit parts, the granular nature of the HyperTexture is visible. A bump map cannot give you that light/shadow play in shadowed or under-lit areas.

The creation of this scene, building HyperTexture materials from scratch, and using HyperBlobs effectively will be covered in the Master Class in detail. Visit www.quadspinner.com for details.