> Indeed. Although I'd actually prefer the waves to *not* reflect off the 
> edges of the framebuffer... but I can't see a way to achieve that.

You kind of get that effect automatically by not bothering to calculate the 
values around the border (ie clamping the border values to zero).  You can 
see this IRL by fixing a string at one end, pulling the other end tight, and 
then applying waves to the string - you will see them reflect off the far 
end.

If you want to avoid reflections then what (I think - not tested!) you need 
to do is calculate the points around the border of your simulation just like 
the others.  Of course you cannot work out the derivatives the same way 
because there are no further points out, but if you fix the derivative 
outside to zero then that should work.

> Ooo, GPU? That's gotta be pretty fast...

I just checked, a 1024x1024 simulation runs at 240 fps ;-)

> Have you tried playing with the reaction/diffusion equations? That's also 
> pretty fun... and yes, you have to see it in motion to truly appreciate 
> it. ;-)

That was next on my list, but I never got around to it.  The Navier-Stokes 
equations also look pretty cool for moving liquids (rather than waves). 
Some people have done some nice smoke/liquid simulations that run on the 
GPU:

http://www.youtube.com/watch?v=D4FY75GwA00

Post a reply to this message

>> Indeed. Although I'd actually prefer the waves to *not* reflect off 
>> the edges of the framebuffer... but I can't see a way to achieve that.
> 
> You kind of get that effect automatically by not bothering to calculate 
> the values around the border (ie clamping the border values to zero).  
> You can see this IRL by fixing a string at one end, pulling the other 
> end tight, and then applying waves to the string - you will see them 
> reflect off the far end.

Indeed, the *cause* is obvious. The *solution* is not.

> If you want to avoid reflections then what (I think - not tested!) you 
> need to do is calculate the points around the border of your simulation 
> just like the others.  Of course you cannot work out the derivatives the 
> same way because there are no further points out, but if you fix the 
> derivative outside to zero then that should work.

Actually, my simulation treats all points the same. The only difference 
is that in computing the derivatives, any point outside the actual grid 
is assumed to be zero. (This effectively creates zero-clamped points 
just outside the image.)

Perhaps what I should do instead is set the derivatives to zero for the 
edge points? But that would still give me a set of points that never 
actually move... hmm...

>> Ooo, GPU? That's gotta be pretty fast...
> 
> I just checked, a 1024x1024 simulation runs at 240 fps ;-)

NOOOO!! Damn you! >_<

My simulation manages about 2 seconds per frame for 100x100...

(Actually it was 10 seconds/frame. For unknown reasons, GHC's 
implementation of floor() is stupidly slow, but the equivilent 
truncate() function is way faster... go figure!)

>> Have you tried playing with the reaction/diffusion equations? That's 
>> also pretty fun... and yes, you have to see it in motion to truly 
>> appreciate it. ;-)
> 
> That was next on my list, but I never got around to it.  The 
> Navier-Stokes equations also look pretty cool for moving liquids (rather 
> than waves). Some people have done some nice smoke/liquid simulations 
> that run on the GPU:
> 
> http://www.youtube.com/watch?v=D4FY75GwA00

That's a GPU?? You'd have to have, like, 50,000,000,000 polygons to make 
it anywhere near that smooth! (And the RAM requirements alone preclude 
doing that.)

Post a reply to this message

> Perhaps what I should do instead is set the derivatives to zero for the 
> edge points? But that would still give me a set of points that never 
> actually move... hmm...

No no, set the 1st derivatives outside of the grid to be zero, then when you 
calculate the 2nd derivative you could still get a non-zero value.

So at [0], you would want to calculate:

2nd deriv = (x[1] - x[0]) - (x[0] - x[-1])

What i mean is to replace the (x[0]-x[-1]) term by zero.  I have no idea if 
that will work or not, but it seems like it might.

>> I just checked, a 1024x1024 simulation runs at 240 fps ;-)
>
> NOOOO!! Damn you! >_<
>
> My simulation manages about 2 seconds per frame for 100x100...

Hehe I just worked out how to use YouTube ;-)

http://www.youtube.com/watch?v=0GeDiFxCY9s
(make sure you click the "watch in high quality" text)

That's using a 256x256 grid, but it's drawing it in 3D as well as 2D so it 
runs a bit slower (~150fps).

>> http://www.youtube.com/watch?v=D4FY75GwA00
>
> That's a GPU?? You'd have to have, like, 50,000,000,000 polygons to make 
> it anywhere near that smooth!

Not that many, you just need each polygon to be roughly the size of a pixel.

> (And the RAM requirements alone preclude doing that.)

The results are stored as textures on the GPU, the actual polygon data does 
not ever exist fully, the GPU creates the polys on-the-fly from the texture 
data.  I think every GPU is fine with a few 1024x1024 textures.

Post a reply to this message

scott wrote:
> http://www.youtube.com/watch?v=0GeDiFxCY9s
> (make sure you click the "watch in high quality" text)

	Cool heightfields.

-- 
Be careful about reading health books. You may die of a misprint. - Mark
 Twain


                    /\  /\               /\  /
                   /  \/  \ u e e n     /  \/  a w a z
                       >>>>>>mue### [at] nawazorg<<<<<<
                                   anl

Post a reply to this message

>> Perhaps what I should do instead is set the derivatives to zero for 
>> the edge points? But that would still give me a set of points that 
>> never actually move... hmm...
> 
> No no, set the 1st derivatives outside of the grid to be zero, then when 
> you calculate the 2nd derivative you could still get a non-zero value.

I might try this if I have time...

> Hehe I just worked out how to use YouTube ;-)
> 
> http://www.youtube.com/watch?v=0GeDiFxCY9s
> (make sure you click the "watch in high quality" text)
> 
> That's using a 256x256 grid, but it's drawing it in 3D as well as 2D so 
> it runs a bit slower (~150fps).

I have no idea how hard this is for your GPU, but my CPU was loaded to 
75% just playing this back!

[I think there's something "wrong" with my PC. Any task involving the 
graphics card seems to put the CPU under an absurd amount of load. Like, 
if I open Notepad and scroll the window, the CPU goes to 100% until it 
stops scrolling. And if I twizzle the mouse wheel, the screen can't keep 
up with me...)

>> That's a GPU?? You'd have to have, like, 50,000,000,000 polygons to 
>> make it anywhere near that smooth!
> 
> Not that many, you just need each polygon to be roughly the size of a 
> pixel.

...which varies according to polygon distance of course. :-P

>> (And the RAM requirements alone preclude doing that.)
> 
> The results are stored as textures on the GPU, the actual polygon data 
> does not ever exist fully, the GPU creates the polys on-the-fly from the 
> texture data.  I think every GPU is fine with a few 1024x1024 textures.

Hmm, well whatever. I'll take implicit surfaces any day! ;-)

Post a reply to this message

Invisible wrote:
> graphics card seems to put the CPU under an absurd amount of load.

Just at a guess, try opening th edisplay properties, going to 
settings->advanced->troubleshoot and make sure the hardware acceleration 
is turned on?

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Invisible wrote:
> I'm hoping to make the thing programmable. 

This is nearly done.

I'm having a spot of local difficulty with the parser, but basically the 
program is in a working state now. For example, see the attachment. ;-)

Post a reply to this message

Attachments:
Download 'frame000260.png' (22 KB)

Preview of image 'frame000260.png'

hello

Post a reply to this message

St. wrote:
>   hello 

CLASSIC! :-D

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

"Orchid XP v8" <voi### [at] devnull> wrote in message 
news:48ff61ae$1@news.povray.org...
> St. wrote:
>>   hello
>
> CLASSIC! :-D

 Had to be done...  :)


>
> -- 
> http://blog.orphi.me.uk/
> http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message