Guest xionmark Posted August 8, 2005 Share Posted August 8, 2005 I saw Nils' LBM fluid stuff at siggraph, and downloaded his papers as soon as I got back. His stuff looked very good. 20291[/snapback] Yea, I saw it too, it looked very interesting. I had hoped I would catch him at the poster but no luck, I'll email him. Haven't had a chance to read his paper yet, probably wouldn't understand 99% of it anyways ... just give me the spec, I'll implement! --Mark Quote Link to comment Share on other sites More sharing options...
ivan Posted August 8, 2005 Share Posted August 8, 2005 why make an eulerian solver? why not implement an SPH solver? it's a much easier thing to implement.... http://www.iro.umontreal.ca/labs/infograph...avet-2005-PVFS/ Quote Link to comment Share on other sites More sharing options...
Mario Marengo Posted August 9, 2005 Share Posted August 9, 2005 why make an eulerian solver? why not implement an SPH solver? it's a much easier thing to implement....http://www.iro.umontreal.ca/labs/infograph...avet-2005-PVFS/ Nice! Thanks for the link, Ivan. Yup, that should be simple to implement. Though Thuerey's LBM method seems very doable as well... and *very* compelling. Lots of really good choices. This is great! I'm curious Ivan, if you've had a chance to implement both voxel/particle approaches, what you can share in terms of quality, pipeline integration, etc. At first glance, it seems that the particle-based method you link to would "play nice" with the rest of DOPs without much effort, since each particle could be considered a rigid body and so easily transfer data to other solvers. Provided that the limit surface can be made production-quality smooth (seems a little "blobby" in the demos but that could just be the large-sized spheres being used to keep it interactive). Any insights appreciated Quote Link to comment Share on other sites More sharing options...
ivan Posted August 9, 2005 Share Posted August 9, 2005 the blobbieness is because the author has an eye on the realtime market, but his stuff is solid. The way that an SPH solver works seems like it would lend itself to a shared programming effort a little better than an eulerian grid-based solver, especially in Houdini where there are already libraries for handling needed stufff (particle primitives already defined, blobbies defined already, particle style collision detection, etc...). Real Flow shows how good an SPH solver can be, I know R&H implemented one and used it for the paddle wheels on "Around the World in 80 days", someone there told me it was very easy to implement. Other than that, I believe the technique is underutilized. The main thing that Real Flow has brought to the technology is years of banging on the code and refining it (I believe they do have a really nice tesselator and several other things) and of course support. But the technology that it is based on is not as difficult as one might think. There's also this one http://graphics.ethz.ch/~mattmuel/publications/sca05.pdf and many other papers. Nice! Thanks for the link, Ivan.Yup, that should be simple to implement. Though Thuerey's LBM method seems very doable as well... and *very* compelling. Lots of really good choices. This is great! I'm curious Ivan, if you've had a chance to implement both voxel/particle approaches, what you can share in terms of quality, pipeline integration, etc. At first glance, it seems that the particle-based method you link to would "play nice" with the rest of DOPs without much effort, since each particle could be considered a rigid body and so easily transfer data to other solvers. Provided that the limit surface can be made production-quality smooth (seems a little "blobby" in the demos but that could just be the large-sized spheres being used to keep it interactive). Any insights appreciated 20340[/snapback] Quote Link to comment Share on other sites More sharing options...
ivan Posted August 9, 2005 Share Posted August 9, 2005 oh yeah, and I almost forgot this one http://sourceforge.net/projects/fluids/ but it is of course eulerian. Quote Link to comment Share on other sites More sharing options...
Mario Marengo Posted August 9, 2005 Share Posted August 9, 2005 The way that an SPH solver works seems like it would lend itself to a shared programming effort a little better than an eulerian grid-based solver, especially in Houdini where there are already libraries for handling needed stufff (particle primitives already defined, blobbies defined already, particle style collision detection, etc...). Thanks Ivan, I think I'm now convinced that, at least as a first stab at fluids, SPH is the way to go (the Muller paper makes another good argument in favor of SPH for the case of phase transitions). This is quickly becoming more a problem of which among all these excellent papers to choose from, than whether there are any good resources out there -- a good problem to have, for sure. Only one way to find out... time to get coding -- even if it's just to learn the DOPs side of the HDK. I wonder which way SESI is planning on going with fluids... Mark T. ? Cheers! Quote Link to comment Share on other sites More sharing options...
Slapdaddy Posted August 9, 2005 Share Posted August 9, 2005 why make an eulerian solver? why not implement an SPH solver? it's a much easier thing to implement....http://www.iro.umontreal.ca/labs/infograph...avet-2005-PVFS/ 20299[/snapback] I have done both. It took me a week to get a basic SPH solver working. It would be great to use for any fluid that does not need pressure, but unfortunately SPH does a lousy job with pressure and there is currently no nice way to get surfaces that don't look like oatmeal. It's still good for some things especially considering that FX people seem to love particles and they can relate to SPH. If you want SPH I would suggest sticking with Real Flow. Quote Link to comment Share on other sites More sharing options...
Guest xionmark Posted August 9, 2005 Share Posted August 9, 2005 If you want SPH I would suggest sticking with Real Flow. 20379[/snapback] Only problem with that is you have to put up with, hmmm, let's see, instability, a strange GUI, bad memory and performance footprint, and of course little to no support from Next Limit. I wish that wasn't the case, I've been hopin' for about 3 years that things would change ... no luck. --Mark Quote Link to comment Share on other sites More sharing options...
MADjestic Posted August 10, 2005 Share Posted August 10, 2005 unfortunately SPH does a lousy job with pressure and there is currently no nice way to get surfaces that don't look like oatmealIf you want SPH I would suggest sticking with Real Flow. 20379[/snapback] What does it mean that it works bad with pressure? And it seems that you sympathise euler solver, why is that? Actually I don't know the drawbacks or benefits of these methods - could you clarify a bit, please? Thanks. Quote Link to comment Share on other sites More sharing options...
mtucker Posted August 11, 2005 Share Posted August 11, 2005 I wonder which way SESI is planning on going with fluids... Mark T. ? We were planning on waiting for all of you to write it for us We actually haven't made any decisions on fluids at this point. It's a good question though because even more than other solvers, fluid solvers each have their own strengths and weaknesses. There is not going to be any one algorithm that works in all cases. We'll keep you posted. Mark Quote Link to comment Share on other sites More sharing options...
Wolfwood Posted August 11, 2005 Share Posted August 11, 2005 We were planning on waiting for all of you to write it for us 20441[/snapback] Do you guys have some magical document hidden away at SESI HQ which provides a overview of the DOPs architecture and how the different classes work together? Ie. In the beginning there was no DOPs and users complained and Mark Tucker was sad and decided something must be done. So on the first day he created the SIM_Engine and all was good. However a SIM_Engine without objects was quite boring so on the second day Mark created SIM_Objects. Now the users were happy that they had dynamic objects to place in the engine but these SIM_Objects didn't do anything and users quickly became angry. So on the third day Mark implemented the SIM_Solver but the users were unable to use it because Edward broke the build and thus there was nothing to show for on the third day. On the fourth day Edward brought in donuts and Mark added the SIM_Force and now the users could have basic dynamics. On the fifth day the users discovered the RFE and Mark has not been seen since. Seriously though... some sort of overview/map would be helpful. Like take us through one time step of the simulation. First the SIM_Engine goes through all the SIM_Objects and checks the SIM_Data....etc etc. You had some wonderful nuggets in this thread here now we (I) want more. Quote Link to comment Share on other sites More sharing options...
Jason Posted August 11, 2005 Share Posted August 11, 2005 For a variation on this theme, has anyone considered implementing a solid 2D fluid solver in Houdini? I know there is the example Jos Stam 2D CFD code that gets distributed with Houdini now but I feel it'd be easy and very useful to add support for user-defined forces, boundaries and so on. I saw a number of sketches this year that show people using the 2D fluid solvers to add some surface displacement detail to bodies of water that aren't solved by 3D CFD solvers. Quote Link to comment Share on other sites More sharing options...
ivan Posted August 11, 2005 Share Posted August 11, 2005 sph is, like many particle type effects, cursed with a lumpy appearance in the hands of a non-visual technician. Real flow's demos were pretty laughable until the artists at the mill got it and cranked out some animations with good results. If I were going to look for the best particle animators on the globe, I would look in this forum. I understand your preference for eulerian solvers, you've certainly achieved incredibly good results with your research (you seem to have more of an artists eye than most of the other researchers) and there are clearly advantages to an eulerian approach, but there are also advantages to a lagrangian approach. I think that one of each might be best, and an SPH solver could be written as a group effort and refined very very quickly. I just thought it would be a good fit for an open source effort amoungst this group in particular. I have done both. It took me a week to get a basic SPH solver working. It would be great to use for any fluid that does not need pressure, but unfortunately SPH does a lousy job with pressure and there is currently no nice way to get surfaces that don't look like oatmeal. It's still good for some things especially considering that FX people seem to love particles and they can relate to SPH.If you want SPH I would suggest sticking with Real Flow. 20379[/snapback] Quote Link to comment Share on other sites More sharing options...
ivan Posted August 11, 2005 Share Posted August 11, 2005 almost forgot this one. It's a well layed out, easy to read java implementation of an eulerian solver. It's pretty strict to Stams stable fluids stuff. http://www.multires.caltech.edu/teaching/d...tablefluids.htm Quote Link to comment Share on other sites More sharing options...
Jason Posted August 11, 2005 Share Posted August 11, 2005 almost forgot this one.It's a well layed out, easy to read java implementation of an eulerian solver. It's pretty strict to Stams stable fluids stuff. http://www.multires.caltech.edu/teaching/d...tablefluids.htm 20453[/snapback] Nicely done, thanks. Quote Link to comment Share on other sites More sharing options...
Charlemagne Posted August 13, 2005 Share Posted August 13, 2005 Anyway, I don't have any current questions on your thesis, but I would be interested in your interpretation of the Moving Objects section of the Foster-Fedkiw practical animation of liquids paper. Section 9 leaves a lot to be desired. If you know of any better explanation of that anywhere that would be great.Mark Carlson 20293[/snapback] Yeah, I didn't like the way they treat moving objects either. There's a short description in my thesis of how I did it, section 4.1.3. I just used level sets for all obstacles, moving and stationary. Makes the inside/outside tests and velocity queries trivial. I think Fedkiw switched to some level set-based approach as well. Quote Link to comment Share on other sites More sharing options...
Slapdaddy Posted August 15, 2005 Share Posted August 15, 2005 You can also find an implimentation of Target Driven Smoke (one way to 'Key Frame' fluid) at http://www.cc.gatech.edu/~sarah/ http://www.cc.gatech.edu/~sarah/smoke.htm Quote Link to comment Share on other sites More sharing options...
n_t Posted August 20, 2005 Share Posted August 20, 2005 Hello, I'm working on the Blender-Fluid project that was mentioned before by Frank - so if anyone dares to try Blender and is interested in testing a beta version, I just posted some executables for linux and win32 here: http://wiki.blender.org/bin/view.pl/Blende...CFluidAnimation. There's also a small tutorial to get started with Blender and the fluidsim stuff... Enjoy, regards, -> Nils Btw. nice smoke java applet! Quote Link to comment Share on other sites More sharing options...
MADjestic Posted September 5, 2005 Share Posted September 5, 2005 Hello,I'm working on the Blender-Fluid project that was mentioned before by Frank - so if anyone dares to try Blender and is interested in testing a beta version, I just posted some executables for linux and win32 here: http://wiki.blender.org/bin/view.pl/Blende...CFluidAnimation. There's also a small tutorial to get started with Blender and the fluidsim stuff... Enjoy, regards, -> Nils Btw. nice smoke java applet! 20718[/snapback] Hey, n_t I've checked the stuff you've mentioned and should say that it kicks ass! Zuper! I've also read your thesis and it also rocks. I even can humbly suspect that I actually did understan it. Very thorough and math-background is nicely laid out. Great job! Do you mind if I try to play around a bit with it in connection with houdini? Of cource I don't meen commercial usage - for now I would be happy if it could be a mere attempt to understand it and make it work. Thanks Quote Link to comment Share on other sites More sharing options...
n_t Posted September 7, 2005 Share Posted September 7, 2005 Hi MADjestic, I'm glad to hear that! It would be great to have the fluid simulation in Houdini as well - I'm still quite busy with the Blender stuff, and not really familiar DOPs... but if you want to try and write an interface maybe I can still help a bit. Btw. I think the CVS access to the summer-of-code branches is still restricted, but it should be part of the main blender branch soon... -> Nils Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.