@Bourbaki
yes, i already saw your thread. your solver looks quite impressive. congrats!
indeed, grid based approaches really are rather slow and wasteful on the memory-side. but i don't think i should use the particle-based approach either. that's more for interacting with the fluid. and i don't really care about the fluid being compressive or not compressive. i am only interested in the velocity field of a fluid, with its eddies and stuff. maybe i do not even need a whole fluid simulation ... but it seems to be the most obvious way and the only way i know.
but i'm looking forward to your article!
@Eelco:
i already thought about the airbubbles. maybe this will help with the visualization.
i'm looking for an "view into the ocean from beneath the water surface" style.
so it should be blue, somehow changing with the flow movement and a falloff to darkblue along the z-axis. i don't know how to couple the flow data to some rendering ...
realtime fluid dynamics
You may want to take a look at Plasma Pong, which was written by one of the forum's members a few months back.
It's basically Pong inside a contained viscous fluid, but it plays and looks wonderful. As far as I know, the author modelled the Navier-Stokes equation on a uniform grid, solving it in real-time with finite-differencing.
The method sounds simple enough, and all of your conditions seem to drop straight out of the model.
Regards
Admiral
It's basically Pong inside a contained viscous fluid, but it plays and looks wonderful. As far as I know, the author modelled the Navier-Stokes equation on a uniform grid, solving it in real-time with finite-differencing.
The method sounds simple enough, and all of your conditions seem to drop straight out of the model.
Regards
Admiral
@TheAdmiral: thanks, Plasma Pong looks awesome! i really like its render style and the performance. i am going to contact that guy ..
anyone had any experience with LBM (Lattice Boltzmann method)? AFAIR this might solve some of my "problems".
anyone had any experience with LBM (Lattice Boltzmann method)? AFAIR this might solve some of my "problems".
Quote:Original post by ghostd0g
indeed, grid based approaches really are rather slow and wasteful on the memory-side. but i don't think i should use the particle-based approach either. that's more for interacting with the fluid. and i don't really care about the fluid being compressive or not compressive. i am only interested in the velocity field of a fluid, with its eddies and stuff. maybe i do not even need a whole fluid simulation ... but it seems to be the most obvious way and the only way i know.
I'm not sure I agree with this. When using multigrid or conjugate-gradient solvers (Which Stam did not do for his published works on stable fluids), grid-based approaches can be very damn fast. You have the advantage of being able to more easily package the cells in a CPU cache-friendly way, compared with particle methods, for an extra performance boost. (But things like multigrid do use lots of memory, like hierarchical spatial partitions of triangles used for visual occlusion culling.)
And as for particle-based fluid methods, there you have the problem of keeping track of "neighborhoods" of particles that have influence on each other. The neighborhoods are needed to compute kernel functions for, say, the SPH method of particle-based fluids simulation. The neighborhoods are typically maintained in a spatial partition, which must be dynamically updated as the particles move around. And the update of the spatial partition will slow down the particle methods.
Now, Stam's method is a hybrid. It has a gridded part and a particle part. His grid becomes the spatial partition for tying the particles back to the continuous fluid. His grid is a uniform grid. This works fine, and fast enough for a fairly small number of particles. But for a very large area of fluid, you'd potentially need a massive number of particles. And the uniform grid partition would not enable fast enough searches. You need a hierarchical spatial partition, such as an octtree or K-d tree. Hierarchical spatial partitions increase the memory needs, and dynamically updating those over time can be very challenging indeed, and quite slow.
Particle systems can be easier to implement, and work well for large areas, until you add tons of particles and need to make it fast. Particle systems do provide a more natural way to interact with other physics objects in a scene, such as rigid bodies.
For velocity fields, I agree that you probably don't want to use particles. Grids are going to give a better result. First, to generate a meaningful field, you'd end up evaluating the SPH kernel functions on a grid anyway. Second, with particles scattered in a somewhat random fashion, when you do evaluate the kernel function, you are going to have hot spots where there are particles, cold spots where there are no particles, and this will appear quite unnatural in the velocity field.
I dont know if my approach is very different from the usual particle based approach but its kind of a FEM which makes the overall thingy continious.
And also this allows me to model density and heat based adaptation of the fluid. Another thing i found very hard to achive with gridbased approaches in interactive speed was that the fluids are compressible. For the velocity fields i think its right that if you need information of the field at each point in the space you are better off with the grid approach but this is getting slower the bigger the grid is if you are off fine with a sparse description of the surface you could just use particles whereever you need them.
What i think is most appealing of my approach is that i can really derive the surface functions and thus not do these finite differences which have some issues with the propper distribution if i am not mistaken.
And also this allows me to model density and heat based adaptation of the fluid. Another thing i found very hard to achive with gridbased approaches in interactive speed was that the fluids are compressible. For the velocity fields i think its right that if you need information of the field at each point in the space you are better off with the grid approach but this is getting slower the bigger the grid is if you are off fine with a sparse description of the surface you could just use particles whereever you need them.
What i think is most appealing of my approach is that i can really derive the surface functions and thus not do these finite differences which have some issues with the propper distribution if i am not mistaken.
Plasma Pong is based on Stam's paper (The GDC2003 one).
Keep in mind, though, that the code in his paper is *horribly* unoptimized. I'm not sure if that's because he just sucks at writing efficient code, or because he wanted to keep it simple and readable. (Or because he intentionally wanted to keep the "efficient" solution to himself), but you can get a 4x speedup without too much trouble.
At uni, I made a 6 month project of optimizing it, and got around 8x the original performance.
Keep in mind, though, that the code in his paper is *horribly* unoptimized. I'm not sure if that's because he just sucks at writing efficient code, or because he wanted to keep it simple and readable. (Or because he intentionally wanted to keep the "efficient" solution to himself), but you can get a 4x speedup without too much trouble.
At uni, I made a 6 month project of optimizing it, and got around 8x the original performance.
All methods get slower as you add detail. Multigrid methods, when applicable, scale about linearly with problem size for gridded solutions, which is probably similar to the scalability of particle methods---assuming the spatial partition update for the particle method scales linearly (and that might or might not be true). So, my point is that gridded methods can scale very, very well, depending on implementation. Multigrid (and the other fancier, fast gridded solvers) can be tricky to implement correctly, though.
Quote:Original post by erissian
Just to clarify, you're not interested in rendering the surface of the water, just underneath the water?
I would love to learn about the different approaches considering these two goals. As stated before in this thread, Navier-Stokes is the way to go if you want to simulate the flow inside the fluid. What is the recommended approach if you wanted to simulate the flow of a fluid through an environment (with rigid bodies etc.)? Particles? And finally there are visual effects fluids, which are accomplished through shaders. However, my main interest are first two cases.
[Edited by - kloffy on November 11, 2006 11:27:49 AM]
http://dan-ball.jp/javagame/mc/ <-- best 2D water simulation( from the side view, top down is acctually a much easier thing to figure out) I have seen in action. Really cool way to do it, if you mess around with it you can kind of see how it works... kind of :O
@grhodes_at_work:
Thanks for your input. I've read about using a conjugate-gradient solver. It actually was one of the optimization suggestions in Stam's paper.
I don't understand the part of uniform grid partitions would not enable fast enough searches. What do you mean by fast searches? It's just a bunch of contiguous values in memory which need to be updated every simulation step. And to get the value at a specific point on the grid the cost is always the same.
I think particle-based approaches fit better for simulating free roaming liquids and their physical interaction with objects (as you said).
But in my project it's just two small streams and a big pool (over several screens) with a mill wheel in it. One stream for the inflow and one for the outflow. And there are Animals in the "fluid" that might be affected by the flow field.
What do you mean by Multigrid and fast gridded solvers?
I'm also thinking about flow tiles for a contiguous flow simulation. So every client could simulate and render the flow and it would not be the task of the server. But besides this paper there is not much information out there.
@djperegrine:
funny demo, but i don't think i get something really valuable for me out of it.
[Edited by - ghostd0g on November 12, 2006 11:40:11 AM]
Thanks for your input. I've read about using a conjugate-gradient solver. It actually was one of the optimization suggestions in Stam's paper.
I don't understand the part of uniform grid partitions would not enable fast enough searches. What do you mean by fast searches? It's just a bunch of contiguous values in memory which need to be updated every simulation step. And to get the value at a specific point on the grid the cost is always the same.
I think particle-based approaches fit better for simulating free roaming liquids and their physical interaction with objects (as you said).
But in my project it's just two small streams and a big pool (over several screens) with a mill wheel in it. One stream for the inflow and one for the outflow. And there are Animals in the "fluid" that might be affected by the flow field.
What do you mean by Multigrid and fast gridded solvers?
I'm also thinking about flow tiles for a contiguous flow simulation. So every client could simulate and render the flow and it would not be the task of the server. But besides this paper there is not much information out there.
@djperegrine:
funny demo, but i don't think i get something really valuable for me out of it.
[Edited by - ghostd0g on November 12, 2006 11:40:11 AM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement