Does someone plan to simulate Fluid on 3D
Author
I want to simulate 3d Fluid, and found some papers about it. But still cannot implement it in 3d. Does someone have some suggestions. 3d codes of the simulations would be best for me...
Thanks for you attention.
3D fluid and 2D fluid are basically the same idea. Is it that you're having problems understanding how a fluid simulation works, or that you're having problems scaling up to 3D?
I have Stam's source from "Real-Time Fluid Dynamics for Games" converted to 3D. If you want it, send me a private message with your email address.
I understand that Crane's chapter in GPU Gems 3 is 3D, but I haven't got my copy yet.
I understand that Crane's chapter in GPU Gems 3 is 3D, but I haven't got my copy yet.
Hey this is what I'm doing right now. Like someone suggested read the Stam's paper on his stable solver.
Then visit Mark Harris' page:
http://www.markmark.net/
Read his paper on simulation of clouds. From there follow the references to other papers.
I'm at the point of implementation. At this point I pretty much understand the mathematics behind the stable solver. If you need any help we can work together here.
What I'm doing right now is doing a basic 2D implementation in c++, as a testbed. From there I will probably proceed to a GPU implementation.
Then visit Mark Harris' page:
http://www.markmark.net/
Read his paper on simulation of clouds. From there follow the references to other papers.
I'm at the point of implementation. At this point I pretty much understand the mathematics behind the stable solver. If you need any help we can work together here.
What I'm doing right now is doing a basic 2D implementation in c++, as a testbed. From there I will probably proceed to a GPU implementation.
Quote:Original post by xissburg
Smoothed Particle Hydrodynamics
Yes, this is a nice technique for modeling fluids with support for splashing, etc. It can be computationally expensive to keep track of the proximities of a large # of particles, e.g., uniform grid is easy to manage but might not cull away enough particles...but hierarchical grid (octree, kd-tree) too expensive to maintain with particles moving around... Also, can be expensive to extract isosurfaces for rendering (though you could use particles to render).
Warning: Possible misinformation, proceed with caution.
Awhile ago I implemented a very simple ray-tracer. I implemented an algorithm called Buckysort/search (I wanted to test it against other algorithms).
http://www.mcnett.org/
His algorithm can be implemented on the GPU. So one may want to look into this algorithm and application to SPH.
My ray-tracing implementation (without any SIMD optimizations) was very slow. But from my tests this algorithm is very fast for searching of nearby regions, i.e collision detection of nearby objects. My ray-tracing adaptation was probably not implemented correctly.
Awhile ago I implemented a very simple ray-tracer. I implemented an algorithm called Buckysort/search (I wanted to test it against other algorithms).
http://www.mcnett.org/
His algorithm can be implemented on the GPU. So one may want to look into this algorithm and application to SPH.
My ray-tracing implementation (without any SIMD optimizations) was very slow. But from my tests this algorithm is very fast for searching of nearby regions, i.e collision detection of nearby objects. My ray-tracing adaptation was probably not implemented correctly.
There is another algorithm well suited for dynamic ray-traced scenes, forgive me, but I don't recall the name...
LOL.
LOL.
If all the particles are the same size (or at least nearly?) in the particle-based approach, then I think a grid would be vastly superior to other methods..
..because a grid is very cheap to update dynamically at O(n) whereas the tree-based methods usualy scale at O(n log n) for dynamic updating (often a full rebuild is best)
..The tree based methods do full O(n log n) collision detection, which is pretty good, but because the particles are (nearly?) the same size a very good grid size can be defined and that too should at least approach O(n) in practice.
..standard grid implementations blow off a lot of memory tho..
..because a grid is very cheap to update dynamically at O(n) whereas the tree-based methods usualy scale at O(n log n) for dynamic updating (often a full rebuild is best)
..The tree based methods do full O(n log n) collision detection, which is pretty good, but because the particles are (nearly?) the same size a very good grid size can be defined and that too should at least approach O(n) in practice.
..standard grid implementations blow off a lot of memory tho..
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
