Linx Moving Objects Fluidsim Preview

[n_t]

Hello, here's the El'Beem christmas preview version
(Currently only for Linux, I hope I'll have time to make some other builds next year or so.)

http://www10.informatik.uni-erlangen.de ... 386.tar.gz

It has moving objects now as a new feature (simply animate loc/rot/size with ipos in Blender), and uses the internal API instead of the disk export - thus, it surely has a whole bunch of new bugs as well... Known problems:
- mass conservation isnt gurananteed with moving objects anymore
- meshes with high triangle numbers or extensive scaling animations may cause severe slow downs
- moving obstacles through each other (or the domain walls) can cause instabilities
- there are still some issues when the animation doesnt start at frame 1

Still, it should be fun to play with... Btw. animating the objects only works for obstacles& in- and outflow - for the others it doesnt really make sense.

There's also a new environment variable BLENDER_ELBEEMEXPORTONLY, that can be set to 1, to just write the config files to disk. These could e.g. be used with the command line tool, that I uploaded here: http://elbeem.sourceforge.net/ - however, that's still an older version that doesnt support moving objects. I plan to update the sourceforge files soon, though.

Have fun, let me know if you make some cool animation, merry christmas and so on,
-> Nils

Btw.: Here are two teaser animations of moving objects - the mixer test:
http://www10.informatik.uni-erlangen.de ... jmixer.mpg
and the suzanne shower:
http://www10.informatik.uni-erlangen.de ... shower.avi

[Caronte]

WWWWWOOOOOOOOWWWWWWWW!!!!!!!!!!!!!

Awesome!!

BTW: I can't see the avi

Edited:
I found the codec for windows here:
http://www.free-codecs.com/FFDShow_download.htm

[2d23d]

That's quite a present!
Thanx alot, love the solver. And I thought your work is done and now you come back with moving obstacles! Thanx again.

Had a look at your website, and have a question:
the bubble example, is that based on moving obstacles or something more complicated?
second one: would the solver be capable of mixing fluids? guess not... could it be tweaked? how far from thermodynamics is that hydrodynamics thing? (i've heard that with thermodynamics one can get a hold of energyexchanging-/mixing-behaviour) Well, have a nice Christmas...

[thetekmerc]

Is the elbeem code able to support the rendering of gasses or clouds, because I am thinking of ways to animate smoke in a volumetric way, like smoke rings. If elbeem can support this then I might as well wait for it to be included rather than spend a few months trying to work things out the hard way and then finding that it was not worth it.

[Koba]

Hi n_t!

First off the say great work on adding IPO collision interaction to the simulator! This is looking very fun!

My computing LBM project is long finished but I am still thinking about the LBM algorithm - especially how to improve it.

I'be been wondering if it is possible to do arbitarily large resolution simulation in finite memory and have come to the conclusion that it in general not possible. However, this thinking has led me to another suggestion on how to improve the simulation.

Disclaimer: I am no computer scientist or programmer - I'm just working from what I know of the algorithm. This is probably highly inefficient but hey..I'm just trying to help here.

It seems clear to me that in the end, it is the isosurface generated by the algorithm that matters most - after all this is what we finally render. Another thing that strikes me is that in high resolution simulations (and often what visually makes high resolution simulations more impressive) is the fine spray generated. Here is what I propose...

Instead of storing the distribution functions of every cell in every isolated drop of spray, how about assuming that sufficiently small droplets are unlikely to break apart (due to effects such as surface tension for example) and therefore internal structure is unimportant - the droplet simply obeys Newton's laws of motion. This means that each isolated droplet surface could simply be assigned a global vector defining its motion. Then instead of storing that drops internal distribution functions in its cells between time steps, they could be recalculated each time from the single vector associated in that closed isosurface. This would mean isosurface data need to be stored..but this is the case anyway as we generate a mesh to visualise the isosurface.

Essentially what I am proposing is that the algorithm search for closed isosurfaces of a certain defined size and if it finds such a surface, the isosurface is tagged in some way, the average vector of its contents computed and assigned to that isosurface allowing the fluid cells inside to become void cells and hence release data (and hence memory). From then on that isosurface is have its future extrapolated from the vector data.

This is just an idea and I realise that for simulation without small droplets it would be completely useless. However, if there is a lot of fine spray then many cells could have their data summarised by these vectors - think about it - drop radius*drop radius*drop radius*19*2 doubles could be released per drop (and there could be thousands of droplets) using this method. It requires a minimum number of cells to generate a closed isosurface in the first place (or so I suspect) so there will be savings even for the smallest drops. If the user is allowed to specify the maximum drop size at which this method is used, there could be substantial memory savings (I hope ! ).

So in conclusion - there is this idea in my head which makes me inclined to believe that there could be memory saved for high resolution simulations with lots of fine droplets that don't collide too often.

Thanks for listening!

Koba

[toomuchcookies]

Hi,

did the code make into the release??

thnx.

[raygun11]

I can`t see these movies, FFDshow doesn`t help.

[raygun11]

I can`t see these movies, FFDshow doesn`t help.

[ZanQdo]

Hi,

did the code make into the release??

thnx.

no, it´s a work in progress as he said.

[jedrzej_s]

I can`t see these movies, FFDshow doesn`t help.

I have this same trouble .

[jedrzej_s]

I can`t see these movies, FFDshow doesn`t help.

I have same trouble .

[n_t]

koba: you're right - for large splashes it will be impossible to resolve every small drop in the grid. I'm currently working on something a bit similar to what you proposed, basically using particles to model small unresolved drops and bubbles. The problem is that you still have to store a grid to perform the actual simulation, and the larger drops you thought of might hit each other or some part of the fluid anywhere. So for now it won't really reduce memory - the adaptive grids that are implemented could be used to reduce the memory requirements (using adaptive patches that are connected by some tree structure), but it's tricky to implement efficiently...

raygun11, jedrzej_s: strange, with mplayer the movies work fine - I uploaded another version of the second one that might work:
http://www10.informatik.uni-erlangen.de ... shower.mpg

toomuchcookies: no

Btw.: Just as a warning - there's a problem with directories, they shouldnt contain a "+" as e.g. the default 2.4 installation path on Macs does. I also added a note to the wiki:
http://mediawiki.blender.org/index.php/ ... Simulation

[Koba]

Hi!

I was about to add the suggestion that drops below a certain size could have a probability of splitting - with vectors based around the velocity of the drop before the split (these drops would have to be stored outside the simulation grid).Because they are smaller, their physical and toplogy evolution could be correspondingly simpler (a single isosurface could be stored representing the drop after the split and this mesh could simply fall under gravity). Essentially, as you said, some clever particle system would do the trick.

Unfortunately, that suggestion was to be appended to a post made on the day that blender.org was having problems (2.40 release!) and I ended up quintuple-posting by accident - hence I left the post as it was.

Apart from that, I am glad to see that you are working on creating the *illusion* of a higher res simulation than actually present. I also saw some people on cgtalk (who are skeptical about Blender) using your work to create fluid dynamics for lightwave/xsi! They seemed pretty impressed!

Keep up the good work.

Koba

[jedrzej_s]

raygun11, jedrzej_s: strange, with mplayer the movies work fine - I uploaded another version of the second one that might work:
http://www10.informatik.uni-erlangen.de ... shower.mpg

THX !!! This version is worked !!! Good work !!!

Happy New Year !

[Dani]

Hello n_t!

(and happy new year!)

Here are two or three things I've been thinking of about ElBeem:

I think I've read around the .org website or the mailing list that one improvement of the renderer would be vector based motion blur. This could solve the problem of no-mblur for fluids. (but you would have to store velocity vectors per vertex I suppose during the simulation, how much work is that and does it need much more memory?)
Hey, having these velocity vectors accessible through python could be extremely interesting! (I'm thinking out loud here)

Have you had a look at harry potter 4? it features a scene where a whole boat (a caravel) comes out of a lake's surface with slpashes and everything. I then thought that for some effects you don't need water preservation of the reservoir, like a lake or the ocean. you just need a surface to represent it. Then when there is interaction between moving obstacles and this surface, the calculations would be easier? How wrong am I? It could be very helpful userwise too.

another last thing that I've thought of while using the simulator is that manually editing the resulting mesh (even though it's HEAVY) could be a good way to solve small leaks and things like that (instead of re-running the simulator at a higher resolution). The hi-rez file could be loaded into Blender when entering edimode and dumped back to disk when exiting editmode. The only problem I see it how to make this work with the undo system?

Well, I think that's all! As Koba, I'm not very good with maths or programming, but I thought I could share these thoughts!

Take care!
Dani