Dakota Smith- Getting Started in FX

The Crystal 

I love crystals, and I love lasers, so it only made sense to put them together in the most explosive way possible.  The objective of this project was to use the Houdini pyro toolset in an unusual or inventive way to create a magical effect.

The majority of this project was accomplished in Houdini. The crystal and background cliffs were modeled procedurally, and all of the effects were created with the Pyro and POP solvers.

To achieve the charging effect, I first emitted fluids from the body of the crystal, then used that fluid to advect particles that were also emitted from the crystal. Then, using the retiming tools in Houdini,  I reversed this effect. Conversely, to create the beam effect I used fast moving particles as the source for a pyro sim. While most of these particles shot directly upwards, I made it to where a few particles would shoot outwards to give the final beam a more volatile look.

For rendering, all of the assets and effects were transferred to Maya, where they were rendered in Redshift. I chose to render in Maya so that I could practice moving assets out of Houdini and into another package, which will come in handy should I ever need to hand assets off to another artist that does not work in Houdini.

Overall, my favorite part about working on this project was the act of layering many small effects on top of each other to create one large effect. 

Houdini - Maya - Redshift - Nuke

The Cave

After many dark hours wandering a labyrinthine cave, a weary knight happens upon an opening to a ravine, where he is met by a waterfall and fresh air. 

This project was an exercise in using FLIP and Pyro to create both water and fire in the same scene.

This project was also primarily created in Houdini. Pyro was used to create the torch flame, smoke, and mist elements, while FLIP was used to create the waterfall. 

The knight character was modeled and textured by Daniel Gryningstjerna, and the torch was modeled and textured by Sean Thomas. Otherwise, I was responsible for all other aspects of the scene.

When setting up my FLIP, I knew that one of the key ingredients to a successful sim  would be having interesting collision geometry for the water to interact with; therefore, I created several procedural cliffs that my water could flow over.

With the environment and effects completed, I once again transferred all of the elements to Maya so that they could be rendered in Redshift.

With all of the major components of the scene rendered in their own layers, I finished the project in Nuke, where I gave everything a little comp love.

Houdini - Maya - Redshift - Nuke

The Tower

This project has been one of my most technically involved projects to date. While it started out as an exercise in RBDs and destruction, it became the ultimate test of immense data management, optimization, and pipeline creation.

I began this project by procedurally modeling the tower in Houdini. By building the tower myself, not only did I get the opportunity to create it "brick by brick", but I also got to group the different parts of the tower as I worked, which helped a lot when it came to fracturing later on.

Here's a little demo of some of the tools that I made that helped in modeling the tower:

 Having a model made up of several thousand small pieces, I knew that it would be difficult to choreograph the larger actions if I simmed it immediately. Therefore, I decided that the most efficient way to start the simulation process is with a guide sim. 

I created a proxy version of the tower, fractured it, and gave it a simple constraint network. Besides hurling the boulder at it, I controlled the destruction of the tower by procedurally animating the deletion of the constraints. My goal was to first get a lot of pieces flying off the initial impact zone, then let the top of the tower fall off, then finish with the rest of the tower crumbling.

With the guide sim in place, I went back to the high-res tower and prepared it for the main simulation. 

Because the tower was already in a ton of pieces, it would have been impractical to fracture the whole thing; therefore, I isolated the areas around the main impact zone for fracture. All of the larger pieces also got fractured.

At this stage, the tower was several million polygons and was very hard to work with; therefore, with the geometry finalized, I was able to poly-reduce everything to make it more workable.  

From there, I set up clusters based on the pieces from the guide sim geometry, separated the active from inactive geometry, and set up a more complex constraint system.

Additionally, I established several groups of smaller clusters within the large clusters and grouped the bricks that were on the edges of these clusters so that I could easily manipulate their associated constraints during the final crumble.

When starting the main simulations, I wanted to test the ranges of values for my constraints without having to babysit a bunch of sims; therefore, I created a very basic wedging setup in TOPs that I could run overnight.

Diving into TOPs for this project was a huge efficiency boost for my workflow, and increased the number of iterations that I could produce immensely. If I got notes on my RBD simulation during the day, I was able to run it and all of my tertiary simulations overnight and would have a brand new iteration to evaluate in the morning, which was really helpful.

In addition to the guide sim, I further choreographed the tower breaking by adjusting the guide influence for each major group of bricks (i.e. the crown, the main body, the impact zone, etc.), as well as by deleting constraints  based on velocity. 

Because I simulated on a lower-res version of my tower geometry, I applied the transform data from the low-res sim points to the full-res geometry. This was only possible because of how thorough I was with the naming conventions of all of my pieces throughout the modeling, fracturing, and simulating processes. Ultimately, this decision saved me a lot of sim time and disk space.

Here is the final simulation without the dust:

For the vines, I simulated a bunch of curves as vellum strings and meshed them post simulation. 

With all of the simulations in place, I was able to begin rendering. For rendering, I decided to experiment with the new alpha version of Karma XPU. The speed at which it could render volumes made it a really attractive option, especially with how heavy the scene was at render time. I knew that I would face many limitations when it came to rendering for compositing, but I was interested in how far I could push this renderer.

Nonetheless, I was still able to render different passes using a few tricks. I utilized the materialX 'dot' node to create my own multimatte-like passes that let me extract correct alphas from separately rendered passes. 

I also used this technique to get material ID and Object ID Mattes out of the main tower render.

Additionally, the tower itself was shaded procedurally, randomly assigning one of a few brick materials to each brick using a material path attribute. This was one of the instances in which piece naming was really important, because I had to make sure that all of the pieces of a single fractured brick were assigned the same material.

Overall, using Karma XPU for this project was a double edged sword. On one hand, it allowed me to iterate my renders very quickly. On the other hand, I lost access to a lot of the tools that I'm used to using for compositing. Either way, it was a really fun challenge to try and work around these limitations, and I'm really glad that I got to dive into this new piece of software. I learned a lot about the USD workflow and the new Material X, and I'm really looking forward to seeing how this renderer develops over time.   

Lastly, I brought my renders into Nuke for the final composite. The original background plate is credited to Rahul Gautam.

Houdini - Karma - Nuke

Closing Thoughts

If you made it this far in my submission, thank you so much for taking the time to take a look at my stuff! I've been working really hard this past year and a half to grow and create as much as humanly possible, and I feel that these few projects have been the culmination of almost everything that I've learned so far. But this is only the beginning! I know that there's still a long way to go, and that the journey never really ends. 

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!

Lastly, I would like to thank all of the mentors and instructors that have passed all of their knowledge and expertise onto my cohort and I. I would especially like to shout out David Stripinis, Christian Olan-Geddes, Dan Bodenstein, and Nate Shaw for all of their instruction and guidance on the projects above.