Amazing fire and water physics simulations
category: general [glöplog]
imbusy: it's like the 2d version. a lot of a 2d fluid solver looks like blur (==diffusion) and edge detection (==project) ops, so it works really well on a gpu. the difference with 3d is you are "blurring" a volume. you can obviously read from a volume texture just as easily as a 2d texture, but to write it you have to do each slice at a time. it's a pretty straightforward extension - if, like in nvidia's demo, you can render to volume texture slices. which you can't do at all in dx9. :)
hurrah for Stam!
did a multithreaded fluid solver based on that and made some inner boundaries.. on a dual core it's 70% faster than a singlethreaded version.
i also tried SPH but the behaviour is still not too similar to fluid.. it splashes, yes.. but doesn't seem viscous enough, and there are a zillion parameters to tweak. the detection of the body edges is sweet, though..
did a multithreaded fluid solver based on that and made some inner boundaries.. on a dual core it's 70% faster than a singlethreaded version.
i also tried SPH but the behaviour is still not too similar to fluid.. it splashes, yes.. but doesn't seem viscous enough, and there are a zillion parameters to tweak. the detection of the body edges is sweet, though..
earx: what grid res did you manage with the grid method on dual core? :)
Quote:
the biggest problem extending the 2d smoke solver to 3d on the gpu was that gpus dont support render to volume slice.
It's fairly well supported as far as i know, and on much more hardware than the 8800 all alone.
When you think about it, the driver just sets the framebuffer address to a place where a slice of volume is stored, there is no reason that this feature would be unsupported, it's just an API limitation.. It also has the effect of disabling texture swizzling, which can hurt the rendering performance afterwards when using the 3d texture.
Well, in OpenGL it still requires the framebuffer object extension..
Quote:
which you can't do at all in dx9. :)
I have a 8800GTS and I managed to run the demo under winxp with only dx9.
You say that they render to slices. You mean that they create like ~32 render targets and render 4 passes, to 8 render targets each? That was I was thinking too, but it seemed to me to be an overkill.
smash: 400x300 or something, i have to check it again. quite good fps on core duo @ 1.8.. didn't use SSE but don't know if this would really benefit the Gauss-Seidel iterations with all the word juggling..
earx: so it was 2d?
lostsoul: supported yea, but not exposed :) as far as i know it's not exposed in dx9 (at least not without some vendor hack)
lostsoul: supported yea, but not exposed :) as far as i know it's not exposed in dx9 (at least not without some vendor hack)
Jos Stam have some excellent publications on the subject. Especially "Real-Time Fluid Dynamics for Games" which comes with c source and everything.
Check it out on http://www.dgp.toronto.edu/~stam/reality/Research/pub.html
We used the solver from the paper in our demo Aramchek and it also have a spring-mesh "water-simulation" in the end.
Check it out on http://www.dgp.toronto.edu/~stam/reality/Research/pub.html
We used the solver from the paper in our demo Aramchek and it also have a spring-mesh "water-simulation" in the end.
this is quite awesome: http://www.youtube.com/watch?v=DHSiSlmsUQY. prerendered version of a prod needless to say. :)
