Previsualize a Liquid Pour: Simulate It or Animate the Shapes?

A pour test is not a contest between a solver and a curve editor. It is an answer to a question, and if you cannot say the question in one sentence with a frame number in it, both routes will produce something attractive and neither will tell you whether the treatment works.

So the order is fixed: name the beat, then pick the tool. Everything in this article is about holding that order under pressure, because the pressure to skip it is enormous. A simulated splash renders beautifully and arrives with a kind of authority. A keyed ribbon is cheap and lands exactly where you draw it. Both will tempt you into treating the picture as the answer.

Choose the beat before choosing the solver

Most commercial pour beats are one of four things. Write down which one you have.

Arrival. Something has to reach some place at some moment. The stream touches the inner rim at frame 12; the liquid clears the top of the glass before the cut. That is a timing question, and timing is authored in both routes.

Interaction. The liquid meets the vessel in a way the shot depends on. It curls over a lip, climbs a wall, pools before it spills. This is the only category where a simulation is doing something a curve cannot.

Shape. The pour ends in a silhouette that no liquid would hold, because the silhouette is the design. A ribbon that becomes a ring. A splash arranged around negative space. Here physical plausibility is not the goal; it is often the obstacle.

Product behaviour. The claim on screen is about the real substance. It pours without glugging. It coats. It holds a bead. No digital route establishes this, and no amount of resolution changes that.

The failure mode is picking a route first and then discovering you have answered a neighbouring question. A photoreal simulated splash is a poor use of a week when the idea is an impossible graphic ribbon, and a beautifully keyed ribbon cannot tell you anything about how liquid fills a container — it only tells you what you decided. Hold the beat constant across both routes or your comparison is between two different questions dressed as one.

Write the question so it can fail. "Does the stream reach the far rim before frame 12?" can be answered no. "Does it look right?" cannot.

Build the simulated interaction before its surface finish

A fluid setup is a stack of declarations before it is anything else: scale, source, receiving geometry, domain, collision representation. Get those wrong and no amount of meshing will save the shot, because they are the things the interaction is made of.

SideFX's filling documentation describes a procedure that connects source, domain, collision representation and solver settings, and notes that the relationship between scale and resolution can affect whether an intended container contains the fluid. That is a narrow claim about documented software behaviour, and it is the whole basis for what follows. Everything else here is working practice, not a documented value.

Here is a constructed test. None of it has been run. Every number is a stipulation chosen to make the comparison legible, not a measurement of anything.

Two things are worth doing before any run, because they are free.

The first is arithmetic, and it is rough. The vessel's inner radius is 60 mm, so its floor area is about 11,300 mm², and with 45 mm of depth to the rim it holds roughly 509 mL before anything crests. The nozzle's inner area is about 113 mm². A stream that has fallen 40 mm arrives at roughly 0.9 m/s, which delivers about 200 mL across the two-second beat — the lower two-fifths of the bowl. That treats the source as starting from rest at the nozzle, so it ignores any head standing above the outlet; a real gravity-fed supply arrives faster, while nozzle resistance and liquid clinging to the walls take delivery back down. It is a rough lower-bound check, not a forecast, and it does not settle whether the run stays in the vessel. The point is not the number. The point is that you would know the scale of the beat before spending a machine-hour — and that a spill, if it comes, is something to examine rather than something the arithmetic already decided.

The second is to decide what you are reading off the runs. Not "which one is smoother." Four questions:

• Through or over? Where the stream meets the rim, does liquid pass through the collision geometry, or does it slide over the lip? These look similar in a still and mean opposite things. Passing through is a representation problem — the proxy or the cell size is failing to be a wall. Sliding over is the modeled interaction actually happening.
• Containment. Does the vessel still hold what the source delivered by frame 48?
• Same event or same shape? At frames 10–14, are the runs showing the same contact, or different contacts that happen to have similar outlines?
• What disappeared? The coarse run's value is not that it is cheap. It is that whatever vanishes at 5 mm was never part of the answer, only part of the setting.

Fill in the observed column only after the runs exist.

The most useful outcome is a disagreement, but the coarse and resolved runs differ in two ways at once — cell size and collision proxy — so a changed rim interaction between them could belong to either. That is what the proxy-isolating run is for. If the interaction at 1 mm against the rim-less proxy matches the coarse run, the proxy was doing the work; if it matches the resolved run, the cell size was; if it matches neither, both dependencies are live in the same result. Until that run exists, a disagreement is not an answer — it is a dependency you cannot yet name, and you should say so in the treatment rather than shipping the prettier one. If the contact interval is the whole beat, you can afford to spend resolution and time there and let the settled tail run cheap. Uniform resolution across a two-second pour is a habit, not a requirement.

Keep the simulation state identifiable through surfacing

The caching documentation, from the same source, describes saving simulation data and surface geometry as distinct stages. That distinction is the thing that keeps a revised render from quietly becoming a different claim.

Say you re-mesh, or shade differently, or change the surface's smoothness. If the simulation stream is unchanged, you have made a new picture of the same motion. That is cheap and legitimate and you should feel free to do it as often as the look demands. But if you changed the voxel size, the collision proxy, or the solver settings, you did not re-render anything. You ran a new test, and the old motion cannot be used to argue for the new one.

So give every run an identity and use the same name for the folder: solver version, cell size, source, collision proxy revision, frame range, and the settings file. Six fields, written once, saves an argument later.

Then do the boring verification. Reopen the recorded cache and step through the contact passage before you present it. The failure this prevents is specific and common: a hero still pulled from the resolved run, a beauty render from the coarse one, and a presentation that shows two things while claiming one. A still from a different simulation state cannot validate timing or contact, no matter how good it looks.

And keep the limits straight. A file cache that reloads identically proves the run is reproducible. It says nothing about whether the run resembles liquid.

Build the authored alternative and compare the actual promise

Now build the other route at the same frames. The point of the keyed version is not to be a cheap sim. It is to find out what authored control actually buys you on this beat.

Key four things, all at the stipulated numbers: the arrival at the rim on frame 12, the contact shape at impact, the settling silhouette, and the final graphic form and its hold from frame 40 to 48. Keep the fluid's declared material properties out of it entirely — they were invented anyway, and carrying them over would just disguise the authorship.

What the authored route does well is land on an exact silhouette at an exact frame and hold a shape nothing physical would hold. It can control negative space inside a splash so a logo reads through it. It never surprises you.

That last quality is also the cost. A simulation can produce a contact you did not plan — a curl you would not have drawn. An authored stream's rim interaction is only as interesting as the animator's idea of one. If the beat lives on that interaction, a keyed version is a storyboard with better lighting.

Then compare both at the same frame numbers on the same four inspection points, and add a fifth column: what would a viewer infer about the product?

This is where the routes differ in kind, not degree. A simulation says, in effect, given these declared conditions, the modeled contact produced this. An authored shape says we chose this. The first invites the viewer to infer physics. The second invites them to infer intent — and that inference is governed by the whole film, not by your file naming. If a thick ribbon climbs the rim and holds a standing bead, a viewer reads a viscous product. If the stream lands hard and sheets, they read something thin and fast. If the shot is cut and graded to look like a demonstration, they will treat the impossible flat disc as a fact regardless of what you called the folder. Labelling protects you internally. It does not protect the viewer's inference.

So when the beat's claim is about the real substance — pour behaviour, splash, coating, whether it holds a bead — the only route that can support it is a planned shoot: the real product at a declared temperature and age, a real vessel, controlled source behaviour, enough takes to see variation. One handsome pour is a picture, not a measurement. A digital version has a legitimate place in that work: plan the camera, the timing, and the vessel geometry, then shoot. That is a handoff, not evidence.

Ending on the route and what it does not establish

Write the route down in the treatment, in the present tense, with the numbers from the beat.

Simulated contact, 1 mm cells, rim proxy preserved. Stream meets the inner rim at 0:00:00:12 and settles into the graphic shape by 0:00:01:16. Declared approximation: invented liquid, uncalibrated viscosity, no measured source rate.

Or:

Authored liquid motion. The ribbon reaches the rim at 0:00:00:12 and holds the graphic shape from 0:00:01:16. Declared approximation: silhouette and timing are drawn, not modeled.

Then add the sentence that keeps the whole thing honest, because the route itself will not:

Whether the product pours this way remains untested.

If the treatment's image needs that sentence to be false, no digital route can make it true. Take the synthetic comparison to someone who has run real fluid setups and ask where the contact stops being believable — not whether it looks nice. And if the answer matters commercially, plan the physical pour: the declared approximation was always going to end there.

Frequently asked questions

What should determine whether to simulate or animate a liquid pour?

First name the beat and write the question with a frame number. Arrival is a timing question; interaction may need simulation; shape is an authored silhouette; product behaviour cannot be established digitally.

Why not pick the tool first?

You may answer a neighbouring question. A photoreal simulated splash is a poor use of time when the idea is an impossible graphic ribbon, and a keyed ribbon cannot show how liquid fills a container. Hold the beat constant across both routes or the comparison is between two different questions.

What should the simulation test and inspection points clarify?

The test should state scale, source, receiving geometry, cell sizes, collision proxy, and the beat. Read the runs for through-or-over contact, containment, same event versus same shape, and what disappeared. If coarse and resolved runs differ in cell size and proxy, a proxy-isolating run separates those dependencies.

Why is changing voxel size or collision proxy a new test rather than a re-render?

The simulation state changes. Re-meshing or shading the same simulation stream makes a new picture of the same motion, but changing voxel size, collision proxy, or solver settings changes the motion, and the old run cannot validate the new one.

What can an authored liquid route not establish?

It can land exact silhouettes and hold shapes nothing physical would hold, but its rim interaction is only as interesting as the animator's idea of one. It cannot establish product behaviour such as how the real substance pours, coats, or holds a bead; that needs a planned physical shoot.

Further reading

• Show What a Product Demonstration Actually Demonstrates — Read next when the beat's claim concerns real product behaviour: it separates an observable event from the inference a viewer draws, and names the conditions to declare.
• When Does a Commercial Treatment Need Storyboards Instead of More Prose? — When the beat is really about timing or simultaneity, this asks whether a plan or a short timed study could settle it before either route is built.