For those who don’t know the tool: tyFlow is a particle and simulation plugin for 3ds Max. It is commonly used for particle effects and procedural simulation within pipelines. The tool expands 3ds Max application simulation features with node-based operators and GPU-accelerated modules.

A CUDA fluid solver arrives

The 2.000 release of tyFlow introduces a new GPU fluid simulation solver named ZENITH. According to the official release notes, the solver runs on CUDA and integrates directly with the tyFlow simulation environment.

The update also introduces twenty new operators for the Inferno module. Inferno is tyFlow’s internal system for simulation tasks, including volumetric and fluid workflows. The release notes confirm that the operators are designed to support the new GPU fluid pipeline introduced with ZENITH.

CUDA modules distributed with tyFlow have also been updated. The package now includes machine learning models intended for fluid up-rez and compression. These models ship inside the CUDA module package together with a defined installation location described in the included documentation. The release raises the minimum supported CUDA version to 12.8. Users are instructed to ensure that GPU drivers are updated accordingly.

Updated CUDA modules

The updated CUDA modules are a central part of the release. The vendor states that the package now bundles machine learning models used for fluid up-rez and compression. Fluid upres workflows typically reconstruct higher resolution detail from a lower resolution simualtion. The release notes do not specify the training method, dataset, or inference process used by these models. No benchmarks or performance figures are provided.

The CUDA modules also now require installation in a specific location. Users are directed to the README documentation included with the CUDA module package for installation details. The vendor also updated the CUDA cub and thrust libraries used internally by tyFlow. According to the release notes, the update addresses rare CUDA crashes during Multifracture operations. (Multifracture is tyFlow’s system for procedural mesh fracturing used in destruction simulations.)

Twenty Inferno operators

The release introduces twenty new Inferno operators designed to work with the new GPU simulation capabilities. Inferno operators in tyFlow provide node based controls that modify simulation behaviour or generate simulation data. The addition of twenty operators suggests a significant expansion of the Inferno system.

New operators for general workflows

Outside the Inferno system, the release adds several new operators and modifiers for tyFlow workflows. A new Global operator has been added. The official documentation referenced in the release notes is required to understand its full functionality.

The update also introduces a MAXScript operator. MAXScript is the scripting language used inside 3ds Max. The operator presumably enables scripting access within tyFlow simulations, although the exact capabilities are not described in the release notes.

A new tyMeshBlend modifier has also been introduced. The modifier blends normals where meshes intersect. This behaviour is typically used to reduce shading artifacts where two meshes overlap or intersect.

Another addition is a new SDF shape mode for the PhysX Shape and PhysX Collision operators. SDF stands for signed distance field. According to the release notes, the new mode allows more accurate concave collisions.

Signed distance fields are commonly used to represent complex shapes in simulation because they encode the distance to the nearest surface point in volumetric form.

tyCache improvements

The release expands tyFlow’s caching capabilities. The tyCache modifier can now cache spline data. Previously, the system primarily cached particle and mesh data. The Export Particles operator now supports subframe export of tyCache data. Subframe data enables simulation playback at time steps smaller than a single frame. This is typically required for accurate motion blur in rendering workflows. The tyCache object also now displays PhysX bind connectivity.

Mesh and material improvements

Several modelling and mesh related updates are included in the release. The multifracture, tyBoolean and tyWeld modifiers now include UVW seam weld options. A new Merge mat IDs mode has been added to the tyMaterial modifier. The same option is also available for the tyMesher object. According to the release notes, the feature merges and concatenates material IDs across instanced objects and generates a compatible multi material with the new ID layout. This behaviour can simplify material management in procedural setups where multiple objects share or generate different ID sets.

UI and usability changes

The update includes multiple interface adjustments aimed at improving usability inside the tyFlow editor. Comboboxes, checkboxes and radio buttons now display non-default values in blue. Previously, this behaviour was limited to numeric spinner controls.

Large dropdown comboboxes now include a text entry field at the top of the list that allows users to search items using fuzzy matching. The release also introduces a Houdini-style value stepper dialog. Middle Mouse Clicking any spinner control opens a dialog that allows incremental changes across multiple orders of magnitude.

Export and procedural variation

The Export Particles operator now supports exporting ranges for tySwitcher indices and reseed values. According to the release notes, this allows permutations to be exported from the same operator during a single export operation. Exported object names and layers now also support symbol replacement variables such as $tySwitcherIndex and $tySeedIndex. These variables allow procedural naming during export operations.

OpenVDB update

The OpenVDB SDK used by tyFlow has been updated to version 13. OpenVDB is an open source library widely used in volumetric workflows. It provides sparse volumetric data structures for storing grids such as smoke, fire or fluid simulation volumes.

Practical implications

The most significant change in this release appears to be the introduction of the ZENITH CUDA fluid solver and the expansion of the Inferno operator set. However, the official release notes do not provide technical descriptions, performance data or architecture details for the solver. GPU fluid simulation inside particle frameworks can reduce iteration times when compared to CPU grid solvers. Whether this holds true for ZENITH cannot be determined yet – so it is time to have a good long playing session with Tyflow!

Users interested in adopting the new system will likely need to examine the updated CUDA modules and example scenes to evaluate real world behaviour. As always, new tools and innovations should be thoroughly tested before use in production.

// https://pro.tyflow.com/

The post tyFlow 2 adds CUDA fluid solver and 20 Infernos first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

A tasting of the dynamics and geometrys side (of) effects

This release is not about the number of features, but about finishing what was started, achieving true production readiness, robustness, performance, and ease of use. It’s a version focused on quality of life. Feature sets like MPM simulations and Karma have matured like a good wine. The machine learning tools respect the artist’s skill set and have left their state of play are actual usefull in production.

Even though SideFX remains modest in its official statements, Houdini 21 is a massive release. For the feature-hungry among us, the highlights include a fully matured APEX; a refined and clever animation and rigging framework; a simulating Copernicus (think Substance on Dope), and in the VFX realm, the production-ready MPM Solver. On top of that, we’re seeing machine learning tools popping up in all the right places (AI for people who don’t expect a Pixar film from a single click), faster and expanded rendering with Karma, and a healthy dose of quality-of-life improvements.

Since our editorial cat can only count to 300, we can’t tell you the exact number of new or improved features, but we’re impressed nonetheless. And soon, you will be too. To avoid overwhelming both writer and reader, we’re breaking this article into a mini-series. We’ll start with VFX & Geometry, followed by Solaris & Karma, Copernicus & Terrain, and the massive Animation & Rigging tools.

MPM

One of the most exciting additions in H20.5 was without question the MPM Solver. The MaterialPointMethod truly allows you to simulate a wide range of different materials. From water, snow, and sand to honey, metal, and concrete, all within a single Solver setup. The geometry is simply substituted by points or particles, which are then simulated. The different materials interact physically accurate and constraint-free, purely based on their assigned parameters.

The initial release was already impressive, but it left users standing somewhat in the simulated rain when asking: “How do I get a proper mesh with UVs?” That exact issue has now been beautifully solved in H21. Any MPM simulation, whether rigid body or fluid, can now be meshed (as polygons or SDF volumes), including UVs, color, and other attributes, using no more than two nodes.

A nice and usefull addition to this workflow is the MPM Debris node, which generates new points along fracture lines as sources for smoke, dirt, or secondary debris effects. So let’s take a look at meshing hard and fluid or granular surfaces across a few setups and scenarios and wrap things up with a creamed cookies drink while watching the official and very excellent MPM demo.

Surfacing MPM Simulations

Testing time! For this test setup, we’ll have a clay ball smash into a vase model, paying close attention to UV transfer and the generation of smaller fragments through the Debris Source. The easiest way to start an MPM simulation is by typing “MPM Configure” into the node search. This gives you a complete set of starter nodes right away. (Under MPM Configure, you’ll also find plenty of additional example setups for study or creative repurposing.) By the way, the MPM container on the far right controls the overall resolution of the entire simulation.

We replace the default sphere with our own model and can now assign materials directly inside the mpmSource node and tweak them to our liking. It’s genuinely fun. Feels a bit like a mini-game. Since a concrete material would be more realistic but also quite boring as a vase material, we went with Chunky Snow instead. The environment comes in via an Object Merge directly into the mpmCollider Sop, ready to go. Our clay ball, the antagonist of this little simulation, isn’t a collider per definition but another mpmSource ready to be smashed, merged with the vase and given its own material behavior, Chunk Soil.

To make sure the particles can actually see and “love” each other, we need to enable Particle-Level Collision in the solver. The new Auto Sleep feature helps keep the vase passive until the collision happens, preventing it from collapsing at frame one and saving quite a bit of compute time.

Since the clay ball will be meshed as a fluid and granular surface and the vase as a rigid object, we first separate the MPM particles using a Blast node, filtering them by their respective source names.

For surfacing the vase, we use the mpmPostFracture node, which takes the rest-geometry and the MPM particles as input. This node essentially breaks the geometry apart “end to start,” so it needs to be fed the final frame of the simulation. After that, we choose either Voronoi or Boolean Cut as the fracture method. The latter can generate interior details, subtle irregularities on the inner faces of the fracture, that weren’t visible before, and it’s also faster to compute. We can further control the number of pieces as well as define the minimum fragment size at which new pieces should be generated.

The final node in the chain is mpmDeformPieces, which transfers the newly generated fracture geometry onto the MPM particles and just like that, the vase shards, physically convinced they’re made of snow, go flying through the scene, complete with perfectly intact UVs. For more of a muddy mess, we could have generated a liquid or granular surface instead, but we’ll save that for the clay ball. The result from the Debris Source, which lets you precisely define when and where particles based on fracture are emitted, is then passed into a POP network, including collisions from the vase and background).

Time to get serious:

Continuos Emissions & Surface Tension

With this new option, you can quickly fill containers, simulate expanding materials, or layer different materials on top of each other. The option is located in the mpmource node and spreads new particles apart using positive pressure.

Let’s take our vase and let a thick, viscous something ooze out of it. A good chance to show how simple MPM can be: if we want things to float inside the fluid, they just need a lower density. A few cubes are generated and assigned a jelly material. Two geometries, two MPM Sources, merged and fed into the solver. That’s all it takes. Just as easily, you can mix different fluids within the same setup. And for a bit more drama, we can dive into the solver and add a POP Wind node with some turbulence.

Surface tension allows for realistic effects such as droplets, tendrils, and flowing water. H21 introduces two new ways to control surface tension for both liquid and viscous materials inside the MPM Solver. The Point Based method offers higher accuracy and stability, making it ideal for small and detailed simulations. The Grid Based method, on the other hand, is optimized for performance and handles millions of particles more efficiently, which makes it better suited for large-scale scenes. External forces and friction can be increased if objects keep moving when they shouldn’t. Otherwise, you might end up with a scene straight out of Terminator 2.

To achieve high levels of detail without an unnecessarily large number of simulation points, the new, more precise collision detection allows you to use the fracture edges of a simulation as the source for a targeted secondary simulation. The attribute Jp (Plastic Compression/Stretching) is key here. It can be used to isolate the fractured areas and feed them into a Surfacing node set to VDB mode. This resulting volume can then serve as the source for the second simulation. And don’t forget to use the main simulation result as a collider.

And finally to top it off, the official demo. A detailed breakdown of that beautiful cookie shot.

Machine Learning in Dynamics

You won’t find any generative AI native in Houdini, but rather a growing collection of smart, locally running models, often trained by yourself, designed to simplify or speed up time-consuming tasks.

Surfacing Flip, Vellum & Particle Simulations

Alongside Neural Point Surfacing for MPM, the new Neural Point Surface and proven Particle Fluid Surface nodes now bring neural meshing to FLIP, Vellum, and POP simulations as well. Until now a bunch of points are trying to reconstruct the surface of a material. With neural meshing, you can now achieve much sharper, more detailed surfaces across a both high and low frequencies. The result: surfaces that are no longer uniformly fuzzy, but crisp, structured, and temporally stable. As before, you can train your own models, but even the included presets already produce finer details. And thankfully, the whole thing is GPU-accelerated.

Volume Upres

The core problem behind volume up-resing: for efficiency, artists often create and approve low-resolution simulations. But once the voxeldensity is increased, the overall shape of the sim tends to change. With the new tools, a low-res simulation can now be upscaled while preserving its exact shape. This not only keeps previously approved versions intact, but also allows for far more iterations. A model that’s been trained on a specific motion or behavior can now upscale multiple variations of it.

The Billowy Smoke recipe (or shelf tool) comes with a pretrained up-res model already integrated. Let’s start by looking at a comparison between the low-res input simulation and the 3× up-res result.

Details are nicely added, while the overall shape is preserved impressively well. Caching took a bit of time, but it’s still far faster than running a full high-res simulation. The real idea, however, is that we can now reuse this up-res model for all our future Billowy Smoke setups and honestly, we probably should. So, let’s quickly modify the setup and see if we can break the upscaler.

This time, the solver runs at a voxel size of 0.05, using the 2× upscaler. The 3× model didn’t really add more detail, just extra waiting time. For a bit more fun, a Gas Wind with random direction and a collision shape were added. That collision shape, as it turns out, gives the upscaler a bit of trouble as seen below.

But when comparing the up-res result to a true high-res sim, it’s clear that the system is really good at preserving the base form. Doubling the voxel size in the high-res sim, on the other hand, changes the overall shape and eats up a ton of time but stays artifact-free. Or, if you really want perfection, you could just train a model specifically for this type of collision.

If you want to train your own model, this Equinox Hive talk walks you through every detail:

Zibra AI VDB compression

With this plugin you can save up to 99 percent of storage space when caching VDB simulations, which makes it perfectly suited for use in real-time engines such as Unreal Engine 5. The Zibra toolset, distributed via SideFX Labs, provides three dedicated nodes.

The first, zibravdb_compress, writes and exports .zibravdb files for use in Unreal and similar environments. The second, zibravdb_decompress, brings those files back into Houdini. And finally, zibravdb_filecache acts as a modified File Cache node that automatically handles compression, loading, and decompression for further use inside Houdini. Before diving in, you’ll need to download the model and obtain a license, potentially a free personal one if your revenue is below 100 K USD. The license management can be accessed directly from any of the three nodes.

For a quick benchmark, I used the Fireball Recipe and cached one regular VDB sequence alongside two Zibra versions with different quality settings. The original VDB sequence weighed 294 MB. The Zibra compression at a quality setting of 0.2 came in at only 5 MB, roughly 98 percent smaller. At a quality setting of 0.9, the result visually matched the original VDB almost perfectly while staying at just 36 MB, around 88 percent less.
That insane low file size at 0.2 naturally comes at the cost of lost detail, as visible in the comparison graph below. Still, the results are impressive and they open up the possibility for bringing volumetric simulations into real-time pipelines far more efficiently than before.

Pyro Shelve Tool Presets

Another way to get artists up to speed faster are production-ready presets, not just educational examples, but tools meant to be customized for your very real projects. Each of them comes with a ready-to-use Solaris network, fully set up for rendering straight out of the box. Even better, the Help section now includes a short guide and exploanation of important Nodes for every preset.

SideFX strikes a noticeably new tone here, aiming to flatten the learning curve rather than overwhelming newcomers with endless options (which, to be fair, they still do from time to time). These guides can be found under Documentation → What’s New → Pyro. In this section, we’ll take a closer look at three fundamentally different presets, each showcasing its own approach and creative use case.

Stylized Flame

With the refined Copernicus toolset, entirely new worlds open up: stylized fire based on a classic Pyro simulation, right inside Houdini. And if needed, even live-rendered in Solaris.

To put the claim of “easy adaptability” to the test, we took the Pyro Fireball preset and gave it a Toon-style makeover. Adding the VDB field “Flame” inside the solver’s output was all it took to make it work. The output from the Cop node, by the way, can be merged directly into the scene for further Houdini style editing.

Ground Explosion B

This shelf tool sets up a sparse pyro simulation featuring a large-scale explosion, smoke trails, and a shockwave. For more control and efficiency, it’s actually made up of two separate simulations, layered on top of each other and interacting through their velocity fields.

Candle Flame

A candle flame might not be the most exciting thing visually, but it’s one of those Pyro results you end up needing again and again. What makes this preset interesting, though, is the procedurally modeled candle that comes with it. Exploring that setup is almost more fun than the Pyro sim itself.

Thruster FX

In true H21 fashion and in the spirit of overall efficiency boosts, the new Thruster FX tool makes its debut: a setup designed to create engine and propulsion emissions with ease. It’s not just a new node, but rather a complete Recipe, a preconfigured network of nodes that some might, in hushed tones, simply call “presets.”

With a cheerful click on Thruster Exhaust in the Pyro Shelf Tools (or via Configure Thruster in the Tab menu), you’ll get a fully adaptable node tree, including a ready-to-render Solaris network. The effect itself isn’t a simulation but a cleverly layered, art-directable procedural system built around VOP Nodes. Multiple pyrothrusterexhaust nodes are stacked in layers, each responsible for different components like sparks, fire, and plasma. All working together to form a surprisingly easy to use thruster system.

So, what does it actually look like? And can it really be used straight out of the box, as promised? The short answer: pretty much, yes. The rendering comes surprisingly close to the viewport preview. To get it running, only a few connections inside the included Solaris network needed to be adjusted. For our small test scene, we did a bit of kitbashing inside Solaris, then added some glow and polish in Fusion.

Let’s take a closer look at the node, both from the outside and under the hood. The node expects a primitive as input, and a simple circle usually does the trick. It outputs both particles and a volume containing density and temperature fields. In the General tab, you can control speed, length, and the overall shape via a spline ramp. The Exhaust section handles the color ramp and lets you tweak the underlying noise pattern, which has a strong impact on the overall form. Under the hood, the node generates a VDB from Polygon, then modifies the result with a Volume VOP and a Volume Adjust Fog node.

As part of the ongoing effort to simplify things and lower the learning curve, SideFX has also released a good and detailed tutorial mini series: sidefx.com/tutorials/how-to-create-thruster-fx

Car Destruction FX

So that we can also crash the rigs built with the Car Rig SOP introduced in H20.5, Houdini 21 brings us the new Car Destruction Tools, led by the mighty RBD Car Fracture SOP, supported by the RBD Car Transform SOP. The first one takes care of fracturing and constraint creation, automatically handling the typical materials you’d expect in a vehicle: glass, metal, wood, and rubber. The RBD Car Transform SOP, similar to Transform Pieces, ensures that all pre-fractured parts are efficiently transformed based on the simulation points. You’re not limited to cars, by the way. Anything that follows the same basic logic can be blown apart. From motorcycles to helicopters, it all breaks just fine.

Destruction-hungry artists will find a detailed yet easy-to-follow example scene in the SideFX Content Library, the same visuals you might recognize from the keynote: sidefx.com/carbd-dual-car-collision/. A fitting go-through video can be found here:

Geometry, Viewport and other tasty QoL

Coming from its deep VFX roots, Houdini has taken quite a journey to establish its own distinct style of procedural modeling. With H21, that journey continues, extending existing nodes and adding a few genuinely useful new ones along the way. This time, even the viewport got some well-deserved love, now powered by Vulkan and capable of loading Gaussian Splats directly.

Sculpting in Time

The Sculpt SOP, introduced in H20.5 and (surprisingly) quite useful, now gets a genuinely groundbreaking new feature called Shot Sculpting allowing time-based, keyframe-free sculpting. Originally intended as a correction tool for character animation, the node turns out to be just as handy for VFX and motion design work.

Temporal control is handled through the Shot Sculpt panel, which at first glance looks a lot like an NLE timeline and, in principle, works much the same way. Sculpting can be organized into layers that can be offset in time, faded in and out (complete with easing), muted, or adjusted in opacity. Alternatively, you can use mask_track to paint time-based attributes, which can then be passed downstream and used in other nodes, for an obvious example, as masks.

Otherwise, the same rules apply as for the regular Sculpt SOP, whose updates we’ll take a look at next. In line with the new Shot Sculpting feature, the mask system has been reworked. Masks can still be painted manually, but can now also be loaded from an upstream float attribute, saved permanently, and blurred or sharpened as needed.

There are also new brushes. My personal highlight, the Elastic Grab brush:

Of course, the complexity and depth of ZBrush remain unmatched, but for many tasks, artists can now comfortably stay right inside Houdini.

Geometry Masks

There are also updates when it comes to masking. Several well-known nodes now include a Mask parameter, allowing the effect to be restricted to a painted or procedurally generated mask. Among them: Peak SOP, Soft Peak SOP, Inflate SOP, Flatten SOP, and Point Jitter SOP.

UV Flatten from Points

The latest addition to Houdini’s already powerful UV toolset could just as well be called “UV from Voronoi” since that’s exactly what it’s based on. The node distributes random or precisely placed points across the surface and uses them to calculate clean, non-overlapping UVs. It’s primarily designed for complex, high-resolution meshes, where traditional unwrapping tends to get messy fast.

Vulkan Viewport

Now enabled by default, the new Vulkan 3D viewport offers noticeably improved lighting, Ambient Occlusion, shading and ray tracing with built-in denoising, and a more accurate texture display though performance can take a hit if you push it too far. New worklights including a fully adjustable Dome Light, Physical Sky, and Three-Point Light setup now serve as the default viewport lighting.

Looking toward the future, the viewport can now display Gaussian Splats directly. Since splats are essentially just point clouds, and Houdini is fundamentally point-based, this opens up a rather promising combination. The .ply file can simply be loaded via a File SOP and passed into a Bake Splat SOP for further processing. From there, you can treat and manipulate the splats just like any other geometry using the usual SOP tools. More on rendering those Splats in the upcoming section on Solaris & Karma.

Curve Tools

The new Extract Contours SOP can generate object outlines from a camera’s perspective either directly as edges or as an edge group. Quite handy for toon-style effects.

The well-known Curve SOP now allows you to interactively split points into branches (with unique vertex numbers) or fuse them back together.

Unsubdivide

If things ever get a bit too much, this node can reconstruct a low-res input geometry based on Catmull-Clark.

Conclusion after some bottles of VFX

Even though the stated (and achieved) goal of H21 was mainly polishing existing systems and adding plenty of quality-of-life improvements, it still manages to sneak in a massive load of new features along the way. And we’ve only scratched the surface here. Deep dives on Copernicus, Solaris, Karma, Rigging, and Animation are already in the works.

What’s also refreshing is the ongoing effort to flatten the learning curve through better documentation, tons of in-house tutorials, and solid example files in the Content Library. Many things have become easier or let’s say, more accessible, without losing depth, at least for those who want to go there. As always, most nodes can still be cracked open and modified at their core. Nice one, SideFX.

The post Houdini 21: Like good wine (Part1, VFX & Geo) first appeared on DIGITAL PRODUCTION and was written by Manuel Kotulla.

Creation Effects kindly hands over a cure for digital hayfever: 3D Dust & Pollen Free, a free After Effects preset. Designed to generate realistic simulations of airborne annoyances — including dust, pollen, spores, dander and similar floaty bits — this preset saves artists from turning their studio desks into sneeze zones. For those already suffering IRL, this tool safely limits the pollen load to your pixels only.

Technical Details: What You Actually Get

The preset is fully compatible with Adobe After Effects and relies on native AE tools for all its magic. That means no third-party plugins are required, making it a simple and clean drop-in solution for motion graphics artists and VFX compositors. It uses expressions to drive a particle simulation and is described as working best when applied to 3D null objects (an invisible helper object used in After Effects to control other layers).

The generated particles simulate motion in three-dimensional space, giving you floating flecks that behave like airborne allergens – only this time, you don’t need tissues. According to Toolfarm, the particles are controllable in terms of amount, speed, and randomness, ensuring that users can easily adjust the intensity of the effect from gentle spring breeze to full-blown attic dust storm.

Because the preset is expression-driven and uses only AE’s native features, it promises stability across After Effects versions, assuming your own version supports expressions properly — a relief for anyone who’s ever crashed AE five minutes before deadline. (Not that we know that feeling. At all.)

Free, But With a Particle Storm Warning

As you might have guessed from the name, the preset is absolutely free of charge. You can grab it directly via Creation Effects news post. Pricing can’t get any better than “zero dollars,” but, as always with freebies, production artists should vet the preset thoroughly in their environment before using it in client projects or larger pipeline integrations. Always better to sneeze at test renders than client feedback rounds. Because 3D Dust & Pollen Free leans entirely on After Effects’ built-in toolkit, it’s relatively lightweight and shouldn’t introduce system instability — at least not beyond AE’s usual Monday morning mood swings.

The post Achoo-Free Effects: “3D Dust & Pollen Free” for After Effects first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

There is always a greater or lesser deposition of organic and inorganic substances in our oceans. This includes, for example, the calcium carbonate shells of diatoms, dead plankton and everything that marine life emits. This continuous shower of material is called marine snow, or ocean dandruff.

The idea of writing a VEX programme for Houdini that simulates the movement of marine snow in the ocean came to me during an exciting presentation at FMX 2024 in Stuttgart. Weta had presented just such a model there, but without going into details or even revealing anything about the code. In the end, it was only clear that the script runs in Houdini.

I have programming experience, but hardly in the simulation area and mainly in Python. So far I had mainly written batch tools, i.e. programmes that execute repetitive processes, e.g. creating shaders, importing assets, etc. The Marine Snow project seemed manageable to me and a good start to do something in the simulation area. So, let’s dive in!

Every beginning is difficult

Ultimately, the big question is always how and where do you start? Apart from the slowly fading memory of the Weta lecture, I had almost no clues as to how the movement of particles could be represented in a physically plausible way. The fact that the simulation was to run in Houdini’s POP solver was almost all I knew at that point. At least the POP system provides a number of ready-made nodes that can be used to transfer forces to particles. Probably the most common example of such a force is gravity, which can be represented with a POP Force DOP. This was once an idea, but it quickly became apparent that POP Force is not flexible enough. Some things can only be solved properly using a script.

So I started by looking for references. What video material was available from which the basic features of the movement or patterns could possibly be derived? Research also involves reading scientific papers. Even if you don’t understand the maths or only have a rudimentary understanding of it, you can often find valuable approaches in the accompanying texts and descriptions. There was film footage of Marine Snow, but no papers that would have helped me. (Here is a link to a video from NOAA, showing a red squid on the ocean, in a “storm” of marine snow. Have a look at the other results from this Expedition, it is amazing and as usual with Deep Sea Science, quite alien. ).

The number of hits for videos was manageable, but sufficient to formulate some assumptions.

1. There are two determining forces: gravity and buoyancy.
2. The wave motion at the surface amplifies the cyclical up and down motion.
3. The particles have different sizes and densities, which influences the buoyancy.
4. New particles are constantly formed and enter the system. Other particles are deposited on the seabed and are thus removed from the system.
5. The particles are in a medium with a certain viscosity (water).
6. Turbulent currents cause swirls and sideways movements.

So how do we get started? What factors should you take into account and what can you try to formulate later? I found it easiest to simulate the forces mentioned in point 1, i.e. the interplay between gravity and buoyancy. Many people will probably remember the formula below from their school days, as it is one of the fundamental equations of Newtonian physics:

F = m * a

The force acting on a particle is the product of its mass and acceleration. For the force of attraction (“gravitation”), acceleration is a constant that is characteristic of every body. Here, on Earth, the constant is not called a, but g and has a value of around 9.81 m/s². In physics, the mass is given in [kg]. The force is therefore a compound unit and is called Newton [N].

(1) gravity = particle mass in kg * 9.81 m/s2

The equation may seem trivial, but it is of great importance for a script because it already represents a calculation rule. For the buoyancy, however, I had to use the search engine I trust and it spit out Archimedes’ law of buoyancy.

(2) buoyancy = density of water * particle volume * 9.81 m/s2

The factor 9.81 again corresponds to g from the gravitational force. The particle volume can be approximated as a sphere. For a sphere, a collection of formulae says that the

(3) particle volume = 4/3 * PI * particle radius3

The particle mass can now also be derived:

(4) particle mass = density of the particle * particle volume

Before we can start calculating the forces, we first need particles. This is done using a small standard mesh that generates points in a cuboid. These particles in turn are sent to a POP solver, inside which a POP Wrangle performs the necessary calculations. In addition to the POP Wrangle, the interior of the solver also contains a POP Kill Node. A complete description of the network can be found here.(→ see POP Up)

It is also important to define start values. Their size and dimension ultimately determine the behaviour of the particles just as much as the calculations themselves.

// Initial variables
float g = 9.81; // Gravitational acceleration in m/s^2
float radius_p = 0.005; // Particle radius in m
float rho_p = 1050.0; // Particle density in kg/m^3
float rho_f = 1030.0; // Fluid density in kg/m^3, e.g. water

To begin with, the script should determine the particle volume and mass, as these values are then used in the formulae. Equations (3) and (4) therefore result in

// Intitial calculations
float volume_p = (4.0 / 3.0) * M_PI * pow(radius_p, 3);
float mass_p = rho_p * volume_p;

The constant M_PI is the circle number, which is predefined in VEX with sufficient accuracy.

Both forces, i.e. gravity (gravity_force) and buoyancy (buoyancy_force), are vectors, but they only act in the Y direction. Gravity always acts downwards towards the centre of mass, while buoyancy counteracts this force. A standard vector in VEX consists of three components, which here represent the XYZ coordinates.

// Calculate force components
vector gravity_force = mass_p * set(0, -g, 0);
vector bouyancy_force = set(0, (rho_f * volume_p - mass_p) * g, 0);

This corresponds to the formulae defined at the beginning with one small exception. With buoyancy_force, the mass is again subtracted in the brackets to obtain the net buoyancy force. This is particularly relevant if a particle’s density is greater than the density of the liquid. This simulates sinking, as the weight force is greater than the buoyancy.

The post Marine-Snow-Simulation in Houdini first appeared on DIGITAL PRODUCTION and was written by Thomas Schlick.

A wild, prehistoric landscape – herds of dinosaurs roam the frosty plains, or sail through the snowstorm over the mountain ranges. In the undergrowth stirs a completely different, small group – primitive humans, but in this world they are among the hunted. They lie in wait for a creature that haunts their tribe, hoping to defeat it once and for all. But nature has other plans: they are surprised by a gigantic T-Rex and are forced to fight. However, they are powerless against the monster; their primitive weapons have no effect. In the end, only one of them remains, who bravely confronts the giant with his daggers..
This is how the short pilot film “We Hunt Giants” ends in terms of content; but the production began much more harmlessly.

The beginnings

Although Titus took the lead on the script, it was important to him to involve me from the first version of the book. On the one hand, I was able to think about the quantity and realisation of the VFX shots at an early stage. At the same time, I was able to give him critical feedback on the contrast with my own perspective on film and offer further creative suggestions from my side. One of these suggestions was, for example, to introduce the film with a vignette of different dinosaurs for a better worldbuilding – even if this would mean creating several additional dinosaurs in CG, which would be counterproductive.

While Titus was making revisions from his side, I began to create the first storyboard sketches and to build and cut a 3D pre-visualisation based on them. This gave me creative freedom to design the resolution & composition, as well as giving Titus the option to plan the shoot in a more focussed way. As the 3D scenes & cameras were scaled to real-life specifications, this allowed us to plan the technical side of the work on set in advance and identify any potential obstacles that could cause problems for the VFX work. This was particularly helpful when talking to cameraman Marcus Möller, as he not only got a better idea for the shoot on set, but was also able to contribute his own expertise. With a finalised 3D previs, shooting schedule and a well-rehearsed core team, nothing should now stand in the way of production.

The shoot

A few days before the shoot in February 2022, cameraman Marcus unexpectedly showed severe Covid symptoms and tested positive. However, giving up was not on the cards, as the equipment and transport had already been booked, and fortunately Andrés Rignell was found at the last minute to stand in for him. He had also already gained experience with VFX as a professional on various shoots and was very familiar with the camera system (RED Gemini). So we found ourselves for a weekend in Tyresta National Park south of Stockholm, and perfect for the first morning we were presented with an untouched winter wonderland, as it had snowed freshly overnight. So deep that even some of the rental cars got stuck in the snow on the last few metres to the film location.
To gain time, Andrés & I went off separately and started shooting various VFX plates while the rest of the crew freed the cars and prepared the actors. This allowed us to find a rhythm on the fly to gather references & camera data alongside the main takes. This was also important as we had to work with less daylight due to the winter season in the north, so some scenes were shot in a rush.

As soon as director Titus & I were happy with the takes of one shot, the actors were prepared for the next shot or recorded sound. Meanwhile, we were shooting quick cleanplates, noting camera specs, taking shots of lens grids, chrome & greyballs and a toy dinosaur for reference. This initially attracted some strange looks, but after a few shots there were always a few interested people around the camera monitor who wanted to catch a first “preview” of the prehistoric star. In every free minute or general break in filming, I also had to take separate photos of all possible references – actors, props, the surroundings & set design (a mini attrape for the dino trap) as well as additional Chromeball photos at different times of day so that an appropriate selection would be available depending on the shot.

Another result of the tight schedule was that almost all the shots were shot on location without any additional equipment – a blue screen was only used for a few specific shots where the VFX work would otherwise have been enormously complicated. After two intensive days of filming in the snow, I flew back to London to start preparing the VFX, while the material went into editing for the next few weeks.

Plate Prep

Finally, all the footage from the shoot was sent to London in the post as RED raw files, along with the first rough cut. Nuke Indie allowed the EDL of the cut to be imported directly and the individual shots to be exported in separate Nuke scripts. For further processing, the plates were reduced from 5K to 2.5k and saved locally as OpenEXR sequences. As the editing was still in progress in Sweden, the sequences were exported with extra leeway to be on the safe side and all tracked in 3D in Nuke Indie for the matchmoving. Thanks to the quality of the shots and the rich texture of the environment, an automatic 3D track usually produced a high-quality result, and it was rarely necessary to intervene with manual tracks or further manual work.

Based on the 3D track, 3D meshes of the environment could also be generated in Nuke at the same time using point clouds. Fortunately, despite initial fears, only a few shots had to be retouched to remove isolated references to the park such as fences or signs. However, the small amount of bluescreens would mean that every interaction with VFX would have to be rotoscoped by hand – some of the shots would end up spending several days or weeks exclusively in rotoscoping. Luckily, a friend and former colleague, Dominik Platen, stepped in towards the end of post-production and took care of the rotoscoping for some shots.

Dinosaur assets

Before filming began, thorough internet research was carried out for each dinosaur. Drawings & photos of skeletons, artistic reconstructions & screenshots from films, as well as material from related species were collected to provide further references. For the main dinosaur in particular, we initially considered a range of large theropods, but Titus was keen to use a T-Rex as a homage to Jurassic Park. In the end, we allowed ourselves a little variation – the bony dorsal crest was inspired by another theropod, the Acrocanthosaurus.
All 3D models were first roughly pre-built in 3ds Max, and then detailed and textured in Mudbox. A method that had proved successful in previous work was again used for the texturing:
For each dinosaur, a small library of base textures, masks and further grunge maps were painted onto the surface, which were then combined together with normal & displacement maps in Nuke via compositing to create a finished texture.

This process, although hardware-hungry, allowed free experimentation with various options & details, all simultaneously on multiple UDIMs in a non-destructive environment. In addition to the main texture, maps for shader attributes could also be “combed” in this way.
This was particularly important for the T-Rex: the model should give an idea that the dinosaur led a rough existence, in the form of scars and wounds from past confrontations. Other ailments such as frostbite & inflammation should indicate that it is actually not welcome as an invasive species in the cold.

With the texture compositing in Nuke, a suitable balance could be found quite quickly over a few iterations. At least one dinosaur was spared all the work, as the CG asset from “Tucki”, a past project, could be directly reused for a small guest appearance. You can read all about Tucki in DP 21:02, or download it for free here is.gd/tucki_pdf.

Rigging & Animation

For the rigging we went back to 3ds Max. As a tried and tested module, each dinosaur was given a special rig in the Character Animation Toolkit, CAT for short, which could be saved as presets for the subsequent animation process.
To save time during rigging and animation, shortcuts were built into the rig for each asset. For example, the flight membranes of the pterosaurs were animated using a cloth simulation, and the tails of all dinosaurs were procedurally controlled with spring constraints to create a flowing organic movement without further manual intervention.

In turn, the T-Rex received an additional upgrade due to its presence in the film: a simplified skeleton and part of the musculature were modelled for the asset, which in turn formed the basis for a tissue simulation in Houdini using the newer Vellum-based Tissue System. The result was subtle, but provided better deformation and volume on the final animated asset. One advantage of working via CAT rig presets in 3ds Max was that the animations could be saved as separate clip files and transferred to identical rigs later. In this way, the animation scenes were kept very performant without having to load the entire asset. Possible revisions could also be quickly transferred to the corresponding main 3D scene later using a new clip.

For the animation, which was done exclusively with keyframes, it was important that all dinosaurs should reflect natural behaviour. In addition, the T-Rex should appear more aggressive than usual, which may also be due to the injuries. Smaller tics such as snorting, snarling and more impulsive movements helped with this. The animation would also have a strong influence on the editing; scenes were often extended to give the dinosaurs more time to perform.

For one particular scene, which features a herd of 20 dinosaurs, a crowd system was not used. Instead, I spent a weekend animating various actions with excess length – eating, head shaking, sleeping, looking out, running, etc. – which were then placed by hand using animation caches and staggered in time to get the appropriate variation. For a quick turnaround, it was advantageous that the individual animations did not have to be too detailed, as they would all blur together in the mass.

FX simulations

A critical point in the project was the FX simulations, as all the dinosaurs had to interact with the cold snow world. A few systems could be prepared directly in 3ds Max & Particle Flow, but Houdini was used for the rest.

For the most part, snow tracks were created procedurally using geometry; a few shots were even given a dynamic simulation with Houdini Grains, insofar as the interaction had to be represented much more subtly. An important component was also frozen breath for the T-Rex and finely swirled snow dust, which were simulated with PyroFX in Houdini. All Houdini project files were created in such a way that, depending on the shot, only the
correct assets for dinosaurs & environment had to be loaded & exchanged, with a little adjustment afterwards.

Otherwise, separate simulations were created for one or the other shot in the respective tool where it was best suited – such as a flock of birds in Particle Flow (3ds Max) or water splashes with fluids in Houdini. For simpler particle effects such as atmosphere, snowflakes, sparks and more, we even used Nuke Particles, which were incorporated as part of the compositing process.

In contrast, the most prominent FX interaction – where the T-Rex violently squeezes through two trees in one moment – was primarily animated by hand. Springs were again used in the rigging so that the bending of the branches did not have to be simulated. A secondary layer of different FX sims from 3ds Max & Houdini combined gave the moment the finishing touches.

Rendering & compositing

All elements were lit & rendered in 3ds Max with V-Ray; caches from Houdini were exported and imported as either VDBs or Alembics. All dinosaurs & snow elements were rendered directly with surface scattering, whereby the intensity of the scattering was slightly exaggerated in order to benefit from the additional details in the shading.
The lighting rig was kept quite simple to limit the amount of render passes – after all, all shots had to be rendered on a single desktop PC. For each CG element there was an average of 3-4 setups, one for each light and a separate data pass with geometric or vector-based render layers such as Zdepth, Velocity & Position.
As each element in this multi-pass setup was rendered separately, this resulted in countless renders, but only in rare cases did a pass exceed a render time of a few minutes per frame. The immense advantage of this setup was the compositing; the lighting & shading could be manually adjusted for each individual CG element without the need for a second render
a second rendering process was required. A comp template in Nuke, which had been refined over the years for V-Ray passes, helped with this, and changes could later be copied directly from one shot to another. Additional details such as dirt, blood and snow were often projected onto the surface of the dinosaurs using the geometric render layers, either as procedural setups or with prepared textures.
Thanks to the references & cleanplates on set, the integration process for the dinosaurs was quite effortless and the compositing template proved to be very robust.
Some shots also required a few more invisible compositing tricks: for example, in the final shot of the film, one of the hunters faces the T-Rex, but it was not possible on set to make the fur jacket flap in the wind as it roared. So a CG plane was generated in 3ds Max via Cloth-Sim and exported to Nuke, where it served as the basis for a 2D projection of the rotoscoped fur. Additional distortion filters created the impression of turbulent fur.

Environments

Environments also played a major role in the VFX. To keep the shooting schedule efficient, all shots were filmed in the same location – for example, during the first half of the film, the actors stared at the same hill in the distance where they would later be chased down by the T-Rex.
So with the help of digital matte painting, the hill had to be transformed into a flat plane, which was primarily done with alternative plates & more photographs. In addition, a somewhat more threatening sky and more atmospheric fog from the snowfall were added. The forest in the background, on the other hand, could be partially retained and was merely expanded; plates from the shoot with shaken trees helped to give the impression that a larger animal was in the background
to give the impression of a larger animal stalking around in the distance.
The trap was also collaged together from photographs of the smaller set on set, and a CG pole with a chopped off leg from one of the existing dinosaur assets added the finishing touches. In view of the fact that the DMP would be visible over an entire sequence, it was designed from the outset as a 3D projection in Nuke with simple geometry. Depending on the shot, the Matchmove camera or the DMP could be easily moved into position.

The opening shot of the film, in which a couple of pterosaurs fly through a snowstorm, was based on a drone shot of a mountain range at sunset, and followed a group of sled dogs. A new stormy sky was added, the dogs and other anachronistic objects were painted out, and Nuke Particles were used to generate a completely new atmosphere for the pterosaurs to freely interact with.

Digital double, weapons & wounds

During the confrontation, one of the humans, Hunter (played by Urban Bergsten), is scooped up by the T-Rex and thrown around. It was clear from the first draft of the script that a digital double would be needed for this moment, and during the shoot there was an extra photoshoot with the actor Urban in costume. The corresponding asset was built quite simply, as it would only be visible for a few seconds with a lot of blurring.

A male figure from the open source programme ‘MakeHuman’ served as the basis, with the model being slightly adapted to Urban in advance. The photos from the shoot were projected directly onto the models of the body and clothing; to suggest more details, while the model could remain quite simple. Instead, cloth simulations & a simple hair groom helped to make the character look more organic, animated with keyframes.
All the weapon props were also photographed on set and recreated quite simply on the base. With a little secondary animation, it was possible to create the impression that the weapons were dangling from the body and could be detached if necessary.
The digital props were also used in other shots. In one case, a digital bow was placed in the hand of one of the characters to cover up a mistake in the editing; another time, a spear throw had to be digitally replaced so that it could interact with the dinosaur.
Plates were originally shot for another shot in which Urban is grabbed directly, but because the moment was redesigned in post-production, the digidouble was also used here. With the help of a new camera, an environment assembled from various cleanplates and a few animation tests, the desired shot was found and was now realised entirely in CG. After the high-altitude ride, Hunter/Urban lands violently in the snow, and the (graphic) consequences are clearly recognisable – his body is torn open from the bite & the fall, and he is missing an eye. Despite a bit of practical facial make-up on set, the result wasn’t scary enough, so a bit of a rush job had to be done towards the end. After an initial (stomach-churning) online search for references, digital DMP patches or projections for wounds, blood spatter and torn clothing were created directly in Nuke for each individual shot. Depending on the situation, individual parts of the body were tracked in 3D or analysed using Smartvector in order to project the elements. Small variations were incorporated into the track for each level, giving the impression, for example, that wounds/skin and clothing moved independently of each other as the person squirmed.

The hunt continues.

In mid-May 2023, after around a whole year of work, all the VFX shots were finally finalised and delivered. The film went into colour correction & final mixing for another month, followed by the premiere in early June in the heart of Stockholm.
As the short film was also conceived as a pilot/pitch, they are already striving for higher things – while the film is enjoying initial success at festivals, the makers are already working on the first script version for a feature-length film. It is still far too early to say what the outcome will be. But we can only hope that the journey into this primeval world is not yet over, despite its dangers.

The post We Hunt Giants first appeared on DIGITAL PRODUCTION and was written by Andreas Feix.