 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
This is from a test run. I'm hoping to make the thing programmable.
(I.e., so you don't have to recompile the program every time you want to
run a different simulation.) If I get this working, maybe I'll post the
completed program...
Thanks Scott. ;-)
Post a reply to this message
Attachments:
Download 'frame0390.png' (73 KB)
Preview of image 'frame0390.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> This is from a test run. I'm hoping to make the thing programmable.
> (I.e., so you don't have to recompile the program every time you want to
> run a different simulation.) If I get this working, maybe I'll post the
> completed program...
Cool! What language are you using, Haskell? It's pretty cool how with the
very simple wave equation you can get all the pretty circular ripples and
reflections.
I did have a version that did the calculations on the GPU a while back, I'll
have to dig it out and put in on YouTube or something - still images just
don't do the wave equation justice!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
> Cool! What language are you using, Haskell?
Well DUH! ;-)
> It's pretty cool how with
> the very simple wave equation you can get all the pretty circular
> ripples and reflections.
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.
> I did have a version that did the calculations on the GPU a while back,
> I'll have to dig it out and put in on YouTube or something - still
> images just don't do the wave equation justice!
Ooo, GPU? That's gotta be pretty fast...
(My own implementation seems to spend far more time converting the
floating-point numbers into integers for display than it does actually
doing the integration... like, WTF?)
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. ;-)
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.
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] nawaz org<<<<<<
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'
|
|
| |
| |
|
|
|
|
| |
