archive/blender-archive
Archived
1
1
Fork 0
Code Pull Requests Packages Activity
This repository has been archived on 2023-10-09. You can view files and clone it, but cannot push or open issues or pull requests.
Files
ee688e24a766d1352d9eac5b22113b118c227ceb
blender-archive/source/blender/blenkernel/BKE_key.h

123 lines
4.9 KiB
C++
Raw Normal View History

doxygen: blenkernel under core as module.
2011-02-18 13:05:18 +00:00
/*
Patch from GSR that a) fixes a whole bunch of GPL/BL license blocks that were previously missed; and b) greatly increase my ohloh stats!
2008-04-16 22:40:48 +00:00
* ***** BEGIN GPL LICENSE BLOCK *****
Initial revision
2002-10-12 11:37:38 +00:00
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version 2
Patch from GSR that a) fixes a whole bunch of GPL/BL license blocks that were previously missed; and b) greatly increase my ohloh stats!
2008-04-16 22:40:48 +00:00
* of the License, or (at your option) any later version.
Initial revision
2002-10-12 11:37:38 +00:00
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software Foundation,
correct fsf address
2010-02-12 13:34:04 +00:00
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
Initial revision
2002-10-12 11:37:38 +00:00
*
* The Original Code is Copyright (C) 2001-2002 by NaN Holding BV.
* All rights reserved.
*
* The Original Code is: all of this file.
*
* Contributor(s): none yet.
*
Patch from GSR that a) fixes a whole bunch of GPL/BL license blocks that were previously missed; and b) greatly increase my ohloh stats!
2008-04-16 22:40:48 +00:00
* ***** END GPL LICENSE BLOCK *****
Initial revision
2002-10-12 11:37:38 +00:00
*/
unify include guard defines, __$FILENAME__ without the underscores these clogged up the namespace for autocompleation which was annoying.
2012-02-17 18:59:41 +00:00
#ifndef __BKE_KEY_H__
#define __BKE_KEY_H__
Initial revision
2002-10-12 11:37:38 +00:00
doxygen: blenkernel under core as module.
2011-02-18 13:05:18 +00:00
/** \file BKE_key.h
* \ingroup bke
* \since March 2001
* \author nzc
*/
Initial revision
2002-10-12 11:37:38 +00:00
struct Key;
struct KeyBlock;
struct ID;
struct ListBase;
struct Curve;
struct Object;
struct Lattice;
struct Mesh;
Optimization and threading fix for shapekeys weights calculation 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
2013-08-19 10:36:39 +00:00
struct WeightsArrayCache;
Initial revision
2002-10-12 11:37:38 +00:00
BGE Patch: Add Shape Action support and update MSCV_7 project file for glew. 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.
2008-06-18 06:46:49 +00:00
/* Kernel prototypes */
#ifdef __cplusplus
extern "C" {
#endif
code cleanup: make shape key api names consistent with our new convention.
2012-09-19 10:12:07 +00:00
void BKE_key_free(struct Key *sc);
void BKE_key_free_nolib(struct Key *key);
struct Key *BKE_key_add(struct ID *id);
code cleanup: function naming, use BKE_*type* prefix.
2012-05-05 14:03:12 +00:00
struct Key *BKE_key_copy(struct Key *key);
code cleanup: make shape key api names consistent with our new convention.
2012-09-19 10:12:07 +00:00
struct Key *BKE_key_copy_nolib(struct Key *key);
void BKE_key_make_local(struct Key *key);
void BKE_key_sort(struct Key *key);
Cleanup and new features for vertex 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!
2005-09-26 15:34:21 +00:00
code cleanup: key/interpolation
2012-05-22 13:59:58 +00:00
void key_curve_position_weights(float t, float data[4], int type);
void key_curve_tangent_weights(float t, float data[4], int type);
void key_curve_normal_weights(float t, float data[4], int type);
Cleanup and new features for vertex 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!
2005-09-26 15:34:21 +00:00
Remove slurph shape-key feature This is an old option which wasn't working in over a year without complaint.
2015-01-07 02:02:55 +11:00
float *BKE_key_evaluate_object_ex(
struct Object *ob, int *r_totelem,
float *arr, size_t arr_size);
float *BKE_key_evaluate_object(
struct Object *ob, int *r_totelem);
Result of 2 weeks of quiet coding work in Greece :) Aim was to get a total refresh of the animation system. This is needed because; - we need to upgrade it with 21st century features - current code is spaghetti/hack combo, and hides good design - it should become lag-free with using dependency graphs A full log, with complete code API/structure/design explanation will follow, that's a load of work... so here below the list with hot changes; - The entire object update system (matrices, geometry) is now centralized. Calls to where_is_object and makeDispList are forbidden, instead we tag objects 'changed' and let the depgraph code sort it out - Removed all old "Ika" code - Depgraph is aware of all relationships, including meta balls, constraints, bevelcurve, and so on. - Made depgraph aware of relation types and layers, to do smart flushing of 'changed' events. Nothing gets calculated too often! - Transform uses depgraph to detect changes - On frame-advance, depgraph flushes animated changes Armatures; Almost all armature related code has been fully built from scratch. It now reveils the original design much better, with a very clean implementation, lag free without even calculating each Bone more than once. Result is quite a speedup yes! Important to note is; 1) Armature is data containing the 'rest position' 2) Pose is the changes of rest position, and always on object level. That way more Objects can use same Pose. Also constraints are in Pose 3) Actions only contain the Ipos to change values in Poses. - Bones draw unrotated now - Drawing bones speedup enormously (10-20 times) - Bone selecting in EditMode, selection state is saved for PoseMode, and vice-versa - Undo in editmode - Bone renaming does vertexgroups, constraints, posechannels, actions, for all users of Armature in entire file - Added Bone renaming in NKey panel - Nkey PoseMode shows eulers now - EditMode and PoseMode now have 'active' bone too (last clicked) - Parenting in EditMode' CTRL+P, ALT+P, with nice options! - Pose is added in Outliner now, with showing that constraints are in the Pose, not Armature - Disconnected IK solving from constraints. It's a separate phase now, on top of the full Pose calculations - Pose itself has a dependency graph too, so evaluation order is lag free. TODO NOW; - Rotating in Posemode has incorrect inverse transform (Martin will fix) - Python Bone/Armature/Pose API disabled... needs full recode too (wait for my doc!) - Game engine will need upgrade too - Depgraph code needs revision, cleanup, can be much faster! (But, compliments for Jean-Luc, it works like a charm!) - IK changed, it now doesnt use previous position to advance to next position anymore. That system looks nice (no flips) but is not well suited for NLA and background render. TODO LATER; We now can do loadsa new nifty features as well; like: - Kill PoseMode (can be option for armatures itself) - Make B-Bones (Bezier, Bspline, like for spines) - Move all silly button level edit to 3d window (like CTRL+I = add IK) - Much better & informative drawing - Fix action/nla editors - Put all ipos in Actions (object, mesh key, lamp color) - Add hooks - Null bones - Much more advanced constraints... Bugfixes; - OGL render (view3d header) had wrong first frame on anim render - Ipo 'recording' mode had wrong playback speed - Vertex-key mode now sticks to show 'active key', until frame change -Ton-
2005-07-03 17:35:38 +00:00
BKE_key: add BKE_key_from_id helper functions
2015-10-08 18:19:28 +11:00
struct Key **BKE_key_from_id_p(struct ID *id);
struct Key *BKE_key_from_id(struct ID *id);
RNA: Object.shape_key_remove method Python had no ability to remove shape keys Original D1169 from @lichtwerk, with edits
2015-06-08 19:49:01 +10:00
struct Key **BKE_key_from_object_p(struct Object *ob);
code cleanup: make shape key api names consistent with our new convention.
2012-09-19 10:12:07 +00:00
struct Key *BKE_key_from_object(struct Object *ob);
struct KeyBlock *BKE_keyblock_from_object(struct Object *ob);
struct KeyBlock *BKE_keyblock_from_object_reference(struct Object *ob);
struct KeyBlock *BKE_keyblock_add(struct Key *key, const char *name);
Code cleanup: use bools where possible
2014-02-03 18:55:59 +11:00
struct KeyBlock *BKE_keyblock_add_ctime(struct Key *key, const char *name, const bool do_force);
code cleanup: make shape key api names consistent with our new convention.
2012-09-19 10:12:07 +00:00
struct KeyBlock *BKE_keyblock_from_key(struct Key *key, int index);
struct KeyBlock *BKE_keyblock_find_name(struct Key *key, const char name[]);
joining mesh objects now keeps relative key setting of each keyblock. also joining absolute shapekeys now sorts by time.
2012-09-19 12:11:28 +00:00
void BKE_keyblock_copy_settings(struct KeyBlock *kb_dst, const struct KeyBlock *kb_src);
code cleanup: make shape key api names consistent with our new convention.
2012-09-19 10:12:07 +00:00
char *BKE_keyblock_curval_rnapath_get(struct Key *key, struct KeyBlock *kb);
Optimization and threading fix for shapekeys weights calculation 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
2013-08-19 10:36:39 +00:00
BGE Patch: Add Shape Action support and update MSCV_7 project file for glew. 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.
2008-06-18 06:46:49 +00:00
// needed for the GE
Optimization and threading fix for shapekeys weights calculation 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
2013-08-19 10:36:39 +00:00
typedef struct WeightsArrayCache {
int num_defgroup_weights;
float **defgroup_weights;
} WeightsArrayCache;
float **BKE_keyblock_get_per_block_weights(struct Object *ob, struct Key *key, struct WeightsArrayCache *cache);
void BKE_keyblock_free_per_block_weights(struct Key *key, float **per_keyblock_weights, struct WeightsArrayCache *cache);
void BKE_key_evaluate_relative(const int start, int end, const int tot, char *basispoin, struct Key *key, struct KeyBlock *actkb,
float **per_keyblock_weights, const int mode);
BGE Patch: Add Shape Action support and update MSCV_7 project file for glew. 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.
2008-06-18 06:46:49 +00:00
moved shape key insert function into BKE_object.h
2009-12-28 15:26:36 +00:00
/* conversion functions */
ShapeKey: Refactor a bit `BKE_key_convert_from_...` 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.
2014-11-16 18:50:23 +01:00
/* Note: 'update_from' versions do not (re)allocate mem in kb, while 'convert_from' do. */
Cleanup: rename `BKE_key_convert/update` to `BKE_keyblock_convert/update`. We are handling a keyblock here, not a whole key(set). Names are alreay a bit confusing, let's be consistent at least.
2014-11-16 19:15:23 +01:00
void BKE_keyblock_update_from_lattice(struct Lattice *lt, struct KeyBlock *kb);
void BKE_keyblock_convert_from_lattice(struct Lattice *lt, struct KeyBlock *kb);
void BKE_keyblock_convert_to_lattice(struct KeyBlock *kb, struct Lattice *lt);
ShapeKey: Refactor a bit `BKE_key_convert_from_...` 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.
2014-11-16 18:50:23 +01:00
Cleanup: rename `BKE_key_convert/update` to `BKE_keyblock_convert/update`. We are handling a keyblock here, not a whole key(set). Names are alreay a bit confusing, let's be consistent at least.
2014-11-16 19:15:23 +01:00
void BKE_keyblock_update_from_curve(struct Curve *cu, struct KeyBlock *kb, struct ListBase *nurb);
void BKE_keyblock_convert_from_curve(struct Curve *cu, struct KeyBlock *kb, struct ListBase *nurb);
void BKE_keyblock_convert_to_curve(struct KeyBlock *kb, struct Curve *cu, struct ListBase *nurb);
ShapeKey: Refactor a bit `BKE_key_convert_from_...` 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.
2014-11-16 18:50:23 +01:00
Cleanup: rename `BKE_key_convert/update` to `BKE_keyblock_convert/update`. We are handling a keyblock here, not a whole key(set). Names are alreay a bit confusing, let's be consistent at least.
2014-11-16 19:15:23 +01:00
void BKE_keyblock_update_from_mesh(struct Mesh *me, struct KeyBlock *kb);
void BKE_keyblock_convert_from_mesh(struct Mesh *me, struct KeyBlock *kb);
void BKE_keyblock_convert_to_mesh(struct KeyBlock *kb, struct Mesh *me);
ShapeKey: Refactor a bit `BKE_key_convert_from_...` 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.
2014-11-16 18:50:23 +01:00
Cleanup: rename `BKE_key_convert/update` to `BKE_keyblock_convert/update`. We are handling a keyblock here, not a whole key(set). Names are alreay a bit confusing, let's be consistent at least.
2014-11-16 19:15:23 +01:00
void BKE_keyblock_update_from_vertcos(struct Object *ob, struct KeyBlock *kb, float (*vertCos)[3]);
void BKE_keyblock_convert_from_vertcos(struct Object *ob, struct KeyBlock *kb, float (*vertCos)[3]);
float (*BKE_keyblock_convert_to_vertcos(struct Object *ob, struct KeyBlock *kb))[3];
ShapeKey: Refactor a bit `BKE_key_convert_from_...` 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.
2014-11-16 18:50:23 +01:00
Cleanup: rename `BKE_key_convert/update` to `BKE_keyblock_convert/update`. We are handling a keyblock here, not a whole key(set). Names are alreay a bit confusing, let's be consistent at least.
2014-11-16 19:15:23 +01:00
void BKE_keyblock_update_from_offset(struct Object *ob, struct KeyBlock *kb, float (*ofs)[3]);
moved shape key insert function into BKE_object.h
2009-12-28 15:26:36 +00:00
ShapeKeys: rework 'move skey' code, and add options to move to first/last 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!
2014-10-21 11:59:14 +02:00
/* other management */
bool BKE_keyblock_move(struct Object *ob, int org_index, int new_index);
ShapeKeys: Add `BKE_keyblock_is_basis` to check whether a given keyblock is used a basis by others. Also fix stupid debug-only error in previous commit.
2014-11-16 21:45:40 +01:00
bool BKE_keyblock_is_basis(struct Key *key, const int index);
BGE Patch: Add Shape Action support and update MSCV_7 project file for glew. 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.
2008-06-18 06:46:49 +00:00
#ifdef __cplusplus
};
#endif
- decided it made more sense to make a key_get_active function, switched to that in editmesh as well as for edit{curve,lattice} - added a G.editModeTitleExtra string that gets displayed in header info string in editmode. currently used to display "(Key)" when editing a key (before there was not UI level display of this info).
2005-07-15 17:55:19 +00:00
code cleanup: make header defines more consistent, JOYSENSOR header guard had a typo too.
2012-10-09 13:36:42 +00:00
#endif /* __BKE_KEY_H__ */
Copy Permalink