| Age | Commit message (Collapse) | Author |
|---|
|
shapekey.
Title says pretty much everything, we now have BKE and RNA funcs to get vertex, poly and
loop normals of a given shapekey.
This will be used e.g. in FBX exporter (shapekeys need normal data too).
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D1510
|
|
|
|
Python had no ability to remove shape keys
Original D1169 from @lichtwerk, with edits
|
|
|
|
This is an old option which wasn't working in over a year without complaint.
|
|
used a basis by others.
Also fix stupid debug-only error in previous commit.
|
|
We are handling a keyblock here, not a whole key(set). Names are alreay a bit confusing,
let's be consistent at least.
|
|
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.
|
|
position.
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
|
|
|
|
|
|
had a typo too.
|
|
joining absolute shapekeys now sorts by time.
|
|
|
|
|
|
|
|
|
|
problem when using the function in lower level parts of the code, instead add add_keyblock_ctime() which sets time and sorts on absolute shape keys.
|
|
|
|
without the underscores these clogged up the namespace for autocompleation which was annoying.
|
|
|
|
http://markmail.org/message/fp7ozcywxum3ar7n
|
|
|
|
|
|
python functions.
- 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.
|
|
|
|
key->from.
- mode duplicate pointer/offset code into a static function.
|
|
flagged as PROP_THICK_WRAP.
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.
|
|
|
|
- Sculpting on the basis key should change original mesh
- For relative keys sculpting on basis key should update others
|
|
the Basis
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
|
|
msvc (though further work may be needed because changes made by the merge
|
|
|
|
|
|
- ensure new shape key names are unique
- Transfer ShapeKey now can have its settings changes (redo operator)
|
|
|
|
trunk/2.5 at r24811 I thought I'd committed but did not, yeek.
|
|
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).
|
|
|
|
|
|
renamed set_four_ipo -> key_curve_position_weights
renamed set_afgeleide_four_ipo -> key_curve_tangent_weights
added key_curve_normal_weights
|
|
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.
|
