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
Used the engine's RemoveScene (which ultimately calls the converter's RemoveScene) instead of the converter's RemoveScene when the converter free a blend file. This handles the scene removal in a safer fashion and solves the crash described in part 2 of the bug report. Part 1 no longer appears to cause a crash.
KX_BlenderSceneConverter's destructor freed the contents of several std::vectors without removing those contents from the vectors. Later these vectors are iterated through. Making sure the vectors get cleared solves this problem.
Was a missing NULL-pointer check. No idea why it took so long to figure
issue out -- apparently there was no crash in linux for me and msvc
didn't show any backtrace :S
Also corrected weirdo way of bit flag check which was:
!ma->mode & MA_FACETEXTURE
better do !(ma->mode & MA_FACETEXTURE) since ! is a logic NOT.
Root of the issue was fixed by Brecht in svn rev56441.
This change only prevents crash of files created in
blender before that fix, and also gives more useable
information about what's wrong (apparently, assert
here was doing nothing).
This bug was producing way more geometry than we need. Potentially
memory saver (or performance even) bugfix.
Bottomline is:
We need to initialize the UVs otherwise vertex comparison fails ...
Ideally MoTo should take care of initializing MT_Point2
(note in Windows that seems to be fine, but it's safer to not rely on that)
* Undoing the previous applyMovement() changes for characters. This was causing bugs for the Motion Actuator.
* Creating a Character Motion type for the Motion Actuator with specific controls for characters. This includes moving, rotating and jumping.
* Adding a KX_CharacterWrapper.walkDirection to set the character's direction and speed.
Note, this also resolves the following bugs:
[#33585] "Setting dLoc of motion actuator [0,0,0] via python won't stop object" reported by Manuel Bellersen (urfoex)
[#33503] "Character physics type won´t accept more than one motion anymore" reported by Mr Larodos
The object color option in the materials always worked, however the initial color of the object
was never passed to the game.
We are now passing it only, only when the object's mesh has a material that has ((shade_flags & OB_COLOR)).
There reason to not always set the object color is probably due to performance (the m_bUseObjectColor
flag in KX_GameObject). This patch still respect that.
Bug report from Mike Pan, as part of our book nitty-gritties review work.
Bugfix during Vancouver Global Game Jam :)
