Helo,

I'm posting a new fluid animation.

The movement of the cube is computed with the MechSim patch. The simulation
of the fluid is done with a program I wrote. The rendering is done with
MegaPOV 1.0.

Following the advice of Tim Nikias in a previous post, I put effort on the
rendering. I used transparency for the fluid, photon for caustics,
radiosity and pseudo HDRI (I used the office 3 map and include file
pHDRI.inc from the page of Jaime Vives Piqueres :
http://www.ignorancia.org/tech_page.php?image=17&db=tips).

The target was to be as realistic as possible.

I see 2 weak points :
- The caustics aren't sharp enough (I used 500000 photons per frame, It
seems to small but I anderstand it to late...).
- The fluid -> object influence is missing. It would have slow down the
object when it is progressing in the water. I tried to simulate it with
some friction in MechSim, but It wasn't enough.

Any Comment is wellcome.

Regards,
Fidos

The video is MPEG1 encoded.

Post a reply to this message

Attachments:
Download 'test.mpg' (613 KB)

That's pretty impressive! It looks like some kind
of thick gel. The lighting is superb, even if you think
there'nt enough photons!

-- 
Steven Pigeon, Ph. D.
ste### [at] stevenpigeoncom
ste### [at] videotronca
"fidos" <fid### [at] wanadoofr> wrote in message 
news:web.42695133d4211a5278b5b33e0@news.povray.org...
> Helo,
>
> I'm posting a new fluid animation.
>
> The movement of the cube is computed with the MechSim patch. The 
> simulation
> of the fluid is done with a program I wrote. The rendering is done with
> MegaPOV 1.0.
>
> Following the advice of Tim Nikias in a previous post, I put effort on the
> rendering. I used transparency for the fluid, photon for caustics,
> radiosity and pseudo HDRI (I used the office 3 map and include file
> pHDRI.inc from the page of Jaime Vives Piqueres :
> http://www.ignorancia.org/tech_page.php?image=17&db=tips).
>
> The target was to be as realistic as possible.
>
> I see 2 weak points :
> - The caustics aren't sharp enough (I used 500000 photons per frame, It
> seems to small but I anderstand it to late...).
> - The fluid -> object influence is missing. It would have slow down the
> object when it is progressing in the water. I tried to simulate it with
> some friction in MechSim, but It wasn't enough.
>
> Any Comment is wellcome.
>
> Regards,
> Fidos
>
> The video is MPEG1 encoded.
>

Post a reply to this message

Looks great. Like Steven said, more like some gel than water, but great
nontheless. An issue I see when viewing it frame by frame is the obviousness
of particles or voxels. It's a completely flat surface when the animation
starts, but as soon as the box hits the liquid, you see discretisation (?)
artifacts. Maybe you could smoothen the data somehow to make it less
obvious.

One thing that bugged me with this animation is the length of it. To me it
seems like it ends when the interesting stuff is about to occur (waves
crashing into each other). Also, I feel that this animation appears more
slow-mo, than realtime. Maybe that's why the water looks more like gel.

-- 
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>

Post a reply to this message

> One thing that bugged me with this animation is the length of it. To me it
> seems like it ends when the interesting stuff is about to occur (waves
> crashing into each other). Also, I feel that this animation appears more
> slow-mo, than realtime. Maybe that's why the water looks more like gel.


I completely agree with these points. I want to see what happens next!

But the rendering is fabulous, and I like the choice of background.

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message

The animation is 8 times slower than the simulation time. I allow to see the
detail. It also reduces by 8 the simulation time for a same movie length.
If you accelerate it by 8, it should give what the water simulator and
MechSim patch calculated.

It's true that the movie is short, but it is very CPU time consumming. For
the moment, I prefer to go quick in order to progress on my simulator.

Thanks for your reactions.

Regards,
Fidos

Post a reply to this message

in news:web.42695133d4211a5278b5b33e0@news.povray.org fidos wrote:

> I'm posting a new fluid animation.

I ran the animation many times, there's so much going on. Run it in slow 
motion and follow the bottom left corner of the cube. Great "interaction" 
of light water and object.

Ingo

Post a reply to this message

As others have already said, it looks more like gel than like water. 
Aside from the low speed of the whole thing, I'd excpect more splashes 
from real water.

But aside from that: Fantastic. I love that water-light-interaction.


Keep up the good work!
Florian
-- 
camera{look_at-y*10location<8,-3,-8>*10}#local a=0;#while(a<999)sphere{
#local _=.01*a-4.99;#local p=a*.01-5;#local c=.01*a-4.995;<sin(p*pi)*5p
*10pow(p,5)*.01>sin(c*c*c*.1)+1pigment{rgb 3}}#local a=a+1;#end
/******** http://www.torfbold.com ******** http://www.imp.org ********/

Post a reply to this message

Florian Brucker <tor### [at] torfboldcom> wrote:
> As others have already said, it looks more like gel than like water.
> Aside from the low speed of the whole thing, I'd excpect more splashes
> from real water.

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:
     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...
     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.'
     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?
     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

"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