   fluid physics
  Hello,I'm interested in a good article or tutorial for accurate fluid physics. I would like it to have some implementation details. I am not interested in making a real time algorithm because want to create a raytracer to simulate fluids.Anyone know one?thanks, Raxvan.   
Fluid Simulation, by Robert Bridson;  Read "Real-Time Fluid Dynamics for Games" by Jos Stam; it's real-time but still a good place to start. He has a C implementation of the algorithm described on his website somewhere, or used to, but I can't seem to find it now.   ;  I may be wrong, but fluid physics is a pretty complex topic.We had a whole semester about it, after 3 semesters of advanced mathematics (and nobody understood a sh.t about it).What kind of simulation are you looking for?   ;  The algorithm by Jos Stam is patented, just so you know.   ;Quote:Original post by _swx_The algorithm by Jos Stam is patented, just so you know.Yeah, I read this. Has whoever owns the patent ever gone after anyone?   ;Quote:What kind of simulation are you looking for?I am interested in particle fluids for liquid (or cloud/dust/nebula) nonrealtime simulation.The rendering is done using raytracing.   ;Quote:Original post by jwezorekRead "Real-Time Fluid Dynamics for Games" by Jos Stam; it's real-time but still a good place to start. He has a C implementation of the algorithm described on his website somewhere, or used to, but I can't seem to find it now.I implemented this algorithm on the CPU and then gave a talk at DigiPen about the disappointing results.  You have to be careful about what people call "real time".  What is not clear in that paper is the size grid on which Navier-Stokes is solved.  I ran a 256x256 grid on a 3 GHz core, only to get about 6 fps.  Surely, you can run on a much smaller grid to increase the frame rate, but then the resulting simulation is not satisfying (the "particles" are too large).  A GPU implementation with a 256x256 grid ran at 135 fps on an NVIDIA GeForce 9600 GT.  The GPU simulations are satisfying.The 3D solver on a CPU is also unimpressive performance-wise.  As it turns out, you can map this to the GPU for a big performance increase.  The only technical issue is how to represent the 3D grid/image to compute the finite differences for the z-derivatives (requires representing 3D image as a tiled 2D image and a dependent-texture lookup for z-offsets).I discuss all this and provide software for it in "Game Physics, 2nd edition"._swx_ wroteQuote:The algorithm by Jos Stam is patented, just so you know.His paper does not make it clear *what* is patented.  In order to figure out what a patent covers, you have to read the patent itself.  Anyone who has ever read such patents realizes that they are vague and try to encompass a larger scope than justified (if there is even any justification that makes sense).  And as is usual these days, mathematical/algorithmic/software patents are granted by a system whose participants just don't have a clue how straightforward these ideas are.  Anyone with basic training in numerical solution of ODEs/PDEs can come up with decent algorithms.  In fact many folks have done so a long time ago before the computer graphics field was in diapers.I doubt the patent system will change anytime soon.  Money and expensive lawyers speak.  Common sense does not.  I still believe that within my lifetime, students will eventually be asked to sign NDAs before taking certain technical classes within the university.  Years ago, I also believed that within my lifetime some students would claim that they would not turn in their class projects because they considered it to be Intellectual Property.  Indeed, that happened, and in a class I taught (on real-time computer graphics).The greatest compliment and respect you can pay your professors is to learn whatever you can from them, learn more than that, and then pass that knowledge onto the next generation so they may continue the cycle.  To skip the last step and instead file for patents on everything you can think of is insanity (oh, and perhaps greedy).  You want to keep something secret?  Just don't tell anybody.  And if they see what you have done and can quickly reproduce it and/or improve on it, then perhaps your ideas just were not that brilliant or innovative anyway, now were they.   ;Quote:Original post by Dave EberlyFluid Simulation, by Robert BridsonI really enjoyed reading this book. Unfortunately my studies have prevented me from implementing much of it, but it's easy to follow and it nicely covers the spectrum from background math/physics to implementation details. For me it felt like "the PBRT of fluid sim books".   ;  Sorry for hijacking this thread, but I have a simple question that maybe fits into this context. My main background is rigid body physics and if you start writing rigid body solvers they two first examples you would start implementing (in my opinion) are a simple pendulum and a sphere dropped on a plane. What are the basical examples in fluid simulation. I often see people dropping a ball of water into a box. Is this the way to go? Also is a 2D framework helpful to test new ideas before moving to 3D? Actually in my opinion it would be great to have something like Fluid2D and FEM2D similar to Box2D (but at the same high quality).Cheers,-Dirk