Page 1 of 2

SoC project : Fluid Linux/Windows (2005/08/29)

Posted: Mon Aug 29, 2005 6:56 pm
by lguillaume
Hello, there is some update for thi projects :
Log:
solver changes:
- redid gravity init
- added memory saving strategy (mem-usage reduced to ca. 50%)
- some more cleanup
- removed dynamic casts for MSVC compiler
blender side:
- fixed no-obj. bug
- modified resolution limits for GUI and export

- minor fixes for MSVC: removed unused header and last dynamic_casts
My compilation for windows:
in zip(2256kB)
in 7zip(1728kB)

KidB compilation for Linux : download

I found my compilation slower than the previous release, but I'm not sure if anyone can confirm.

Posted: Mon Aug 29, 2005 7:43 pm
by RRuiz
Compared with the last compilation it is a little bit slower but also the result is diferent.

Old = 231.587 seg. on 10 frames.
Image

New = 249.247 seg. on 10 frames.
Image

I realy like more the result on the new one.

Un Saludo

Re: SoC project : Fluid Linux/Windows (2005/08/29)

Posted: Mon Aug 29, 2005 7:50 pm
by kidb
lguillaume wrote: KidB compilation for Linux : download
x86_64 only (AMD64)

Posted: Tue Aug 30, 2005 2:11 pm
by n_t
Interesting, the updated version should actually be a tiny bit faster and use half as much memory as before... Once all the basic features work I'll have to do some benchmarking. Are you perhaps comparing a GCC and a MSVC version, where gcc compiler does a better job with optimizations...?

Posted: Tue Aug 30, 2005 10:00 pm
by Zsolt
The same for me too: it is slower than the previous build.
Another thing: why has the resolution been limited to 200? I admit higher values take a long time/might crash slower computers, but sometimes a nice animation is worth a long wait, now we don't have that option any more. Maybe you could include a warning on the button, or on its side, that values over 200 aren't recommended.

Posted: Wed Aug 31, 2005 12:09 am
by Smb
Zsolt wrote: Another thing: why has the resolution been limited to 200? I admit higher values take a long time/might crash slower computers, but sometimes a nice animation is worth a long wait, now we don't have that option any more. Maybe you could include a warning on the button, or on its side, that values over 200 aren't recommended.
quote for agreement ;)

Posted: Thu Sep 01, 2005 5:36 am
by Merlot
The links seem to not work?? (for the compiled win files)

It's only been three days... or is it just me?

Posted: Thu Sep 01, 2005 11:05 am
by Smb
It's just you... :D

Posted: Thu Sep 01, 2005 12:47 pm
by n_t
Smb,Zsolt: the problem with large resoltuions is the memory usage, there were people with 512MB that tried to do 400^3 simulations (that's more than you can allocate on a 32bit machine), so I decided to restrict the resolution to what should fit into 1GB without problems. I'm looking into ways to determine how much free memory there is right now to fix this...

Btw.: I just added a second tutorial yesterday.

Posted: Thu Sep 01, 2005 3:20 pm
by Pablosbrain
I'd say just display an estimated required amount of memory for the calculation to succeed. Then leave it up to the user to decide if they want to try it or not. If they want to try using a hammer to eat cereal thats their choice. May not be a good or functional one... but their choice. :)

Posted: Fri Sep 02, 2005 4:54 pm
by Zsolt
n_t: how about the option to set the resolution along each of the axes?
IE: you might have a long, thin domain, where you want the water to flow, then you could have 400 "cells" (or what are they called?) along the length, and 100, 100 along the side and the height. Therefore saving memory, and optimizing the cells to be cube shaped. Not sure whether this could be implemented or how...

Posted: Fri Sep 02, 2005 10:48 pm
by Koba
Seconded. I was going to ask the same question at the same point.

In many situations it would be useful to have a large but shallow domain to simulate rain falling on puddles, rivers for example. The resulting splashes normally rise only a tiny fraction of the other two dimensions (for small drops at least).

Anyway, as far as I know there is nothing in the algorithm that prevents non-cubic domains but then n_t is the one who decides what is and isn't possible.

One last question though, when will the fluid sim be able to interact with keyframed objects and will it be possible for objects marked as fluid (for sake of argument) initially outside the domain at the start of the bake "join" the simulation in the marked domain if they move into it at some later frame?

Koba

Posted: Sat Sep 03, 2005 2:32 am
by Rahu
Could someone explain how this works to me? I make a large gube, and set it as the domain, I make a small platform for trhe water to land on, and set it as an obstacle, then I make a small cube above the obstacle, and make it fluid, leaving all the settings at thei default value. I press bake, and assume it is calculating(I get the little frame rendering cursor thingy) Aftyer that nothing happens, and I do not notice any difference :/

Posted: Sat Sep 03, 2005 4:28 pm
by Zsolt
Rahu: switch to wireframe view, as in solid view the original objects might cover the fluid object. What should happen is the domain object becomes the fluid that is animated. Try Alt-A to see the animation.

Posted: Sat Sep 03, 2005 4:46 pm
by poutsa
TIP1:

For better Preview in 3D Window of your Fluid Object you can make it Transparent (Looks like Water)! Click on Transparent button (F7 Buttons) and in the Material Buttons set the Alpha Value to 400 some more Spec and Emit and give a Blue Colour!!

TIP2:

If you use for your Domain Object Final for Preview in 3D Window and the Animation is to Slow (if you Press Alt +A in 3D Window)....you can speed up by Pressing the Sync Button in the Anim Panel ...also by changing the framerate Frs/sec:25

Vassilios Boucer