[Soc-2005-dev] Fluid animation

[Nils Thuerey]

Hello,

I have an internet connection again, so I can finally answer - but I
think Jonathan already explained the approach. Basically that's a
problem for all LBM or Navier-Stokes/Levelset based solvers. Only SPH
has an advantage there, but you'll also need at least some tree
structure there to organize the particles.

Jonathan - this copying strategy is a good idea, and you're right, it
shouldnt be too hard to implement. I also thought about this, and I at
some point wanted to implement a grid consisting of small(er) blocks, so
that areas dont have fluid dont use too much memory. But that will be
more difficuilt. Overall I think that extensions like rigid body
interaction are more important though. In most cases you can e.g. just
reduce the resolution a bit (or buy more memory :) to get it working.

Regards,
-> Nils


Jonathan Merritt wrote:
> 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.
> 
> _______________________________________________
> Soc-2005-dev mailing list
> Soc-2005-dev at blender.org
> http://projects.blender.org/mailman/listinfo/soc-2005-dev
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : http://projects.blender.org/pipermail/soc-2005-dev/attachments/20050730/f45d720c/signature.pgp