Thing is, those functions always reallocate the whole keyblock's data mem,
while in some cases we already have right amount of elements, so we can just
copy over. Further more, `BKE_key_convert_from_offset`, despite its name,
was not making any check nor allocation on keyblock's data elements!
So split 'copy' operation itself in `BKE_key_update_from_...`,
where no mem checks/operations are performed (only an assert).
Only useful in sculpt mode currently, but will be used by fix for T35170 too.
Main moving logic is moved to new `BKE_keyblock_move()`, which makes it available from anywhere.
In addition, move code was reworked so that it only loops once on whole keyblocks list,
and it accepts arbitrary org and dest indices, not only neighbor ones.
Partly based on work by revzin (Grigory Revzin) in his soc-2014-shapekey GSoC branch, thanks!
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
- use NULL rather then 0 where possible (makes code & function calls more readable IMHO).
- set static variables and functions (exposed some unused vars/funcs).
- use func(void) rather then func() for definitions.
Also use const char in many other parts of blenders code.
Currently this gives warnings for setting operator id, label and description since these are an exception and allocated beforehand.
PBVH used the same verts array as mesh data and shape key/reference key coords
were applying on the mesh data, so on some refreshing undeformed mesh was
displayed.
Added utility functions to get vert coords from key block, apply new vert coords
on keyblock and function to apply coords on bpvh, so now pbvh uses it's ovn
vertex array and no changes are making to the mesh data.
Additional change:
Store key block name in SculptUndoNode, so now shape wouldn't be copied to
wrong keyblock on undo
Rather than applying the modifier to the object data, it will create a new shape
with the deformed vertices in there. Only mesh at the moment, other object
types on the todo.
Blended shape keys can now be displayed & edited in edit mode. This
is much like showing an armature modifier in edit mode, and shape keys
now are a applied as a virtual modifier (for mesh & lattice only, curve
doesn't fit in the stack well due to tilt).
The main thing missing still is being able to switch between the active
shape key in edit mode, that's more complicated.. but the weights of
other shapes can be edited while in edit mode.
One thing to be careful about is that this does automatic crazyspace
correction, which means that if you edit a shape key with a low value,
the actual vertices will be moved to correct for that and actually move
a (potentially much) longer distance.
Also includes some UI tweaks, mainly placing some buttons horizontally
since the vertical list was getting too long.
Internal change to not apply the shape keys to the Mesh vertex coordinates,
but rather use it as part of the derivedmesh/displist evaluation. This only
has one practical advantage right now, which is that you can now make a
linked duplicate and pin it's shape key to a different shape than the first
object.
Further, this makes shape keys correctly fit into the modifier stack design,
which will help implement some other features later. Also it means the mesh
vertex coordinates are now really the orco's.
Special priority request from Durian team to get this sub-editor of the DopeSheet Editor restored. Originally I was kindof planning to drop it, but obviously it still has a role!
It now supports all the modern features that the DopeSheet supports, complete with selection, muting, locking, DopeSheet summary, and all the other tools that you know and love from the other views.
Also, this no longer uses the old hacky sliders that 2.4x used (instead it uses RNA-based ones), so should function just the same as other DopeSheet views).
Think global, act local!
The old favorite G.scene gone! Man... that took almost 2 days.
Also removed G.curscreen and G.edbo.
Not everything could get solved; here's some notes.
- modifiers now store current scene in ModifierData. This is not
meant for permanent, but it can probably stick there until we
cleaned the anim system and depsgraph to cope better with
timing issues.
- Game engine G.scene should become an argument for staring it.
Didn't solve this yet.
- Texture nodes should get scene cfra, but the current implementation
is too tightly wrapped to do it easily.
Merged 'backend' changes from AnimSys2. Many of these changes are necessary for the Dopesheet and other changes I'm currently still stabilising. Those will come in due course.
Shape Action are now supported in the BGE. A new type of actuator "Shape Action" is available on mesh objects. It can be combined with Action actuator on parent armature. Only relative keys are supported. All the usual action options are available: type, blending, priority, Python API. Only actions with shape channels should be specified of course, otherwise the actuator has no effect. Shape action will still work after a mesh replacement provided that the new mesh has compatible shape keys.
User doc: http://www.blender3d.org/cms/Shape_Keys.678.0.html
- The mixed use of "Vertex Key","Key" or "RVK" in Blender was a bit
confusing. Also a 'vertex key' assumes keys per vertex, which actually is
only a single key for the entire shape. The discussions on blender.org
forums all mentioned "Shape" or "Blend Shapes", which I think is an OK
name for a "Vertex Key" in the UI. :)
- Most work was code spaghetti cleanup. Doing shape-keys now nicely goes
via the depgraph and DerivedMesh. That then allows to have different
shapes per object, with the new "Pin" feature.
Objects now define what Shape is shown (ob->shapenr)
- Added a Shape Panel in the Edit buttons with the various options
- Fixed a lot of issues in the IpoWindow, with drawing the channels.
For example, deleting a key-line there caused the entire Relative option to
go wrong, same for moving the lines up/down.
Changing key-line order now reflects in order of channels. The active
Shape is drawn more clear now too.
- Noticed it doesnt work yet for curves/lattice. Need modifier advise!
