Featured Artist: Javier Meroño, London
My name is Javier Meroño, FX TD and Houdini instructor currently based in London. I've been using Houdini since 2006 (version 8.0) both for production as well as an instructor.
It was around that time (2006) when my good friend and colleague, Pablo Giménez, made me realise that particles and simulations were not just a couple of panels on your regular 3D application. There was a whole world of proceduralism waiting for me to explore it, not to mention an actual career to pursue! Since then, Houdini has been my main weapon for FX-driven shots.
I'm sure you are finding my background story terribly exciting by now, so I'm going to stop right here and get into the thick of our topic which is what really matters after all.
FLUID SHOTS WITHOUT FLUID SIMS
During my career I have been involved in quite a few shots where fluids were called for. I enjoy these kind of shots because of the challenge they represent, both technically and hardware-wise. Now, for every two or three shots where an actual fluid simulation was needed, I recall at least another one where an alternative solution could have been applied.
Don't get me wrong: I enjoy working with fluid simulations. But I see shots for which you can avoid simulations and apply what I like to call “directed proceduralism” instead as opportunities. These are the situations where you can escape from the wonderful “black-box” (or maybe grey-box, as they're tweakable) nature of solvers, and force the geometry into the exact result your mind's eye is looking for.
Of course, sometimes that “mind” is actually a mutant hive-mind made of the blended ideas of the director, creative, supervisor, customer and yours truly, depending on the project. But I digress...
My point is, sometimes being able to avoid simulations can be an asset and there's no such thing as “too many weapons” in our CGI arsenal.
The beautiful reference
Last year I enjoyed the first season of a Netflix show called “Daredevil” and the initial credits for this show are outlined by beautiful work centered around fluid simulations. As far as I know, the company responsible for the opening sequence is called Elastic, and the Fluids Lead is a well-know FX Artist, Miguel A.Salek (https://vimeo.com/msalek), who used Realflow for a wonderful final product which deserves all kinds of kudos for a job well-done.
Now, since I saw this for the first time I realized several of those shots could have been done without resorting to fluid sims. Of course, not all of them, but a few, which again moves me into my “missed opportunities” mind-frame.
Later on, while hanging out with friends and enjoying a couple of beers, I solemnly vowed to prove that some of those shots could have been done without fluid simulations. Since my friends come from a totally different sector, I was swiftly informed that the only fluid simulations that mattered at that moment were coming from the next round I was paying for. Notwithstanding the initial response, when GridMarkets approached me for a spotlight article I decided it was a perfect chance to test my idea and attempt to create some of those fluid shots without simulations.
By the way, this project was rendered on Mantra, using the cloud-rendering service that GridMarkets provides, and which I've been using for all my personal projects since I first found out about it. Not only it's really simple to use and perfectly blends into Houdini's workflow, but it's also more than reasonably priced, so you don't have to get that second mortgage on your Millennium Falcon. GridMarkets provides a wonderful solution for those of us who don't own a render farm, and/or work with a laptop at home.
The Set-up
Naturally, in order to be able to duplicate the detail in a fluid sim, I have to mix and match several techniques. I have separated the process in three different steps. You can use all of the techniques together or independently, depending on the specific shot.
1. Layered Point clouds
This is undoubtedly the most important of the three techniques, since it will generate the main growth effect that simulates the evolving fluid. Of course, a growing point cloud is a well-known technique for any half-competent FXTD, which doesn't take away from its usefulness.
The “layered” part comes from the fact that we are creating several growing point clouds with different point “seeds”, so that the meshing process afterward gets much more detail. One strong point here is that the point cloud generation runs at about 3-10 fps on my humble laptop, which is a speed that no half-decent CPU-based fluid sim can usually aspire to.
Those different point cloud layers will be sent to the meshing tool (in Houdini the Particle Fluid Surface SOP), and some of them will be time shifted so that they overlap, creating one of the rippling effects we see in the final video.
One interesting improvement that was added here is to group the front edge of the growing point cloud. That gives us the option of somewhat “soft thickening” the edge of the layer.
The selection of that edge is really simple, since when we erased the point cloud we already had a smoothed color on the edges, thanks to our friend the Attribute Transfer SOP. We can use that smoothed color both for the selection as well as for applying a bigger point scale. Unfortunately, due to time constraints I only applied it here to the general shot, and not to the close shot, which makes that edge somewhat harsh on the latter, and definitely improvable.
Finally all those point clouds are merged together and meshed with the Particle Fluid Surface.
2. Deformers(Ripple solver)
Over our meshed geometry we can add some kind of controlled deformation that adds some variation to the more quiet areas. In the close shot I added a Ripple deformer. Other possible options would be Bulge or Magnets deformers, Soft Peaks/Transforms or even trying to get multiple ripple propagations at once with a Ripple Solver, although in this last case you should be wary about the loss of speed on heavy meshes. Besides, this is counter-intuitive with our current philosophy of not using sims for a more direct interaction.
On the close shot, if you look at the top part of the helmet you will spot a ripple deformer adding some secondary deformation. This may be a bit too extreme for a final piece, but ok for our tests.
As an alternative, some “point massaging” could also be applied before meshing, probably using VEX/VOPs, which would provide a greater speed when compared to other deforming options.
3. Drops or “Rivulets” system (Thanks to Matt Evans)
Remember, we are standing on the shoulders of giants here. Many of the techniques being mentioned here have been used before. We are just adapting and combining them to follow our devious plan. I read about the next technique long ago, but the Houdini implementation of it was shown to me by Matt Evans (https://vimeo.com/artkill).
Actually, the “Daredevil” reference showed no dripping action, so I didn't resort to it in this case, but it can get really handy for some shots.
It's an interesting technique which consists in forcing particles to follow the contours of the geometry, effectively behaving like drops that are released when they reach the bottom of the mesh. Here, we are guiding our particles as opposed to allowing them the be freely simulated, so we get the randomness of a particle simulation while preserving the drop behaviour.
Of course, not being an actual fluid sim but just a simple particle sim, the calculation is extremely fast, even for complex geometry.
The interesting part of it, technically speaking, is how we actually force the particles. We first check if a particle is inside or outside the volume of the geometry. If it's outside, it simply flies freely. Otherwise, we use a couple of cross-products to force the particle over the contour of the geometry (https://en.wikipedia.org/wiki/Cross_product).
As the educated reader already knows, a cross-product returns a vector which is perpendicular to the two input vectors. By using two concatenated cross-products we are moving the particle over the surface.
For the next step, we need the dot product (https://en.wikipedia.org/wiki/Dot_product). The Dot product is defined by the product of the magnitude of its two vectors, multiplied by the cosine of the angle between the two. This means by calculating the dot product of two vectors we can get a number related to the angle between them, and thus, use it for our own purposes. In this case we use the result to release the particles whenever we want to, which is usually when they reach the bottom of whatever geometry they are sliding over.
Here, I'm including a screen grab of Matt Evans original VOP setup, as mine isn't as comprehensive and lacks of the amount of explanation that his original file had. You can see the double cross-product calculation over the normalized vectors in the lower part (middle green box), and the dot product being used for the release of particles on the upper part (right red box).
Finally, we should decide what to do with those particles. Adding a trail and then meshing them is a strong option, but not the only one. Also, when to mesh them, either before the point cloud mesh or afterwards with a volume or VDB “boolean” (note the quotes) operation, is another important setup option which depends a lot on the shot. Sometimes you don't even need to add particles to the main mesh, as you want these drops to be clearly different from the object they are over. That makes this final part even simpler.
Final thoughts
Hopefully my thoughts open up some new options for those pesky shots for which your sims aren't behaving the way they should and you need an “art-directable” and fast alternative.
As it tends to happen with every project, the final 5% will always be the most time-consuming, but at least we will play with the backup of a decent enough geometry that is “almost there.”
Javier Meroño 2016
By: Patricia Cornet
GridMarkets marketing