| Age | Commit message (Collapse) | Author |
|---|
|
first 3 frames
|
|
|
|
https://svn.blender.org/svnroot/bf-blender/trunk/blender
|
|
with >4GB is verified to work on Vista64.
|
|
|
|
|
|
|
|
|
|
|
|
simulation and control time desync
|
|
issues to solve but with 1 change in fluidsim.c it kind of works already (hint for me - disabled for other people so they don't complain)
|
|
|
|
https://svn.blender.org/svnroot/bf-blender/trunk/blender
|
|
remove the problematic normalize() call
|
|
in normalizing a vector to fail, reverted other change from today
|
|
popping/inconsistency/flickering issue with fluids, please give feedback :)
|
|
blocks that were previously missed; and b) greatly increase my
ohloh stats!
|
|
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.
|
|
|
|
them leaving 'only' the original OpenMP additions from N_T
|
|
|
|
correct
|
|
|
|
#include <ieeefp.h>
Kent
|
|
64bit architecture
|
|
|
|
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.
|
|
Some more compiler warning fixes. Some of these seem to be specific to GCC 4.1
|
|
Fixing warnings: conversion from string constant to char *
This should make gcc 4.1.x a little happier.
|
|
More fix to solaris build, patch by Vladimar Marek
|
|
All small patches submitted by Vladimar Marek (neuron)
Basically fixes up some headers for Solaris's compiler.
Kent
|
|
- 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...
|
|
different platforms will follow soon. This was just tested against current CVS on MSVC 2005 with Verse, QuickTime, OpenEXR, Player all on.
|
|
|
|
|
|
|
|
#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
|
|
- slightly improved and optimized
handling of moving obstacles
- cleanup of debug messages and minor fixes
|
|
there was a wrong divisor for memory estimate
|
|
and to prevent surface flickering near obstacle sides
|
|
obstacle fluid surface generation bug
- also contains some code clean ups
and safer initializations
|
|
(surface mesh structs werent handled correctly,
copying is now done in a new function)
|
|
- added more std::string fixes from bjornmose
|
|
|
|
i'll give it to nils later on
|
|
- removed some more debug output in the solver
|
|
works for non closed objects), volume ("normal"/old way of
doing it), and a combination of both:
http://www10.informatik.uni-erlangen.de/~sinithue/blender/voltcomp_sm.jpg
- Finally included bjornmose MSVC6 fixes
- Added support for animated meshes, e.g. meshes with
parented skeletons. Is enabled for obstacles with a new button.
A simple example with Bassam's mancandy can be found here:
http://www10.informatik.uni-erlangen.de/~sinithue/blender/fluid2_mancandy.mpg
http://www10.informatik.uni-erlangen.de/~sinithue/blender/fluid2_mancandy.blend
(Warning - keep meshes as simple as possible, e.g. turn off subsurf
for baking. Export probably shoulb be further optimized.)
- Changed handling of no/free/part slip obstacles, see:
http://www10.informatik.uni-erlangen.de/~sinithue/blender/bndtcomp_sm.jpg
- Removed surface particle option for upcoming release,
needs more testing & tweaking
- Added tracer particles instead (swimming along in the fluid)
- Updated wiki (description of IPOs still missing).
|
|
removing dead files in el'beem however the "std::std::string" problem is still there
still no GE
|
|
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
|
