Dakota Smith- Continuing with FX

Strike!

Strike! is an effects based project that I created for Sercan Yasar's VFX Design class at Gnomon. When figuring out what kind of project I wanted to undertake, I approached concepting with three major things in mind:

1. I wanted to make something magical.
2. I wanted to make something explode.
3. I wanted practice working with an absurd amount of data.

One idea led to another, and Strike! was conceived.

Scene Prep
Once I settled on a project idea and found workable footage online (thanks to Kelly Lacy on Pexels.com), the first steps I took in preparing the scene was tracking the footage and creating some proxy geometry  to represent the environment. Fortunately, I was able to use PF Track to take care of both these things in one go- using its camera tracker and photogrammetry toolsets to extract a moving 3D camera and proxy mesh of the environment. 

Previs
Before building out any of the actual effects systems, I did an overall previs pass on both of the shots in the sequence in Houdini. Not only would this give me vital information about how I would time and compose the shot, but it would also be the basis for the effects work what I would later implement. 

With the underlying animation complete, I was ready to start developing the effects.

The first effect that I developed was the comet. The main body of the comet was comprised of a couple of layered procedurally animated volumes- one for the head and one for the trail- as well as a small layer of whispy particles. While the main shaping of the volumes was done through volume manipulation in sops, I gave them an additional animated 'vel' field, which gave them a streaky look when they were rendered with motion blur.

The Main Effects
I built HDA setups for each of the major simulated effects elements in the scene. Each of these HDAs were built to give easy-to-access control over all of the major aspects- such as sourcing and simulation settings- for each individual occurrence of the effect. While the major simulation for each system was different (pyro for the explosions, FLIP for the plasma, and RBD for the rocks), each effect HDA also included a custom solver within that detected the frame and area of collision for each comet, which was used when sourcing each effect.

Handling Data
As I mentioned in my project brief, a large aspect of this project was managing a lot of data, which was definitely the case given the fact that I had five different trails, explosions, plasma hits, and rock debris hits. To deal with all of the different variations of each effect, I created several different TOPs setups to deal with the caching and moving of simulation files. The idea behind the main setup was using a TOPs attribute to point to different output nulls in SOPs (corresponding to the output points of each simulation iteration), which were in turn fed into a ROP geometry output.

When running this Topnet overnight, I was able to get a lot of data out, but frequently ran into network issues that would interrupt its cooking; therefore, for a quick solution, I elected to first write the cache files to the local disk, then move them to the main network drive where they would be stored, hence the inclusion of the file copy TOP. 

Additionally, while I could have elected to go with a more TOPs-centric setup (i.e utilizing wedging to get different variations of each effect), I opted to create the HDAs instead so that I could better art direct each individual iteration.

Rendering
I composed the final scene in Solaris within Houdini, and used Karma for the final renders. In order to quickly look-dev and iterate upon my effects, I utilized Karma XPU for first look renders; however, due to the current limitations of XPU rendering, I used the CPU engine for my final renders.

I'm a really big fan of using Solaris to compose my scenes for render because it gives me a really easy and hands-on way to break out each of my elements into their own render layers.

Compositing
Lastly, to finish the shot, I brought all of my render layers together in Nuke for the final composite. Creating a day-for-night composite ended up being somewhat of a last minute decision- all of my elements were initially lit to match the daytime plate; however, after seeing how difficult it was to get good color and glow reads on my effects, I was left wishing that the footage was shot at night. Then I remembered that I was doing a VFX shot for myself, and made it night. Ultimately, I think this decision made for a much more visually appealing shot. 

The comp itself was very straightforward; however, one extra (and nearly invisible) effect added in comp was the heat distortion that followed the comets as they fell. For this effect, I created several trailing pyro simulations, and using their renders to drive an IDistort in Nuke. 

PF Track - Houdini - Karma - Nuke

Candles and Bottles

Candles and Bottles was a self-indulgent tech test. On the surface, I wanted to create a simple scene with a basic setup that would leave me a lot of room to polish and make look nice; however, beneath the surface were a myriad of self imposed limitations that resulted in a very convoluted (yet fun) workflow. 

Project Obstacles

Prior to starting the project, these are some of the things that I wanted to accomplish, and some difficulties I anticipated I would have to overcome to accomplish those things.

Scene Assembly in Solaris, Render in Karma
Like I said before, I really enjoy the flexibility and visual aspects of composing a scene in Solaris. Also, Karma is a favorite render engine of mine; however, it is not a particularly fast renderer. Couple that with the fact that I was planning on rendering a bunch of nested dielectrics (the bottles and the "fluid" inside them), as well as the candles- which were SSS heavy- and I was looking at some very long render times. 

Moving Camera
I also wanted to have a moving camera in the scene to give it a more cinematic look, which meant that I could not just render a single frame, resulting in even longer render times. Obviously, the camera move in the final render is almost unnoticeable, so my solution to this was not watertight.

Day to Night Transition
This meant that I would need two lighting setups that ideally morph into one another, which of course meant I would need to render the scene at least twice.

Aware of the technical challenges I would face, I began assembling the scene. The bottles and shelf were recycled from an old project that I had worked on long ago, and the candles were modelled procedurally in Houdini. 

With all my assets finished, I was able to start bringing them into Solaris for look development and layout. When building the shaders for my assets, I elected to put them together by combining materialX BSDF nodes, just to see if I'd be able to recreate what is happening under the hood of the materialX standard Surface shader. Here's the network for the bottle shader, which ended up having the most layers.

After look development, I utilized Solaris' layout tools to assemble the scene. To layout the bottles, I used a scatter within a point instancer to get an initial placement and distribution, making minor tweaks by hand to finalize the composition.

With everything in place I was able to begin the relentless back and forth of rendering and compositing.

To begin the compositing process, I started by rendering a single frame of the night lighting setup with all of the lights generally in the positions I thought they should be in, set to the color white. I made sure to include a Beauty per light AOV for each of the lights in the scene so that I could control their color, intensity, and animation much more interactively in Nuke. 

When doing my initial light balancing, one of the first major things that I noticed was that the light passing through and reflecting off of the two main bottles in the foreground was a little too perfect, so I returned to Karma and rendered an 'st' pass, which I used to add grunge to that specific area in Nuke.

Next, I rendered several extra atmosphere passes to add on top. For these, I used Karma XPU to cut down on render times, which would be especially important when I added the moving camera; however, at the time I was working on this project, XPU did not support the use of very many LPEs, meaning  I had to create a separate render for every light I wanted to control in comp. While this definitely was not super efficient workflow wise, the use of Solaris made it very easy to break out each separate atmosphere layer, and the time I saved rendering made it worth it. Just like in my previous project, I utilized TOPs to manage and streamline this rendering process.

For the candle flames, I created a very simple candle flame simulation in Houdini, and created a basic TOPs wedging setup that created three unique flames that were cached then rendered. These were then placed on 3D cards within Nuke. Doing it this way made it much easier to coordinate their ignition times with the animated lights I had already established, and gave me the opportunity to rearrange them without having to wait for new renders. Obviously, by doing this I lost the interactive reflections of the flames on the bottles; however, because of the already lengthy render time of a single frame, I opted to go for efficiency over correctness, and while those reflections would have been very nice to have, time did not permit their addition, and it did not feel like they would make or break the scene.

To finish establishing the look of the shot, I added depth of field, several particulate layers, and various value balances. I then repeated the entire process for the daytime lighting setup. 

Adding the Camera Move

This is where my workflow gets a little silly. The process I took ended up being relatively involved, and had very little payoff; however, it was still fun to explore and I'm glad I tried it. Like I said, the render time of a single frame made rendering an entire sequence seem impossible, especially without access to a farm of any kind.

Once I had the base look established, I decided to render an intermediate comp from Nuke (without any atmospherics or finishing techniques applied), and re-project that render onto my scene geometry, baking in the lighting and animation. However, due to the nature of the camera move I was trying to accomplish, the projection of some of the foreground elements ended up spilling onto the background due to parallax. To remedy this, I re-rendered my scene from Karma, this time breaking it into the foreground elements and everything else. From there, I ran each foreground and background pass through the intermediate lighting comps that I established earlier, and re-projected those onto my scene geometry.

Despite my best efforts, I could not come up with a watertight system for dealing with the projection issues that resulted from the parallax, hence why the camera move is so subtle. Like I said earlier, it was a lot of extra effort for not a lot of payoff, but it was still worth a shot, and I learned a lot.

After rendering the re-projections, I ran these images through the final comp. This was the resulting Nuke script.

While I had larger ambitions for the day to night transition, time did not permit me to explore them to their fullest potential, and I ended up just fading between the day and night comp renders.

Houdini - Karma- Nuke

Hell Hand

A mysterious primordial goop serves as a catalyst for the earthly birth of a hellish entity. Surely this begets an era of chaos and damnation for humanity! 

The main objective of this project was to create a series of effects that could be integrated into a live action plate. When approaching concepting, I knew that I wanted to create at least one of the effects procedurally, and I wanted to make something kind of unsettling.

I was fortunate enough to find the perfect backplate (shot by Mart Productions on Pexels.com) for what I wanted to accomplish, and began the project by tracking it in PF track and creating proxy geometry to represent the environment.

​Two of the three main effects in this sequence- the tendrils and the lightning- were created and animated procedurally using curves. Meanwhile, the goop was created with a viscous FLIP sim.

​In order to further integrate the main effects into the shot, I created a series of tertiary effects that primarily impacted the environment. In the end, I added smoke hits and scorch marks to the environment wherever there was lightning interaction.

In the end, the scene was composed in Solaris and rendered with Karma. Lastly, I brought all of the rendered layers into Nuke for integration and finishing. 

PF Track - Houdini - Karma - Nuke

Closing Thoughts

If you made it all the way down here, thank you so much for taking the time to check out my work! I've had a blast making the projects above, and I'm really happy I get to share them with you. :)

 Sadly, this is the last time I'll be eligible for the Rookies, so if you're interested in following me as I continue my journey (or liked what you saw above :) ), feel free to follow me on linkedIn! I'd love to connect :)

Lastly, I would like to shout out all of the mentors and instructors that gave guidance on the projects above: Dan Bodenstein, Nate Shaw, Josh Hatton, Sercan Yasar, Matt Puchala, and Miguel Ortega. Thank you so much for your knowledge and support! 

Thanks again for tuning in, and hopefully see you sometime!