Here is my implementation of water, which copies what Rune did, and uses Tim
Nikias's i/o macros to save the arrays to files between frames.  As simple
as it looks, I picked up a lot of neat things running through this: from
smooth triangle patches and finding normals, to making the edges on bezier
patches match up.

It looks like I'm getting two artifacts from the simulation.  One is the
"square" look of the wave when it starts.  The other problem is that the
frequency of the waves is sometimes higher than the frequency of the mesh,
so it looks funny.  I guess I can try a hexagonal grid instead of a square
one, but I have no idea how to get away from the spatial frequency problem.

Does anyone know of a macro that handles a hexagonal mesh?  I'll work some
more on it, but I was getting messed up in the corners.

Post a reply to this message

Attachments:
Download 'water test.MPG' (254 KB)

I looked at the animation. From your post I gather
you're using bicubic-patches?

The other thing: I think that the frequency of the waves
can impossibly be higher than the frequency of the mesh.
They're dependant on each other, the smaller the mesh,
the faster waves will move, the "grainier" they look.

The implementation suggested that waves aren't fully circular,
so I guess that's not you're fault...

But Rune should speak up, he knows a little more about those
matters!

Good start though.

Steven Vogel wrote:

> Here is my implementation of water, which copies what Rune did, and uses Tim
> Nikias's i/o macros to save the arrays to files between frames.  As simple
> as it looks, I picked up a lot of neat things running through this: from
> smooth triangle patches and finding normals, to making the edges on bezier
> patches match up.
>
> It looks like I'm getting two artifacts from the simulation.  One is the
> "square" look of the wave when it starts.  The other problem is that the
> frequency of the waves is sometimes higher than the frequency of the mesh,
> so it looks funny.  I guess I can try a hexagonal grid instead of a square
> one, but I have no idea how to get away from the spatial frequency problem.
>
> Does anyone know of a macro that handles a hexagonal mesh?  I'll work some
> more on it, but I was getting messed up in the corners.
>

--
Tim Nikias
Homepage: http://www.digitaltwilight.de/no_lights/index.html
Email: Tim### [at] gmxde

Post a reply to this message

"Tim Nikias" <tim### [at] gmxde> wrote in message
news:3CD### [at] gmxde...
> I looked at the animation. From your post I gather
> you're using bicubic-patches?

No, these were smoothed triangular patches.  I started with a 50X50 array
and each square was broken into 2 triangles.  I took the vnormalized normals
for the 6 triangles surrounding each point, summed them, vnormaled the
result, and saved the result to another array.  Then I made a mesh from
those smoothed triangles.

I went through the exercise of making a bicubic patch for each square, but I
was unimpressed by the improvement over what I had with the triangles.
Other images I made to test it looked smoother, this one stood about the
same.  I was getting the internals points in the matrix by using the point
before and after each edge to do a linear approximation of the slope.

> The other thing: I think that the frequency of the waves
> can impossibly be higher than the frequency of the mesh.
> They're dependant on each other, the smaller the mesh,
> the faster waves will move, the "grainier" they look.

Well, maybe.  I was thinking after the waves start reflecting and
interfering with other waves.  I think you're right, though.  Won't finer
meshes only make the problem smaller?  The way the algorythm works, making
the mesh smaller still keeps the "speed of sound" at 1 square per tick in
the verticle and horizontal directions.  I tried to take the average over 8
points, but that either resulted in a black hole or a featureless (but very
round) wave, depending on the damping and value you divid the sum of the
corner point by.

> The implementation suggested that waves aren't fully circular,
> so I guess that's not you're fault...
>
> But Rune should speak up, he knows a little more about those
> matters!
>
> Good start though.
>

Thanks.  I forgot to mention the disclaimer that it's my first posted
animation.

Post a reply to this message

Steven Vogel wrote:
> It looks like I'm getting two artifacts from the
> simulation.  One is the "square" look of the wave
> when it starts.

Use more blue samples. :)

> The other problem is that the frequency of the
> waves is sometimes higher than the frequency of
> the mesh, so it looks funny.

I don't think that's the problem. It looks like every other "pixel" in
your simulation is affected different than the other half of the
"pixels". Using more blur samples might also fix this problem. By blur
samples I mean those four array values that are avraged. I use at least
8 instead, with weights based in distance to the "center pixel".

> I guess I can try a hexagonal grid instead of a square one

That sounds complicated, but if you think that helps, give it a go...

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:  http://rsj.mobilixnet.dk (updated Apr 14)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Ring:  http://webring.povray.co.uk

Post a reply to this message

Hm. Perhaps you're not calculating the
normals the same "direction", and some point
upwards and some downwards?

Steven Vogel wrote:

> "Tim Nikias" <tim### [at] gmxde> wrote in message
> news:3CD### [at] gmxde...
> > I looked at the animation. From your post I gather
> > you're using bicubic-patches?
>
> No, these were smoothed triangular patches.  I started with a 50X50 array
> and each square was broken into 2 triangles.  I took the vnormalized normals
> for the 6 triangles surrounding each point, summed them, vnormaled the
> result, and saved the result to another array.  Then I made a mesh from
> those smoothed triangles.
>
> I went through the exercise of making a bicubic patch for each square, but I
> was unimpressed by the improvement over what I had with the triangles.
> Other images I made to test it looked smoother, this one stood about the
> same.  I was getting the internals points in the matrix by using the point
> before and after each edge to do a linear approximation of the slope.
>
> > The other thing: I think that the frequency of the waves
> > can impossibly be higher than the frequency of the mesh.
> > They're dependant on each other, the smaller the mesh,
> > the faster waves will move, the "grainier" they look.
>
> Well, maybe.  I was thinking after the waves start reflecting and
> interfering with other waves.  I think you're right, though.  Won't finer
> meshes only make the problem smaller?  The way the algorythm works, making
> the mesh smaller still keeps the "speed of sound" at 1 square per tick in
> the verticle and horizontal directions.  I tried to take the average over 8
> points, but that either resulted in a black hole or a featureless (but very
> round) wave, depending on the damping and value you divid the sum of the
> corner point by.
>
> > The implementation suggested that waves aren't fully circular,
> > so I guess that's not you're fault...
> >
> > But Rune should speak up, he knows a little more about those
> > matters!
> >
> > Good start though.
> >
>
> Thanks.  I forgot to mention the disclaimer that it's my first posted
> animation.

--
Tim Nikias
Homepage: http://www.digitaltwilight.de/no_lights/index.html
Email: Tim### [at] gmxde

Post a reply to this message

"Rune" <run### [at] mobilixnetdk> wrote in message
news:3cd7e59e$1@news.povray.org...

> I don't think that's the problem. It looks like every other "pixel" in
> your simulation is affected different than the other half of the
> "pixels". Using more blur samples might also fix this problem. By blur
> samples I mean those four array values that are avraged. I use at least
> 8 instead, with weights based in distance to the "center pixel".

You're right!  I had not noticed that.  Every other triangle does look
different.  Now I need to dig a bit and find out why.

I wonder why I didn't see that.  Thanks,

Steve

Post a reply to this message