[Soc-2005-dev] Fluid animation

[Jonathan Merritt]

Hi Daniel,

>One small comment though, I noticed from the webpage that you
>say "The bounding box of an object will be used to define a 
>region to simulate the fluid in". This is a pretty huge limitation
>to actually being able to use the fluid solver in animations.
>
>Is there hope of overcoming this limitation? (Know you are
>packing, so I don't expect a reply soon)
>  
>

I'll try to answer this question in case Nils is already on a plane. :-)

The Lattice-Boltzmann solver that Nils is using is a kind of cellular 
automata.  (Another example is Conway's "Game of Life".)  The problem 
space is split into a voxel grid of cells, each of which has a set of 
state properties.  The properties include such things as whether the 
cell has fluid or is empty, types of boundary cell flags, and fluid 
velocities within the cell.  The simulation advances a time step by 
allowing cells to interact with their nearest neighbours according to 
certain rules.

The simplest way to construct the voxel grid for the problem is as a 3D 
array in some pre-specified domain.  Hence the requirement that such a 
domain exist.  As Tom has already pointed out, I think you could make 
the domain arbitrarily large, as long as you have enough memory.

Based upon the papers on Nils' site, I can think of one way that the 
system might be extended to remove the requirement of a fixed domain.  
This would be to add an additional "bounds check" step to the solution 
iterations...

This step could be performed during each iteration to check whether the 
fluid is approaching one of the boundaries.  If so, the boundary could 
be grown to accomodate the movement.  Similarly, boundaries with 
distance between themselves and the fluid could be contracted.  After 
movement of the boundaries, the problem domain would be re-constructed 
and the cell properties simply copied across from the old problem 
domain.  This would provide a malleable boundary that would exactly 
surround the fluid volume at all times.  You would just need to make 
sure it didn't grow too large.

As I understand it, Nils' current algorithm already contains a step 
where the problem domain is copied, during the velocity propagation 
stage.  This could presumably be modified to copy propagated cell 
velocities into a new domain of a different shape and location.  
Provided the origin of each domain were tracked properly, and all the 
necessary book-keeping done, I don't see why it wouldn't work.

However, this kind of thing is probably for the future.  We want to be 
animator-friendly, but for now I think being Nils-friendly is the 
priority. :-)

Jonathan Merritt.