Page Contents


Overlapping Simulators

In Phoenix, if two or more Simulators overlap, they see one another as the Isosurfaces of their loaded cache data, so one Simulator can be an obstacle or emitter in another simulation. You can preview the Isosurface of a Simulator in the viewport by enabling Show Mesh from the Preview rollout - this will be the shape that other simulators will interact with, when this Simulator is included in their simulation. This way a Simulator can be used as any regular deforming mesh geometry - it can be made Solid or non-Solid, can be selected in a Source as an emitter, can be used by a Body Force to attract or repel the fluid of another simulator, and also can be excluded or included from other Simulators' Interaction list. By default all Simulators are Solid and included in one another's simulations, just like any other geometry in the scene.

Simulators interacting as obstacles

It's important to consider that when simulating overlapping Simulators, you would often need to run the Simulators in a certain order. For example, you could have two Liquid Simulators, where "Sim1" would be a heavy liquid that would fill the bottom of a container first, and then "Sim2" would be a lighter liquid that will not blend with the liquid from Sim1, but instead will spill over it and float on top of it. In this case you need to run Sim1 first, and then running Sim2 would by default have the liquid of Sim1 as an obstacle, so the lighter liquid would avoid both the container geometry, and Sim1's Isosurface. Once you already have a cached simulation for Sim2, you must consider that Sim1 now would also see the liquid from Sim2 as a Solid obstacle by default, so if you run Sim1 again without changing any settings, it would produce a different simulation from the first time it was run. In order to avoid this and have Sim1 ignore Sim2's Isosurface, you could exclude Sim2 from the Interaction rollout of Sim1. Then, if you want to change how Sim1 behaves, you would need to run it and also run Sim2 after that, so Sim2 would interact with the new Isosurface of Sim1.

Using one Simulator as an Emitter in another Simulator

The same way that one Simulator can be used as a plain obstacle to another, it can also be used to emit fluid from its Isosurface. You just need to add a Source and select the first Simulator in it. This way, your first Simulator can run a Liquid simulation, and then be used as an emitter in a Fire simulation, so the liquid mesh would ignite in the second Fire/Smoke Simulator.

Transferring fluid between Simulators using a Cascade Connection

A more advanced example of interaction between two simulators would be a cascade connection, where the fluid flows from one simulator into another. You can use cascade setups for simulations with irregular shapes where using just one Simulator grid would leave a lot of empty space and consume an unneeded amount of RAM and processing power. Additionally, if the simulation can be broken into pieces that should run one after another, then the cascade simulation would also be a good choice - this way you can iterate on the first Simulator until it's right, then iterate on the second Simulator for the continuation of the effect, and so on.

Cascade simulations are handled differently for Fire/Smoke Simulators and Liquid Simulators:

  • A Liquid Simulator can be connected in a cascade setup to the previous Liquid Simulator in the sequence using the Cascade Simulator connector in the Grid rollout. The liquid flows from the Cascade Simulator to the Simulator that points to it. The Simulators must be run in this order as well. The only requirement for this setup is that the connecting simulators overlap. They can be oriented in any way and can have different resolutions. Many Simulators can be connected in a cascade chain, and many simulators can get fluid flown in from the same Cascade Simulator. Note that when rendering, each simulator will produce its own Mesh or Isosurface, so when using a refractive material, there could be visible seams between the different Simulators.
  • Fire/Smoke Simulators require more manual work because they don't simply have fluid Isosurfaces, but their volumes are irregular and have varying density. A Source can be used to make the first Fire/Smoke Simulator an emitter for the second one. The Source would emit in Volume Brush mode the kind of grid channels simulated by the first Simulator from the shape of the first Simulator's Isosurface. However, simply emitting from the Source would create constant density inside the volume, and would ignore the internal detail and density of the emitter Simulator. This can be solved by modulating the emission of each Source channel by a separate Grid Texture, each Grid Texture reading the corresponding channel from the emitter Simulator. This would imprint the exact fluid channels of the emitter Simulator into the destination Simulator.