|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Prompted by Tim's post. I found an example of something that did not turn out as
planned. This is supposed to be a wave in a circular container, with the wave
reflecting off the sides.
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
From: Tim Nikias v2 0
Subject: Re: Things that went wrong. - ob01b.mpg (0/1)
Date: 29 Mar 2003 08:36:43
Message: <3e85a16b$1@news.povray.org>
|
|
|
| |
| |
|
|
Yikes! What does your algorithm look like, how
does it interact with the objects, in order to get
that kind of effect? I don't understand why the
surface would suddenly rise to meet the
top rim of the containter, and then drop down in a
circular fashion as seen on the animation (which
you might have made smaller, the effect is clearly
visible on smaller scale as well).
Do you use that "magic algorithm", whic you can
find all over the net (and at Hugo Elias' page)?
--
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
Email: Tim### [at] gmxde
> Prompted by Tim's post. I found an example of something that did not turn
out as
> planned. This is supposed to be a wave in a circular container, with the
wave
> reflecting off the sides.
>
>
> Regards
> Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sat, 29 Mar 2003 14:35:45 +0100, "Tim Nikias v2.0" <tim### [at] gmxde> wrote:
>Yikes!
I like it.
>What does your algorithm look like, how
>does it interact with the objects, in order to get
>that kind of effect? I don't understand why the
>surface would suddenly rise to meet the
>top rim of the containter, and then drop down in a
>circular fashion as seen on the animation
>(which you might have made smaller, the effect is clearly
>visible on smaller scale as well).
Sorry will do, in future :-(
>Do you use that "magic algorithm", whic you can
>find all over the net (and at Hugo Elias' page)?
>
Well the algorithm is, I assume, the "magic algorithm". I know it as the water
effect.
Actually it's a variation of it using three arrays
buffer(2, W, H) = ((buffer(1, W + 1, H) + buffer(1, W - 1, H) + buffer(1, W, H +
1) + buffer(1, W, H - 1)) / 2) - buffer(0, W, H)
// Swap the buffers
buffer(0, x%, y%) = buffer(1, x%, y%)
buffer(1, x%, y%) = buffer(2, x%, y%) - (buffer(2, x%, y%) * damp)
buffer(2, x%, y%) = -1 'This line is what caused the
surface to suddenly rise to meet the
top rim of the container
I'm sure you get the drift.
For a circular edge, I ignored all elements that lay outside the circle in the
wave calculations. I must say that I'm no programmer (this is probably obvious),
and struggle with it. But it looked impressive I thought. I hope some others
will post interesting mistakes.
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
From: Tim Nikias v2 0
Subject: Re: Things that went wrong. - ob01b.mpg (0/1)
Date: 29 Mar 2003 17:25:48
Message: <3e861d6c@news.povray.org>
|
|
|
| |
| |
|
|
Hm. As I stumbled upon this, Rune and Christoph had
made some experiments, and gave me a push
in the right direction:
1. Smoothen with more than just the four neighbours,
take the diagonal neighbours as well, but weight them
a little less.
2. The initial wave shouldn't be just a single point, I've
found that using 9 nodes (with the center one being
the highest) gives very pleasing results.
--
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
Email: Tim### [at] gmxde
>
> >Yikes!
> I like it.
>
> >What does your algorithm look like, how
> >does it interact with the objects, in order to get
> >that kind of effect? I don't understand why the
> >surface would suddenly rise to meet the
> >top rim of the containter, and then drop down in a
> >circular fashion as seen on the animation
>
> >(which you might have made smaller, the effect is clearly
> >visible on smaller scale as well).
>
> Sorry will do, in future :-(
>
> >Do you use that "magic algorithm", whic you can
> >find all over the net (and at Hugo Elias' page)?
> >
> Well the algorithm is, I assume, the "magic algorithm". I know it as the
water
> effect.
> Actually it's a variation of it using three arrays
>
> buffer(2, W, H) = ((buffer(1, W + 1, H) + buffer(1, W - 1, H) + buffer(1,
W, H +
> 1) + buffer(1, W, H - 1)) / 2) - buffer(0, W, H)
>
> // Swap the buffers
>
> buffer(0, x%, y%) = buffer(1, x%, y%)
> buffer(1, x%, y%) = buffer(2, x%, y%) - (buffer(2, x%, y%) * damp)
>
> buffer(2, x%, y%) = -1 'This line is what caused the
> surface to suddenly rise to meet the
> top rim of the container
>
> I'm sure you get the drift.
>
> For a circular edge, I ignored all elements that lay outside the circle in
the
> wave calculations. I must say that I'm no programmer (this is probably
obvious),
> and struggle with it. But it looked impressive I thought. I hope some
others
> will post interesting mistakes.
>
>
> Regards
> Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sat, 29 Mar 2003 23:22:18 +0100, "Tim Nikias v2.0" <tim### [at] gmxde> wrote:
>Hm. As I stumbled upon this, Rune and Christoph had
>made some experiments, and gave me a push
>in the right direction:
Yes,I read the thread too.
>1. Smoothen with more than just the four neighbours,
>take the diagonal neighbours as well, but weight them
>a little less.
I used sqrt(2)
>2. The initial wave shouldn't be just a single point, I've
>found that using 9 nodes (with the center one being
>the highest) gives very pleasing results.
>
I started out using a different approach, for the initial array I've been
reading a graphic file (pgm) so I've painted a splash using a brush with a
hardness of 32 (Paint Shop Pro), same effect I think.
One thing I noticed was that there was a diamond shaped leading edge to the
wave. This disappeared when I made both initial arrays the same. I hope that is
clear.
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
From: Tim Nikias v2 0
Subject: Re: Things that went wrong. - ob01b.mpg (0/1)
Date: 29 Mar 2003 18:30:11
Message: <3e862c83$1@news.povray.org>
|
|
|
| |
| |
|
|
Also used sqrt(2), but hard-coded .707, that's sufficient
and faster than having the CPU calculate sqrt(2) all the
time.
How do you read the pgm-file? I've got no experience
with reading other files than those I've scripted myself.
But using an image as a base, wouldn't that be a
bit complicated if you'd want to set you're water surface
different than on a horizontal plane? Also, if you have
surrounding objects to block the waves, it would be
difficult to match splashes with surrounding environment...
BTW, how interactive is your system?
--
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
Email: Tim### [at] gmxde
>
> >Hm. As I stumbled upon this, Rune and Christoph had
> >made some experiments, and gave me a push
> >in the right direction:
>
> Yes,I read the thread too.
>
> >1. Smoothen with more than just the four neighbours,
> >take the diagonal neighbours as well, but weight them
> >a little less.
>
> I used sqrt(2)
>
> >2. The initial wave shouldn't be just a single point, I've
> >found that using 9 nodes (with the center one being
> >the highest) gives very pleasing results.
> >
> I started out using a different approach, for the initial array I've been
> reading a graphic file (pgm) so I've painted a splash using a brush with a
> hardness of 32 (Paint Shop Pro), same effect I think.
> One thing I noticed was that there was a diamond shaped leading edge to
the
> wave. This disappeared when I made both initial arrays the same. I hope
that is
> clear.
>
> Regards
> Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sun, 30 Mar 2003 00:26:42 +0100, "Tim Nikias v2.0" <tim### [at] gmxde> wrote:
>Also used sqrt(2), but hard-coded .707, that's sufficient
>and faster than having the CPU calculate sqrt(2) all the
>time.
Yes it is, I set it as a constant so I can try different values.
>
>How do you read the pgm-file? I've got no experience
>with reading other files than those I've scripted myself.
>But using an image as a base, wouldn't that be a
>bit complicated if you'd want to set you're water surface
>different than on a horizontal plane? Also, if you have
>surrounding objects to block the waves, it would be
>difficult to match splashes with surrounding environment...
>
>BTW, how interactive is your system?
>
It's not interactive. I'm using this project to learn C++ so I shell out to my
programme to create a heightfield. I found that the parsing time in SDL was too
long. Your system looks much better. For this project I want to create waves
around a footstep of a walking figure so I want to have a large array/
heightfield. I export a mesh from Poser and import it into POV. I'm playing with
BVH motion files, see my post in moray.binaries (called Spinkick something). As
for reading pgm files, they are text files so they are simple to read using
fileio. One thing to point out is POV does not read comment lines as per the
file specs. I don't know what you mean about setting the water surface different
than on a horizontal plane. In my world water is level :-)
Blocking objects are not in scope but I have an idea or two using an overlay. As
they say on Mastermind I've started so I'll finish.
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
From: Tim Nikias v2 0
Subject: Re: Things that went wrong. - ob01b.mpg (0/1)
Date: 29 Mar 2003 19:26:31
Message: <3e8639b7@news.povray.org>
|
|
|
| |
| |
|
|
Hm. Sounds interesting, though a little limited due to
the external handling...
And referring to non-horizontal water-surfaces: have
you seen the animations I've put on my website? They
use non-horizontal surfaces. In fact, I could easily
rotate the surface about its axis, and the macros so
far would still properly interact with the surface. I hope
that I can get that to work with objects as well...
Perhaps I'll prepare an animation to show it off in a
few days...
Anyways, good luck with your system. With C++ it
would defnitely be faster than mine...
--
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
Email: Tim### [at] gmxde
>
> >Also used sqrt(2), but hard-coded .707, that's sufficient
> >and faster than having the CPU calculate sqrt(2) all the
> >time.
>
> Yes it is, I set it as a constant so I can try different values.
>
> >
> >How do you read the pgm-file? I've got no experience
> >with reading other files than those I've scripted myself.
> >But using an image as a base, wouldn't that be a
> >bit complicated if you'd want to set you're water surface
> >different than on a horizontal plane? Also, if you have
> >surrounding objects to block the waves, it would be
> >difficult to match splashes with surrounding environment...
> >
> >BTW, how interactive is your system?
> >
> It's not interactive. I'm using this project to learn C++ so I shell out
to my
> programme to create a heightfield. I found that the parsing time in SDL
was too
> long. Your system looks much better. For this project I want to create
waves
> around a footstep of a walking figure so I want to have a large array/
> heightfield. I export a mesh from Poser and import it into POV. I'm
playing with
> BVH motion files, see my post in moray.binaries (called Spinkick
something). As
> for reading pgm files, they are text files so they are simple to read
using
> fileio. One thing to point out is POV does not read comment lines as per
the
> file specs. I don't know what you mean about setting the water surface
different
> than on a horizontal plane. In my world water is level :-)
> Blocking objects are not in scope but I have an idea or two using an
overlay. As
> they say on Mastermind I've started so I'll finish.
>
> Regards
> Stephen
Post a reply to this message
|
|
| |
| |
|
|
From: Christoph Hormann
Subject: Re: Things that went wrong. - ob01b.mpg (0/1)
Date: 30 Mar 2003 03:57:43
Message: <3E86B1C6.4A676065@gmx.de>
|
|
|
| |
| |
|
|
S McAvoy wrote:
>
> >
> It's not interactive. I'm using this project to learn C++ so I shell out to my
> programme to create a heightfield. I found that the parsing time in SDL was too
> long. Your system looks much better.
> [...]
This is about the same approach i took when doing my water animations some
time ago. Doing the calculations in a separate program is really much
faster. It is important to use a 16 bit pgm though, otherwise you will
probably soon get artefacts. For the influence of the environment and
moving objects i wrote an 'influence image' with the file writing
functions in POV.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 28 Feb. 2003 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sun, 30 Mar 2003 10:58:46 +0200, Christoph Hormann <chr### [at] gmxde>
wrote:
>
>This is about the same approach i took when doing my water animations some
>time ago. Doing the calculations in a separate program is really much
>faster. It is important to use a 16 bit pgm though, otherwise you will
>probably soon get artefacts. For the influence of the environment and
>moving objects i wrote an 'influence image' with the file writing
>functions in POV.
>
I don't know about artefacts I was getting clipped or flat topped waves with
straight sides before I changed to 16 bit pgm. I intend to write an 'influence
image' with the file writing functions. Also I will have footprint templates
that I will add in the correct places using the above. Of course all this means
that I will have to learn how the Trace Macro works. Work, work, work :-}
Tim's work looks really good and a lot more flexible, I am impressed at the
quality using smallish arrays. Thanks for the hints and encouragement
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|