| Age | Commit message (Collapse) | Author |
|---|
|
Also deduplicated the 'mesh as shapekey' code, we had kind of two funcs
doing the same thing here...
|
|
|
|
This will allow much finer controll over how we copy data-blocks, from
full copy in Main database, to "lighter" ones (out of Main, inside an
already allocated datablock, etc.).
This commit also transfers a llot of what was previously handled by
per-ID-type custom code to generic ID handling code in BKE_library.
Hopefully will avoid in future inconsistencies and missing bits we had
all over the codebase in the past.
It also adds missing copying handling for a few types, most notably
Scene (which where using a fully customized handling previously).
Note that the type of allocation used during copying (regular in Main,
allocated but outside of Main, or not allocated by ID handling code at
all) is stored in ID's, which allows to handle them correctly when
freeing. This needs to be taken care of with caution when doing 'weird'
unusual things with ID copying and/or allocation!
As a final note, while rather noisy, this commit will hopefully not
break too much existing branches, old 'API' has been kept for the main
part, as a wrapper around new code. Cleaning it up will happen later.
Design task : T51804
Phab Diff: D2714
|
|
Noisy change, but safe, and better do it sooner than later if we are to
rework copying code. Also, previous commit shows this *is* useful to
catch some mistakes.
|
|
This function was only a wrapper around id_clear_lib_data(), and shapekeys
are not linkable nor shareable anyway, no point keeping this currently,
was only adding confusion about shapekey 'status' as a datatblock.
|
|
used locally.
Will be used by link/append code.
|
|
Also allows us to get rid of a few _copy_ex() versions...
|
|
|
|
Mostly pass bmain and do not check for NULL key, keys' make_local is
suspiciously simple in fact, but think until those behave like real
full-featured IDs, it's doing enough!
|
|
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.
|
|
|
