Breakdown: Capturing Ocean In A Box With Houdini & Karma

Introduction

Hey, I'm Charlie. I have a background in advertising, design, and illustration and, in the last eight years, have moved into using Houdini as my software of choice for creating, particularly focussing on all aspects of FX simulation with a passion for water, fluids, oceans, and all things splashy.

In the past few years, I've worked for clients like Amazon, Disney, and Nike to bring their shows and campaigns to life and worked at studios such as Jellyfish Pictures, Time Based Arts, and Primary VFX, mainly as a freelancer.

The Ocean in a Box Project

I wanted to create something memorable and dynamic that people would have fun watching. Damien Hurst's formaldehyde installations from the early '90s informed the look of this project more than a little. The idea of having something wild and unpredictable, like a shark in the middle of a sterile gallery environment, always created an interesting juxtaposition in my mind.

Houdini

I knew I wanted the ocean to collide with something inside the glass box, so I used a simple sphere converted to an SDF and just dialed in the look of a (admittedly simple) rock using the volume noise SDF SOP.

I converted to polygons and ran the resulting geometry through connected pieces for-loop with a Measure SOP to remove any small unconnected pieces of geometry that the SDF noise generated and quad-remeshed, auto-UV'd, and poly-capped the resulting geometry to ensure it would be a water-tight SDF collider and be ready for texturing later in Solaris. I then took a grid, rotated and extruded to create the base, and merged these 2 items together. Adding a Bound SOP to this with some additional space in +Y for splashes created my simulation domain to be fed into the FLIP solver later on.

Next, I made an ocean spectrum with high swell to have the directionality of the waves facing directly at my rock collider and merged it with an Ocean Waves SOP to time a couple of hero waves at various points. This was fed into an Ocean Evaluate SOP to create the velocity and surface volumes to guide the FLIP simulation via the solvers' fourth input. 

For the final simulation, I wound up with around 10 million points in narrowband for the fluid simulation.

I meshed my fluid simulation using a custom VDB from particles workflow that allowed higher voxel counts in areas of high movement prior to converting to geometry.

Once I was happy with my fluid simulation, I moved on to whitewater and created a custom emit source from vorticity in the fluid. If I can, I try and avoid the whitewater source SOP as it’s unnecessarily heavy for a lot of use-cases.

For the whitewater solver, I always turn on state attributes to easily split my points out after the sim, and as a first port of call, I disable clumping, which is often a needlessly slow and RAM-consuming step. Clumping is capable of great results, but often, it really isn't needed. Instead, I often opt for a custom POP-VOP plugged into the whitewater solver to create the shapes that clumping would have otherwise. Whitewater is probably the thing that people should wedge the most to get familiar with the effects of erosion, lifetimes, and repellents, as small tweaks can make quite meaningful differences.

For the final simulation, I wound up with around 9 million points for the whitewater sim. It's really important you don't sell yourself short with the point counts on whitewater (9 million is on the low side, and obviously this is a small, contained domain) as whether you're going to render a volume or point representation of the foam you're going to want to try and get as many points as your RAM allows to give maximum fidelity for either rendering method.

Point replicating is definitely an option if your system can't hit tens of millions of points, but it should only be used carefully and if really necessary. As mentioned earlier, turning clumping off will help greatly with RAM requirements.

Post-sim, I split off the foam/bubbles/spray into different streams. I rendered the foam and underwater gloopy bubbles as VDBs and the spray as points. Often, the spray points are a basis for a new spray pop sim, mainly to be affected by a wind field, but I didn't deem that necessary this time, so I just rendered the raw points from the simulation.

I chose Karma XPU to render this project, which comes with so many upsides that it's difficult to ignore if you have a decent GPU. One downside is that Material X doesn't support the gradient component for specular highlights on volumes, which the VEX-based shaders in Mantra and KarmaCPU can accommodate. Since this was a personal project and I didn't have a farm at my disposal, it felt like using XPU was a bit of a no-brainer, and I'm happy with how my foam turned out, given the current limitations in place.

I chose to render my scene in Karma XPU, so once in Solaris, I hijacked the Material X water and interior volume shaders from the Karma ocean procedural LOP and modified the ocean surface shader to add water-churn (diffuse) to my water via the velocity and vorticity attributes in the mesh.

Thanks for all of the kind words and support everyone has given me on this project, my hope is someone thinks it's cool and makes something of their own that I'm excited to watch. Going through the feed and seeing the work of talented artists at all levels is what inspires me to jump into personal projects when time allows, so please make more great stuff!

Tech specs: 128GB RAM/AMD Ryzen 9 5980HX/GeForce RTX 4090

240 Frames (+50 in preroll)
Fluid Sim: 10 million pts/6 hours/112GB
Fluid Mesh: 5 hours 
Whitewater: 9 million pts/30 mins/110GB
Whitewater VDB: 1 hour 

You can find me on Instagram and LinkedIn. Project files are available for download on Gumroad.