"triple_r" <nomail@nomail> wrote:
> Excellent job on the water.  It does look just a little viscous, but if you
> want to go all out and make it look like gel, check out:
> http://www.cs.berkeley.edu/b-cam/Papers/Goktekin-2004-AMF/index.html
>
> You're sure not obligated to read all or any of this, but...
>      Also, on a nerdier level, I'm curious about your solution method.  I've
> been working on the smoke simulation thing for a while (on and off - just
> check some time around february in this group for smoke stuff) but the
> biggest challenge was solving for the pressure.  I ended up coding for a
> symmetric banded sparse matrix and wrote fairly quick routines for the
> incomplete cholesky factorization and conjugate gradient method (for the
> specific case of the 3-D laplacian operator on a cartesian grid).  Did you
> use a canned solver?  Sounds like you wrote your own.  I was also looking
> into the octree thing, but haven't had enough time to spend time on it.
> For a couple reasons:
I also used a conjugate gradient method for the solving of the pressure.
Nearly all the articles I read on smoke or liquid animation used it. Now, I
use a simple relaxation method. It is less efficient but I have no more
problem with non symetric matrix.
>      1) I don't know much about the octree structure.  I'm not in computer
> science, so I know more about the equations than the programming of them.
> In the most general terms possible, how did you program the octree grid?
> Is it very fast or at least just not slow enough to outweight the cost of
> searching through it?  I sure like plain arrays a whole lot better...
I use an octree structure after the read of an article of Frank Losasso (see
http://www.cis.upenn.edu/~fostern/). The octree is used to split the
original grid very close to the fluid surface. For each cell close to the
surface, the cell is split in 8 sub cells. Each sub cell has is own
physical properties. The octree allow to simulate on a virtual thiner grid
without a huge memory comsumption. In my implemenation, the use of the
octree slow down the simulation (around half). In my case, the main
difficulty was the solving of the PDEs on the octree.
>      2)  You said you used a patched version of POV-Ray - does it support
> the octree structure?  My simulations on a 50x50x50 grid are already slow
> enough to render so if I can't render an octree structure, why program it?
> I have a Mac, so I'm not into the patched versions of POV unless they start
> with the word 'Mega.'
I used MegaPov 1.0 with the add of the patch for density file (see
http://staff.aist.go.jp/r-suzuki/e/povray/iso/df_body.htm). I made no
change to MegaPOV, the octree structure is than not supported for
rendering. I save my octree on a regular grid (typicaly 100x100x100) for
rendering.
>      3)  What about interpolation?  Tricubic?  (see p.b.i)
>      4)  What about the pressure?  I was so content with my solver; I'd hate
> to have to rewrite it.  I'm sure the discrete laplacian matrix doesn't look
> nearly as pretty for the octree structure.
>      Oh, and velocities -- if you import the boundary conditions via df3,
> how do you handle velocities?
The velocity is computed by a standard first order differentiation of 2
boundary states. It imply that the key frames defining the boundary
movement are close enough in such a way a linear interpolate between them
produce valide states.
>      If you even get this far - my posts tend to be long-winded - I'd be
> very grateful for any help since you're obviously a fair amount further
> along than I am.  I'll cut myself off here.
>  - Ricky

Post a reply to this message