interface for it is still missing. Right now there is only a simple hard coded
example, that moves a single control particle with strong attraction
and velocity forces through the domain.
I added more detailed information about the control code to the wiki
http://wiki.blender.org/index.php/SoCFluidDevelDoc#The_Fluid-Control_Branch ,
together with some thoughts on how a Blender integration could be done.
compilation. Currently, it is not yet active by default, but
Genscher wanted to do some tests.
It can be used to distribute the computation load onto multiple shared-
memory CPUs by splitting the domain along the y-axis (assuming a
gravity force along z). However, there is no load balancing: so
if there's fluid only in one of the y-axis halves you will not get
a speedup for 2 CPUs.
- Added a fix for the memory allocation bugs #7120 and #6775. In
solver_init.cpp there are now several variables max___MemChunk
(line 692+), that set upper limits for various systems. The same
problem existed for mac & linux, but the limit is higher, so
it probably went by undetected. The windows limit is currently 1GB,
if the strange 700MB limit problems mentioned in the bug regports the
bugs persist, this could be further reduced. For 64bit compilations
this problem shouldn't exist anyway.
What's still missing is a display of how much the resolution was
reduced to fit into memory...
- And some minor solver code cleanup.
- removed warnings in attributes.cpp,
- and a first Klockwork bug fix: removed NULL returns in ntl_ray.h,
several other issues mentioned in the Klockwork report
are either hard to fix or not really errors...
#4742 exported normals are now correct
#4821 & 4956 for complex movements in/outflows can now also
use the animated mesh option
- new features
* isosurface subdivision: directly
creates a finer surface mesh from the simulation data.
this increases simulation time and harddisk usage, though, so
be careful - usually values of 2-4 should be enough.
* fluidsim particles: extended model for particle
simulation and generation. When isosurface subdivision is enabled,
the particles are now included in the surface generation,
giving a better impression of a single connected surface.
Note - the particles are only included in the final surface
mesh, so the preview surface shows none of the particle
effects.
* particle loading: different types of particles can now be selected for
display: drops, floats and tracers. This is a bit obsolete
due to the extensions mentioned above, but might still be useful.
Floats are just particles floating on the fluid surface, could
be used for e.g. foam.
* moving objects impact factor: this is another tweaking option,
as the handling of moving objects is still not conserving
mass. setting this to zero simply deletes the fluid, 1 is
the default, while larger values cause a stronger
impact. For tweaking the simulation: if fluid disappears, try
increasing this value, and if too much is appearing reduce it.
You can even use negative values for some strange results :)
- more code cleanup, e.g. removed config file writing in fluidsim.c,
added additional safety checks for particles & fluidsim domains (these
currently dont work together). I also removed the "build particles"
debug message in effects.c (seemed to be unnecessary?).
Some more info on the new features:
Here are two test animations showing the difference between
using the particle generation with isosurface subdivision.
This is how it would look with the old solver version:
http://www10.informatik.uni-erlangen.de/~sinithue/blender/fluid6_fl6manc4_1noparts.mpg
and this with the new one:
http://www10.informatik.uni-erlangen.de/~sinithue/blender/fluid6_fl6manc4_2wparts.mpg
Both simulations use a resolution of 64, however, the version with particles
takes significantly longer (almost twice as long).
The .blend file for a similar setup can be found here:
http://www10.informatik.uni-erlangen.de/~sinithue/blender/fluid6_testmanc4.blend
(Minor Tips for this file: dont enable subdivions of characters until rendering,
thus leave off for simulation, as it uses the rendering settings! For making
nice pictures switch on subdivion, and OSA.)
And here's a picture of old vs. new (for webpage or so):
http://www10.informatik.uni-erlangen.de/~sinithue/blender/fluid6_manc4compare.png
of the fluidsim can now be disabled with the
flag: BF_NO_ELBEEM='true', e.g. for irix systems.
(The number of ifdefs from the original
patch was reduced, and the defines are now
only necessary when elbeem is switched off.)
- particle generation option is available again
This should bring the projectfiles upto date for msvc7.
Moving these to version 7.1 so that the version 8 people don't have such a hard time importing into 2005.
Build intern.sln, extern.sln and then blender.sln. Enjoy. :p
variable blah at a higher scope is already defined...
(one of these was introduced by me when I moved a variable declaration
to the top of the function.)
Kent
Try to get the yy_wrap and yy_parse definitions for IRIX. Hoping
that it will also help Kent's multiply resolved warnings, I've done
this so that these symbols are defined only if they are currently
undefined. I'm not sure if it will work though, please test!
- Added part of Austin's msvc8 fixes (vector::erase function
was "misused"), hopefully compiles better now.
- Ctrl-b now also bakes a selected fluidsim domain
similar to the softbodies.
- Added surface smoothing option for domains: default is
1, higher values result in a smoother surface (and probably
slightly higher comupation times), while 0 means the surface
is not modified at all.
- Added BLENDER_ELBEEMBOBJABORT environment variable in readBobj,
if >0 quits blender when a not yet existing fluidsim
frame should be loaded. Useful for rendering simulations
as far as possible from the command line.
- Surface normals pointer is now set to NULL in readfile.c
- Fixed win32 error string handling, now uses a function
to return the string from the solver.
- Fixed fluidsim particle halo scaling problem.
- Solver update
no GE right now ( need to adapt to erwins file reshuffle
so may be i wait a bit until he has his mind made up )
elbeem is running when you remove the extra std:: at some places
well the msvc6 preprocessor is not very smart
--> std:: is not a member of std:: :)
so i guess there is a "using namespace std" somewhere
