Page 2 of 4

Posted: Mon Jan 02, 2006 9:37 pm
by LetterRip

the fluid sim creates a seperate object for each frame currently the vectors he would need to store would be per voxel, not per vertex...

Basically the way the fluid sim is currently implemented I don't think any of your ideas can work...


Posted: Tue Jan 03, 2006 1:39 pm
by Dani

okay, I hadn't understood how the algorithm works, though I had understood that there was one mesh per frame.
However, once everything is calculated, maybe idea 3 could still be valid?


Posted: Wed Jan 04, 2006 10:33 pm
by n_t
Koba: I also saw the Lightwave export thread on cgtalk - it's pretty cool :). I also learned that it's not legal to create a GPL'd plugin for a non-GPL'd program, so thats probably going to be the only way for a while...

Dani: Point 1) I actually thought along the same lines - you could store per vertex velocities (interpolated from the voxel grid) with the fluid mesh and use those to create image based motion blur... if there was an image-based motion blur feature :). 2) I also saw the HP4 movie and was amazed by the ship scene - I'll have to try and do something like that with elbeem&blender. 3) Manually editing the meshes would be possible, i have a mesh loading script here: ...
and maybe I still have the export script somewhere. But it's probably pretty tedious work...

Posted: Thu Jan 05, 2006 12:47 am
by Koba
As Koba, I'm not very good with maths or programming, but I thought I could share these thoughts!
Did I say that? What do you mean? I'm doing physics degree at Oxford University for heaven's sake! are completely right, I am rubbish at maths :D . When asked to derive the temperature distribution of an infinite (as always) cylindrical rod with the thermal diffusion equation I go :shock:

Anyway, enough of that.

Why would you need to use the vectors from the voxel grid? After all, blender can only render surfaces and motion blur means nothing to an invisible volume. Wouldn't it be easier to interpolate the vectors by considering the change in the surface configuration between frames? Of course you might need to make some assumptions about the continuity of the surface and how points on the different surfaces map to each other but I would imagine it is possible. Of course using the boundary cell velocities might end up being easier - the point is I don't feel motion blur should really involve the fluid simulator - it seems a little messy (but that is just my opinion).

Vector motion blur is something that has been discussed before and would be a real nice addition to Blender. Perhaps it will be added over the course of project Orange but I wouldn't get my hopes up.

Finally, one last question for n_t - do you know of any practical algorithms for mixing fluids of different visual properties? Something like red wine mixing with water perhap?. It just seems a fiendishly difficult thing to do - you would need first need a volumetric rendering system and then you would need to calculate the shading properties of each voxel taking into account diffusion etc. Are there any commercial apps that can do this?

I suppose it could be done with LBM alogorithm by splitting the DFs into two components to distinguish the fluids and so allowing an interpolation of the shading properties. Of course this would be for two fluids mixing only - more would materials would pose an even greater nightmare.

It doesn't bear thinking about.


Posted: Thu Jan 05, 2006 3:32 am
by IanCalvert
Koba, I think he meant "Ask Koba, I'm not very good..."


N_t, this is incredible, thanks so much.


Posted: Thu Jan 05, 2006 1:19 pm
by rcas
n_t wrote:Koba: I also saw the Lightwave export thread on cgtalk - it's pretty cool :). I also learned that it's not legal to create a GPL'd plugin for a non-GPL'd program, so thats probably going to be the only way for a while...
You can use LGPL for that.

There are ways to get GPL to work with Commercial applications, you just need to Google a bit and read some stuff.
There are ways to use Libraries or scripts or even mixing LGPL with GPL.

All in all, you need some reading on the subject first and it doesn't work the same way in all cases, so it has to be related to your specific work.

-- Rui --

Posted: Thu Jan 05, 2006 1:38 pm
by Dani
Hi n_t!

thanks for your answer! I'll be trying the import script within the day, and as for the export script, I might as well try to code it in python (the only computer language I know)

Hey Koba: I meant no offense! sorry!

Anyway, this is already a great tool for many many applications!
keep it up!

Posted: Thu Jan 05, 2006 2:23 pm
by Koba
Hey Koba: I meant no offense! sorry!
I was only joking. No offence taken. :D


Posted: Thu Jan 05, 2006 7:03 pm
by Dani
I was only joking. No offence taken.
no problem then ;)


Posted: Thu Jan 12, 2006 4:04 pm
by n_t
Here's win32 version of the moving objects promised ages ago: ...

Please let me know if it works, or doesnt...

Koba: Mixing fluids meaning volumetric objects are probably hard to render (the PBRT book has some nices chapters on it), but the simulation should not be that hard - you can basically treat both as having the same properties, and add a coupled advection/diffusion solver to it based on the fluidsim velocities. If you want to have fluids with different properties, like oil & water, thats much harder - like you said, you need a separate grid for each one, and treat the interface interactions...

Posted: Thu Jan 12, 2006 5:58 pm
by lucky3
Thanks, thank you so much n_t for the window build!
I'm gonna check it out.

After a quick test with fluid in a moving glass (thanks to bullet for baking rigid bodies ;) , i've noticed there was less liquid at the end in the glass than at the 1st frame.

Is that what you mean with " mass conversion is not guaranted with moving objects"? :? Is there a way to avoid it? (higher resolution...)

Posted: Thu Jan 12, 2006 6:47 pm
by nozzy
n_t wrote:Here's win32 version of the moving objects promised ages

Please let me know if it works, or doesnt...
This test went a bit funky on the last 6 frames.
But otherwise really sweet, great work.


And heres the blend: stamp.blend
And for those who are interested heres a quicktime of the part that did work :)


Posted: Fri Jan 13, 2006 3:35 am
by Money_YaY!
is there a patch file ?? I can try and make an osx version

Posted: Fri Jan 13, 2006 5:06 pm
by n_t
nozzy: looks like an instability, the moving objects are more critical with respect to stability...

lucky3: yes, fluid in a moving glass is something like a worst case. Higher resolution or slower movement might work better, but i'll probably just have to implement some more stuff to get that right...

Money_YaY!: I finally setup a mac here and tried to build a mac version, here it is (Python2.4): ... mac.tar.gz
I'm not sure how works together with the different OSX versions, though...

Dynamic Domain Res?

Posted: Fri Jan 13, 2006 11:38 pm
by MrWonka
Hi n_t,

I love the new functionality. It's fantastic. At the moment I'm just finding out what happens if you fire a pellet at a large tank of water.

I don't pretend to know anything about fluid algorithms but I was just thinking, would it be possible to do a dynamic domain size/resolution calculations based on the movement of 'liquid'. For instance, a splash causes a large spike of water to be fired into the air, could the domain expand to calculate it's path and shrink as it falls?

Can the algorithm do dynamic resolution? Similar to the technique the radiosity solution in blender uses. It adds more resolution to the areas that need it, i.e. corners, increasing the overall accuracy without spending resources on other areas.

Something like this would be useful when, for instance, producing an animation of a boat in an ocean. You would need high res around the boat to make realistic wake, yet futher away you could get away with a basic impression of the wake.

Keep up the excellent, excellent work.

Mr Wonka