I did a very drastic cleanup for the different libgroups, there's now only a few left. It compiled with scons/msvc, will be testing in a bit on linux, too.
If you get any problems, please reply to this commit message on the taskforce ML.
to compile blender with gcc on IRIX, IRIX_USE_GCC needs to be set to true in
user-def.mk.
Other changes related to irix:
* compile solid from extern/
* don't build plugins (yet) with "make release" when using gcc (the shell
script used assumes MIPSpro is installed)
* use statvfs instead of statfs on irix, like done on solaris
* use external libs from $(LCGDIR) instead of /usr/freeware
* use glew header files from $(LCGDIR)/glew instead of the ones installed on
the system (this applies to other platforms as well)
* ffmpeg support currently is disabled on irix
I changed sqrtf to sqrt in elbeem
in bullet2 I added defines found in floatpatch.h eventually
we should make a "floatpatch.h" that all of blender can use.
Kent
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.
