Wreak Havoc

The challenge has been an astounding journey, I was able to explore a wide variety of effects, from rigid bodies to FLIP and Pyro simulations to procedural animation.

I also learned workflow optimization, pipeline, lighting and rendering, and so on. With this new knowledge, every day produced something unexpected that I needed to overcome, developing at the same time my research and problem-solving skills. Furthermore, the required updates were the opportunity to break down my work and improve my English, a great writing practice.

This is the first time that I have attempted a project of this magnitude. I was nervous at first about taking on the challenge, but the encouragement from my friends definitely made me face my fears and give my all. The pinnacle of my five years learning Houdini.

The sense of achievement in delivering my biggest project to date, far beyond what I thought to know doing, and seeing the incredible effort that all the contestants put into their entries made this one-of-a-kind challenge a very rewarding experience!

Yet the adventure barely begins. With all the knowledge I'll take away, I can't wait to work on future projects. Huge thanks to Rebelway, the Rookies, and their sponsors to make the challenge possible!

Project Planning

To plan the project, I needed to identify the different steps needed to create the shots. I split the effects into small steps to help manage them.

With that list, I started a Gantt Chart to schedule the tasks. Thanks to that I could have an overall view of the project, knowing which part was in work and if it was on time. Also, I could manage the amount of time that a task can be delayed without causing a delay to other subsequent tasks of the project completion.

Since this is a huge project for me, I thought that with enough preparation, I could be confident that I could avoid some bad surprises down the road or having the project getting out of hand. 

Remote work

All simulations, and some renders, like the final explosion and the temple flames, were handled on my workstation, while rendering was done on a second computer.

Although I worked most of the project on my PC, for the rendering part, I had to work remotely on another computer to benefit performance that could reduce render time and enhance image quality. To get the most of the available rendering capacity, I split rendering on both workstations.

Thanks to Teamviewer free version, I could remotely check renders, manipulate files and launch new renders from anywhere to save time (for example from my PC, my full-time job when I was on break, or even my phone if my workstation crashed).

Sound Design

The challenge doesn't expect sound design. And for a good reason: not only it adds more work, but it can also distract from the shot. But often, when you talk about FX, you start making all of these noises, pops etc. So I thought that working on the sound design could be a cool way to emphasize the action.

For the sound design to be efficient, I wanted to tell the story with the sounds, supported by the soundtrack that will blend everything.

Each effect has its sound choreographed and spatialized for maximum impact and immersion. This way, the image, and the sound should flow seamlessly together, without taking us out of the story or because of the sound effect.

Renderer

Once all the caches are complete, the assets can now receive their dedicated shaders.

We were fortunate to be supported by SideFX, which provided us with an Indie license of Houdini for the challenge period. Thanks to this license, I could discover other renderers than Mantra or Karma.

For the rendering, I choose Arnold for its advanced Monte Carlo ray tracing renderer that helped quickly get realistic results, leaving more time for iterations. The shot was the perfect occasion to give it a try.

Hydra's Shader

Fortunately, the Hydralisk model was provided with UV's. That avoids a lot of pain and allows going straight ahead to have fun in the shading stage.

The monster is a very old demon that was trapped under the temple a long time ago. To represent that, I tried to achieve procedurally the look of aged skin shader inside Houdini.

Additional maps (normals, roughness, and displacement) were generated to retrieve as much information as possible from the albedo texture. I think the original geometry was intentionally lacking detail that gives me more freedom to explore and develop various procedural textures and patterns.

The final result was achieved using different noises, curvatures, and playing with the components of the material.

For the burned state, I used the source areas computed previously for the skin peeling simulation to drive the components and layering of the different materials.

This allowed emphasizing the ravage due to the spell burning. Even if all of this will be seen from far away and partially lost in compositing, I think that like in Pareto's law, 80% of the final look will come from the tiny 20% of more details added.

Hydra's Skin Damage

After shooting all that energy during the ultimate spell, the expectation would be to see the devastating repercussions on the monster: the skin of the monster falls to pieces, over-heated by the spell.

The spell's color attribute is transferred to the points near the impact on the Hydralisk geometry. A solver helps keep the color on the points once transferred. An additional fade was added to be used for the impact trail (like laser burn).

Different distances threshold wield to serve different purposes: a large threshold that defines peel area for skin fracture and cloth simulation, and a lower threshold (nearer the impact point) for delete skin pieces at impact and create color ramps to represent burned skin and dermis.

This allowed me to control how much of the Hydralisk's skin was crumbling as it burned. Besides the cloth simulation, all other aspects were handled without simulation involved, allowing to tweak the visibility of the flesh and degree of burning during the sequence.

The Hydralisk base geometry is split into two layers: the base that will be fractured then used as Vellum cloth for the skin peeling, and the dermis geometry made from the slightly eroded VDB of the beast's base geometry.

The skin relies on two constraints: "attach" that will stick the whole skin to the underlying dermis geometry, and "weld" that stitches the skin pieces together.

The transferred color from the spell is used as an attribute to break the constraints near impact making the skin crumble and fall naturally as the monster moved.

Finally, cloth pieces under the impact point are deleted revealing the hotter area of the dermis underneath.

The initial dermis color is made with mismatched noises to give the flesh look. Previously transferred color from impact defines the area where further noises are added on top of the dermis base initial color.

Thanks to provided UV's, the noise could follow the deformation of the geometry avoiding the feel of static noise on top of deforming object.

And a similar approach was taken to color the overlying burned skin.

From that starting point, the dermis geometry will operate as the source and the peeled skin as collision for the later smoke simulation that will happen after the spell explosion, when the monster skin cools down.

On top of that, an additional skin shreds simulation synced to the explosion is added to reinforce the feel of damaged skin. These shreds will serve as a source for residual skin shred burning simulation.

Fierce Chaser Spell

The effect is the combination of different layers that needed to be integrated together to make it look cohesive.

The move is decomposed into three steps: the charging, when the hero focuses his energy to summon the spell, then the loading during which the actual spell grows and strengthens, and finally, the casting when the spell is cast.

A similar setup to the previous shield triggering was used for the charging step but with a slower animation to emphasize all the energy needed by the cyborg to create the spell.

During my research for the loading step, I stumbled upon the amazing Big Bang animation by Charles "BigBlueBoo" Deck, a combination of creative coding and “generative design".

I wanted to give it a try recreating something similar. Without programming knowledge, I broke the effect in two setups. At first, the animation is based on a particle sim where target points get attracted by the hunter's point, once targets get trapped by the hunter's attraction, they stick on it.

Next, the hunter's growing size is handled by a custom solver to compute the point scale attribute by addition of the hunter size to the target points that stick to it. This is similar to the coalescing phenomenon of water droplets. A trail was added to the hunter to emphasize its growth.

For the rays, lines are randomly scattered on a sphere with normals pointing toward the chaser head.

Cast

The design of the spell cast was developed to refer to the stylized effects in animes but recreated with 3d elements and the stage scale in mind.

I took the inspiration from Yu Yu Hakusho's Spirit Gun attack.

In the beginning, the spell has the appearance of a small beam of light that can travel long distances with considerable speed; then the size and intensity of the explosion increase dramatically, allowing the hero to generate bursts of large scale.

Shield Explosion

As touched on previously for the triggering, the shield displacement is handled through VOPs. It was a very enjoyable experience working with different noises and masks with various attributes to move the points. I was able to explore a wide range of abstract shapes while keeping control of the animation.

A random selection of points from the shield is used to create the shockwave at the end of the explosion.

Stains

To avoid the visual continuity of the shot being broken, the shield left stains on the character due to the particles constituting the shield hitting him when the explosion happens.

Internal Structure Color

Behind the dome that represents the robot's face, instead of a fixed pattern, a particle simulation reflects the robot's emotions’. This is its 'Nucleus'.

This part started out colorful but it was distracting. Also, I wanted to avoid the look of floating particles with random forces applied to them.

Instead, I decided to go with a look inspired by the iridescent surface of a soap bubble: the particle's color and their motion would show the character's thought flow as time passes.
This way, the hero's face was a bit more hypnotic as you stared into his face.

In order to represent the tension and energy flowing across the body of the cyborg, my references were a blend between Green Lantern's suit and the colors from Thor's Bifrost.

Velocity trails were the base for the coloring. Trails are made from points computed through the velocity volume around the character.

Their color (infrared) is mapped on the magnitude of the velocity at each location. Because the magnitude is not too harsh between regions, the colors mix well together offering interesting variations in the color range.

Once the color of the trails transferred to the cyborg's internal body structure, their deformation creates the noise representing the energy flowing through the artificial muscles.

Thanks to the cross-product function, some parts of the structure were colored in such a way that they change color depending on the areas where the muscle's fibers are contracted.

Shield

In the heat of the moment, the Hero triggers its shield just in time to block the attack. Because of that, the Hydralisk's hook gets trapped through the shield.

Struggling to break the shield, the beast generates multiple impacts with the particles that form the shield.

The structure of the shield is inspired by spider webs that are made to catch the prey on the fly. For the colors and the middle splash, the shield's painting look represents the raw feeling of the Hero at the moment. Like an artist who paints frantically to express their raw feel without refining shapes, not to represent but to make feel its thought.

The splash is the only particle layer of the shield that has been simulated. Other layers are manipulated through VOPs.

To add dynamism to the impact of the hook into the shield, I used Houdini's Ripple Solver to displace the proxy geometry of the shield. The particles are then projected onto the shield geometry, the parts that are on the bumped area get distorted by the displacement giving the sense of rippling.

This setup allows me to work on the rippling effect without having to tweak parameters in the base shield generation.

A sonar effect is added on top to emphasize the shockwave of the collisions between the hook and the particles. I was inspired by The Dark Knight sequence in which he uses his spy vision to locate hostages.

A sphere with a growing animation on 4-5 frames is copied on the points hit by the hook. Their animation is offset thanks to a custom solver created for the effect. The solver creates an attribute on each point that stores on which frame they get collided.

The sphere's color fades and blurs over time. The color is then transferred to points scattered on the shield to achieve the look.

Pillars Smoke

The pillar's smoke is based on the same setup as the stairs but with some adjustments. Despite the interesting results, something was missing.

After checking for references, I found that the collision was injecting velocity into the simulation as planned (that's why the pieces seem to drag the smoke),

but the volume of the ambient air pushed by the moving pieces was not present. This phenomenon is more visible of large destruction e.g.

during a building collapsing, when the falling debris hits the ground, the dust is pushed not just by the debris themselves but by the air around them.

To create the effect, I created an additional pyro simulation with only the velocity sourced from the collision geometry. No density, temperature, etc.

The velocity is then injected into the divergence field of the base smoke simulation. This gives more volume to the smoke, maintaining it floating a bit before dissipating.

A second dust simulation with particles advected by the smoke is added to create another layer of dust: the heavier that falls on the ground and the finer one floating in the air.

 Drool

I always found FLIP Simulation fascinating, so when the Hydralisk is roaring, I took the opportunity to experiment with new tools.

The drool is made from two layers: liquid saliva (that sink from the beast's mouth) and doughy saliva (that forms strings of saliva inside the mouth).

Liquid saliva is handled by FLIP solver while Vellum Grains is used for the doughy saliva.

 Smoke

After the stairs and the dust are cached, they are brought for smoke source generation. The geometries are imported along with their proxy collision.

The smoke source is generated from two streams:

The first is generated from the fast-moving pieces within a defined threshold from the stairs destruction geometry.

Imagining that the Hydralisk would have some residual dust on it when emerging from the ground, I thought about adding smoke that follows the Hydralisk's moves. The base idea was to emit from the monster geometry, but the result ending in too much smoke to handle for my computer.

Knowing that the cached sequence could be huge at the end (400-500 frames multiplied by ~ 5-150Mo/files), I had to find a way to keep the files small enough (without losing too much data).

The Hydralisk's part of the dust simulation is used as a second source. The dust falling from the creature matches its moves and adds more realism to the falling dust. It also reduced the amount of smoke in the sim, impacting the cache size.

Color has its own field created to be pushed by the velocity field. Noise is applied to the source color to get even more variance.
Having the color field advected played a huge role in the look of the smoke. The blend of the different-colored smoke sources (brown for the soil and grey for the cement of the stairs) adds further textural details on the smoke density.

Thanks to Houdini Sparse Pyro Solver, setting up the smoke simulation was unbelievably straightforward.

Parameters:
- Voxel Size: 0.06
- Dissipation: 0.15
- Disturbance: 3 layers of noises with different block sizes and strengths.
- Turbulence: 0.1
Sim time: ~ 2 hours for 200 frames / 5Gb cache size.

The computed volumes are then converted into 16-bits float VDB. Velocity (vel.x/y/z) and color (Cd.x/y/z) are merged into a single VDB field. This compression step helped to reduce by half the size of the cache.

 Flipbook and cache

To avoid choosing between waiting for the cache to be completed or make a quick flipbook then write the cache, a quick setup helped to do both without rely on Houdini's PDG. With this, the flipbook is generated at the same time that the cache is written.

Houdini cooks downstream. Based on that, the sim data are split into two streams: one for the caching and another one for the flipbook.

In the caching stream, after writing the files, the stream is emptied.

The two streams are then merged (one from the simulation, another empty), outputting the sim result in the viewport (as if the display flag was on the sim node).

To cook the merge node, Houdini needs to compute the two flows upstream. Thereby, Houdini writes the cache files and output to the flipbook at the same time.

This helped me save a lot of time, knowing that even if the flipbook was canceled, I could not only access the entire cache on disk, instead of just the last frame saved in the memory but also estimate the cache size before saving the entire simulation. I will pack this setup into an HDA to use for further simulations.

Pillars

The pillars are passed through the same setup as the stairs for the destruction and dust generation.

However, the stairs and the pillars are simulated separately to be able to adjust the settings depending on which part is destroyed ( e.g.: the pillars have different properties (density, friction, bounce) than the material of the stairs).
Also, it avoids re-sim all elements just for one part of it.

Note: shield design is currently in dev, so I will re-cache with proper collision.

Sim Time:
Lo: DOP Substeps: 3 / RBD Solver Substeps: 80 / Constraints Iterations: 300  > 1h25m
Hi: DOP Substeps: 1 / RBD Solver Substeps: 10 / Constraints Iterations: 10  >21m
Dust: 40m

Dust

The dust is generated from two sources: the stairs and the Hydralisk.

For the stairs, point emission sources of the debris are generated from the separating fractured pieces.

As to the Hydra, the point source is generated by transferring color from the stairs to the monster. With a fade the color slowly disappear, avoiding having dust falling continuously.

Points are scattered on the concerned surface.

Stairs destruction

The stairs destruction was very challenging. Since this is the entry of the Hydralisk, the destruction has to be huge and detailed enough to put the emphasis on the monster's strength without destroying all elements around him to keep space for the rest of the action.

As touched on earlier, the destruction setup has to be simple enough for me to iterate fast and caches have to be light enough to be able to load and merge all elements later since it's a huge scale.

My approach was to start from a low-res RBD simulation to drive the hi-res sim (as shown in the pre-production). Using the computed destruction area, I was able to fracture only the active pieces, avoiding fracturing pieces that will not be destroyed. To add details, there is also a fractured ground layer under the stairs.

The constraints are a mix of glue and soft constraints. The glue (intracluster) keeps the cluster together while the soft constraints (cluster to cluster) allows the geometry to bend before breaking.

Chains

In the story, the Hydralisk escapes from the catacombs under the temple.
To illustrate that, I added chains to the beast's arms. Adding this kind of detail can quickly become fancy work since the challenge focus on the FX.

However, I think it would help understand the context of the conflict between the two characters. Also, the chains are simulated, adding emphasis on the monster's moves.

To avoid spending too much time on this "bonus", I choose Houdini's Vellum cloth to simulate the chains hanging. This is basically a line with points on which the link's geo will be instanced. Note that the ending link of each chain is broken.

Scale

Prior to the temple construction, the first step was to establish the right scale of the characters. The environment and the FX depends on it.
As a reference, the cyborg is at human scale (approx. 1.8m tall). Proportionally, the Hydralisk is  ~16 m tall.
With these informations, I could build the temple.

Construction

My reference for the temple was "The Ark" by Bart Tchorzewski. At this step, to avoid having objects being awkwardly placed in the space, I started thinking about how the monster moves in the space to build interesting parts which the monster would interact with. The layout also has to emphasize the size of the Hydralisk, this will help a better reading of the scene.  The temple was made procedurally in Houdini to be able to quickly adjust the different parts to fit the action.

Damage Area

Having now the base environment and the characters, the collision areas can be computed. This helps visualize the size and the position of th areas that will be processed for destruction.

Research

Before beginning the project, I wanted to verify if I could make a soil destruction. 
The setup has to be sufficiently light to be handled by my computer knowing it will be used in a big scale scene.