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...?
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.
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.
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...
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.
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...
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?
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 :/
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.
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
Last edited by poutsa on Tue Sep 06, 2005 2:11 pm, edited 1 time in total.
