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
b3dabc200a4b0399ec6b81f2ff2730d07b44fcaa
blender-archive/source/blender/blenkernel/BKE_key.h

108 lines
4.5 KiB
C++
Raw Normal View History

doxygen: blenkernel under core as module.
2011-02-18 13:05:18 +00:00
/*
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.
*/
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: add newline after \file While \file doesn't need an argument, it can't have another doxy command after it.
2019-02-18 08:08:12 +11:00
/** \file
* \ingroup bke
doxygen: blenkernel under core as module.
2011-02-18 13:05:18 +00:00
*/
Cleanup: sort forward declarations of enum & struct Done using: source/tools/utils_maintenance/c_sort_blocks.py
2019-01-28 21:08:24 +11:00
struct Curve;
struct ID;
Initial revision
2002-10-12 11:37:38 +00:00
struct Key;
struct KeyBlock;
struct Lattice;
Cleanup: sort forward declarations of enum & struct Done using: source/tools/utils_maintenance/c_sort_blocks.py
2019-01-28 21:08:24 +11:00
struct ListBase;
Cleanup to shapekeys' make_local (and copy) functions. 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!
2016-07-09 14:44:48 +02:00
struct Main;
Initial revision
2002-10-12 11:37:38 +00:00
struct Mesh;
Cleanup: sort forward declarations of enum & struct Done using: source/tools/utils_maintenance/c_sort_blocks.py
2019-01-28 21:08:24 +11:00
struct Object;
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);
Cleanup: remove moar G.main from BKE area.
2018-06-12 12:53:27 +02:00
struct Key *BKE_key_add(struct Main *bmain, struct ID *id);
Refactor ID copying (and to some extent, ID freeing). 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
2017-08-07 16:39:55 +02:00
void BKE_key_copy_data(struct Main *bmain, struct Key *key_dst, const struct Key *key_src, const int flag);
Make whole ID copying code use const source pointer. 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.
2017-06-14 22:36:30 +02:00
struct Key *BKE_key_copy(struct Main *bmain, const 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_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
ShapeKey: add utils to say whether given ID type supports shapekeys. Those kind of checks are handy to have for generic processing...
2019-01-25 17:37:19 +01:00
bool BKE_key_idtype_support(const short id_type);
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);
Cleanup: Set BKE_key_from_object/_p to take const Object *
2019-02-26 18:14:09 -03:00
struct Key **BKE_key_from_object_p(const struct Object *ob);
struct Key *BKE_key_from_object(const struct Object *ob);
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_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
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
Put the Radius property of Curve points under shape key control. Since shape keys are stored as raw floating point data, this unfortunately requires changes to all code that works with it. An additional complication is that bezier and nurbs control points have different entry size, and can be mixed in the same object (and hence shape key buffer). Shape key entries are changed from: bezier: float v1[3], v2[3], v3[3], tilt, pad, pad; nurbs: float vec[3], tilt; To: bezier: float v1[3], v2[3], v3[3], tilt, radius, pad; nurbs: float vec[3], tilt, radius, pad; The official shape key element size is changed to 3 floats, with 4 elements for bezier nodes, and 2 for nurbs. This also means that the element count is not equal to the vertex count anymore. While searching for all curve Shape Key code, I also found that BKE_curve_transform_ex and BKE_curve_translate were broken. This can be seen by trying to change the Origin of a Curve with keys. Reviewers: campbellbarton, sergey Differential Revision: https://developer.blender.org/D3676
2018-09-05 16:17:59 +03:00
int BKE_keyblock_curve_element_count(struct ListBase *nurb);
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);
Cleanup: remove DM from 'join as shape' operator. Also deduplicated the 'mesh as shapekey' code, we had kind of two funcs doing the same thing here...
2018-06-21 18:24:32 +02:00
void BKE_keyblock_convert_from_mesh(struct Mesh *me, struct Key *key, struct KeyBlock *kb);
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_convert_to_mesh(struct KeyBlock *kb, struct Mesh *me);
Add functions to compute normals (verts, polys and loops ones) for a given 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
2015-10-12 20:12:55 +02:00
void BKE_keyblock_mesh_calc_normals(
struct KeyBlock *kb, struct Mesh *mesh, float (*r_vertnors)[3], float (*r_polynors)[3], float (*r_loopnors)[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_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