Jump to content

Real Flow, Fluids, Dops, And Stuff


Guest xionmark

Recommended Posts

Guest xionmark
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

Link to comment
Share on other sites

  • Replies 47
  • Created
  • Last Reply

Top Posters In This Topic

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 :)

Link to comment
Share on other sites

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]

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Guest xionmark
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.

:ph34r:

--Mark

Link to comment
Share on other sites

unfortunately SPH does a lousy job with pressure and there is currently no nice way to get surfaces that don't look like oatmeal

If 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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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. :)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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]

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

  • 3 weeks later...
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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...