Right now, the walls of the fluid domain act like those of an obstacle. Though, I have an idea for at least three more options. Two of them with kind of a use, too. The third would make sense for abstract stuff only, I guess… Maybe it could be made even more dynamic, allowing per-face (or something) change of behaviour.
Obstacle (default, as it’s now)
Outflow (simply, fluid that touches the sides seems to go on as if no walls are there, this behaviour would be like you put an outflow over the domain and initialize by shell)
Torus (what goes out on one side, comes back in on the opposite side)
KFlask / Mirrored Torus (KFlask = Kleinean Flask… Behaves like Torus but with axes mirrored. what Goes out comes in on the Opposite side, but mirrored along the center.
They all need to be configurable to some extend to limit it to certain side-pairs. For instance, if you simulate rain, Torus should be everywhere. Rain drops fall down and when they reached the floor (only if you want a rain-cutout, not if the rain is supposed to hit the floor, visibly), they fall down again from top, simulating new drops.
But if you are going to simulate an ocean, torus is useful aswell, being tilable, but it should not happen for top - and bottom sides. Else, all the water would fall through the floor, pouring down on the other side. Here, the behaviour would need to be fixed to left/right and front/back - surface-pairs.
So, it would be nice to set per face: Obstacle/Outflow/Torus and as an additional switch in the Torus-mode, Mirror along X-/Y-/Z-Axis (all three switched on would behave like a K-Bottle-like Domain.)
Also possible would be a smooth transition between those. As in particle-systems, where you for instance can set a body to allow particles to pass with a certain probability, it would be possible to set the domain to behave with a certain probability like a certain thing. For instance, a 50%-chance, that fluid goes through the surface (torus-style), the other 50%, that the fluid acts as if there is an obstacle. - This could also be done without probabilities but rather with splitting the forced, copying the force-fields on that position (I’ve no idea, but I guess, it’s done with vector-sets? ^^), halfing their influence and applying toroid behaviour on one and obsatcle-behaviour on the other. - Same would work for Mirroring.
The next feature, Subdomain, would be kind of a rule-changer inside the system.
For instance, if you want to have behaviour of water, overally, but on a certain region, the fluid should suddenly behave like honey, flowing way slower, you would use a domain with the setting “water” and a subdomain, as wanted, where you set it to be like honey.
Same thing for gravity. Wanna have liquid suddenly falling sidewards, rather than down? a subdomain could do just that…
- This could also be done with an event-option: As soon, as the liquid passes/is inside this mesh/whatever, it acts like honey. - this might be even more flexible and could add something like a time-based control… As soon as it passes the geometry, it smoothly changes behaviour within X seconds/frames/Blender Units.
Also, the gravity change could come from a gravity-field… I think, right now, fluid-sim doesn’t respond to force-fields?
Last feature could also be done with that geometry-event-thing… Or a hack of inflow/outflow.
This Portal would basically be like one inflow and one outflow. What goes into the outflow, comes out of the inflow somewhere else, with similar forces aplied to it. This would also allow for finetuned “Torus”-effect, as described above. Mirroring should be possible, too. Rotation would also rotate the forcefield. Size would multiply the force…
A bit crazy thoughts, I guess… What do you think?
Similar kinds of controls could be done with the new smoke simulation. I actually hope to see them unified, to allow for instance different kinds of fluids, acting together (oil, water, milk which allows the two to suddenly mix) and gasses, aswell as vapourizing, which affects amounts of liquid and smoke - Though, I guess, the things above would be easier to implement than this… ^^
Edit: Use of “Outflow”-behaviour would be rain again, seeping away into the floor. - Here, some kind of “Damped Outflow” would be nice, so that the rain isn’t gone immediatedly but seeps away slowly…