This commit fixes two different issues, which were caused by
how weights are being calculated for relative shapekeys.
Weights for key block used to saved in KeyBlock DNA structure,
which lead to situations when different objects could start
writing to the same weights array if they're sharing the same
key datablock.
Solved this in a way so weights are never stored in KeyBlock
and being passed to shapekeys routines as an array of pointers.
This way weights are still computed run-time (meaning they're
calculated before shapekey evaluation and freed afterwards).
This required some changes to GameEngine as well, to make it
never cache weights in the key blocks.
Another aspect of this commit makes it so weight for a given
vertex group is only computed once. So if multiple key blocks
are using the same influence vertex group, they'll share the
same exact weights array. This gave around 1.7x speedup in
test chinchilla file which is close enough to if we've been
caching weights permanently in DNA (test machine is dual-code
4 threads laptop, speedup measured in depsgraph_mt branch,
trunk might be not so much high speedup).
Some further speed is optimization possible, but it could be
done later as well.
Thanks Brecht for idea of how the things might be solved in
really clear way.
--
svn merge -r58786:58787 ^/branches/soc-2013-depsgraph_mt
Shapekey drivers were executed for every call to derivedmesh, which shouldn't happen.
It now only runs on the object_update() function, once for every depsgraph change.
Error was found while testing preview render in viewport. On each render, the
animsys sent a 'changed data' because of the shapekey drivers being called,
causing eternal re-render loops (without showing anything).
from Lawrence D'Oliveiro (ldo)
notes from tracker:
use bool for return type from BLI_remlink_safe, necessitating including BLI_utildefines.h in BLI_listbase.h
get rid of duplicate BLI_insertlink, use BLI_insertlinkafter instead.
A few places which were using BLI_insertlinkafter (actually BLI_insertlink), when it would be simpler to use BLI_insertlinkbefore instead.
Change Scene.frame_set so that it ensures subframe in range [0,1[ as Blender
expects, otherwise some things like physics point cache lookups don't get
evaluated properly.
* Motion blur with shutter time > 1 did result in the correct evaluation
of some modifiers because it set the subframe to values > 1, and some
places assume the current frame to be set to the integer coordinate and
the subframe to be a value between 0 and 1.
* Shape keys did not take subframe time offsets into account.
* Point density texture was using an current frame value that was never set.
- Make sure functions are named in way BKE_<object>_<action> (same way as RNA callbacks)
- Make functions which are used by mball.c only static and remove their prototypes
from public header file.
Further cleanup is coming.
This report points out thet absolute shape keys are unusable.
The problem is there was no way to adjust the play time of a shape key (all absolte shape keys would start at frame zero with no way to change the speed).
Added an 'eval_time' property to the key block that works like the curve path evaluation time, so the time in the keyblock can be controlled.
