2011-07-30 09:24:10 +00:00
|
|
|
/*
|
|
|
|
* ***** BEGIN GPL LICENSE BLOCK *****
|
|
|
|
*
|
|
|
|
* 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
|
|
|
|
* of the License, or (at your option) any later version.
|
|
|
|
*
|
|
|
|
* 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,
|
|
|
|
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
|
|
|
|
*
|
|
|
|
* Contributor(s):
|
|
|
|
*
|
|
|
|
* ***** END GPL LICENSE BLOCK *****
|
|
|
|
*/
|
|
|
|
|
2011-02-27 20:29:51 +00:00
|
|
|
/** \file blender/editors/interface/interface_anim.c
|
|
|
|
* \ingroup edinterface
|
|
|
|
*/
|
2009-04-03 23:30:32 +00:00
|
|
|
|
|
|
|
#include <stdio.h>
|
|
|
|
#include <stdlib.h>
|
|
|
|
#include <string.h>
|
|
|
|
|
First stages of easier "expressions" creation...
It is now possible to create "scripted expression" drivers by simply
clicking on some property, and typing some short Python expression
prefixed with a '#'. This will result in a scripted expression driver,
with the typed-in text being created.
For example, you can click on X-Location of the default cube, and
type:
#sin(frame)
and a new driver will be created for the x-location of the cube. This
will use the current frame value, and modulate this with a sine wave.
Do note though, that the current frame is a special case here. In the
current implementation, a special "frame" driver variable, which
references the current scene frame is created automatically, so that
this simple and (assumed) common case will work straight out of the
box.
Future improvements:
- Explore possibilities of semi-automated extraction of variables from
such expressions, resulting in automated variable extraction. (Doing
away with variables completely is definitely 100% off the agenda
though)
- Look into some ways of defining some shorthands for referencing
local data (possibly related to variable extraction?)
2011-07-04 03:12:28 +00:00
|
|
|
#include "MEM_guardedalloc.h"
|
2009-04-03 23:30:32 +00:00
|
|
|
|
|
|
|
#include "DNA_anim_types.h"
|
|
|
|
#include "DNA_scene_types.h"
|
|
|
|
#include "DNA_screen_types.h"
|
|
|
|
|
2009-07-12 02:06:15 +00:00
|
|
|
#include "BLI_string.h"
|
2011-10-20 09:47:05 +00:00
|
|
|
#include "BLI_string_utf8.h"
|
First stages of easier "expressions" creation...
It is now possible to create "scripted expression" drivers by simply
clicking on some property, and typing some short Python expression
prefixed with a '#'. This will result in a scripted expression driver,
with the typed-in text being created.
For example, you can click on X-Location of the default cube, and
type:
#sin(frame)
and a new driver will be created for the x-location of the cube. This
will use the current frame value, and modulate this with a sine wave.
Do note though, that the current frame is a special case here. In the
current implementation, a special "frame" driver variable, which
references the current scene frame is created automatically, so that
this simple and (assumed) common case will work straight out of the
box.
Future improvements:
- Explore possibilities of semi-automated extraction of variables from
such expressions, resulting in automated variable extraction. (Doing
away with variables completely is definitely 100% off the agenda
though)
- Look into some ways of defining some shorthands for referencing
local data (possibly related to variable extraction?)
2011-07-04 03:12:28 +00:00
|
|
|
#include "BLI_utildefines.h"
|
2009-04-03 23:30:32 +00:00
|
|
|
|
|
|
|
#include "BKE_context.h"
|
|
|
|
#include "BKE_fcurve.h"
|
First stages of easier "expressions" creation...
It is now possible to create "scripted expression" drivers by simply
clicking on some property, and typing some short Python expression
prefixed with a '#'. This will result in a scripted expression driver,
with the typed-in text being created.
For example, you can click on X-Location of the default cube, and
type:
#sin(frame)
and a new driver will be created for the x-location of the cube. This
will use the current frame value, and modulate this with a sine wave.
Do note though, that the current frame is a special case here. In the
current implementation, a special "frame" driver variable, which
references the current scene frame is created automatically, so that
this simple and (assumed) common case will work straight out of the
box.
Future improvements:
- Explore possibilities of semi-automated extraction of variables from
such expressions, resulting in automated variable extraction. (Doing
away with variables completely is definitely 100% off the agenda
though)
- Look into some ways of defining some shorthands for referencing
local data (possibly related to variable extraction?)
2011-07-04 03:12:28 +00:00
|
|
|
#include "BKE_global.h"
|
2014-11-16 20:24:38 +13:00
|
|
|
#include "BKE_nla.h"
|
2009-04-03 23:30:32 +00:00
|
|
|
|
2009-07-08 12:30:09 +00:00
|
|
|
#include "ED_keyframing.h"
|
|
|
|
|
2009-04-03 23:30:32 +00:00
|
|
|
#include "UI_interface.h"
|
|
|
|
|
First stages of easier "expressions" creation...
It is now possible to create "scripted expression" drivers by simply
clicking on some property, and typing some short Python expression
prefixed with a '#'. This will result in a scripted expression driver,
with the typed-in text being created.
For example, you can click on X-Location of the default cube, and
type:
#sin(frame)
and a new driver will be created for the x-location of the cube. This
will use the current frame value, and modulate this with a sine wave.
Do note though, that the current frame is a special case here. In the
current implementation, a special "frame" driver variable, which
references the current scene frame is created automatically, so that
this simple and (assumed) common case will work straight out of the
box.
Future improvements:
- Explore possibilities of semi-automated extraction of variables from
such expressions, resulting in automated variable extraction. (Doing
away with variables completely is definitely 100% off the agenda
though)
- Look into some ways of defining some shorthands for referencing
local data (possibly related to variable extraction?)
2011-07-04 03:12:28 +00:00
|
|
|
#include "RNA_access.h"
|
|
|
|
|
2009-04-03 23:30:32 +00:00
|
|
|
#include "WM_api.h"
|
|
|
|
#include "WM_types.h"
|
|
|
|
|
|
|
|
#include "interface_intern.h"
|
|
|
|
|
2014-01-24 17:09:21 +13:00
|
|
|
static FCurve *ui_but_get_fcurve(uiBut *but, AnimData **adt, bAction **action, bool *r_driven, bool *r_special)
|
2009-04-03 23:30:32 +00:00
|
|
|
{
|
2013-01-31 16:19:44 +00:00
|
|
|
/* for entire array buttons we check the first component, it's not perfect
|
|
|
|
* but works well enough in typical cases */
|
2013-02-02 04:58:03 +00:00
|
|
|
int rnaindex = (but->rnaindex == -1) ? 0 : but->rnaindex;
|
2013-01-31 16:19:44 +00:00
|
|
|
|
2014-01-24 17:09:21 +13:00
|
|
|
return rna_get_fcurve_context_ui(but->block->evil_C, &but->rnapoin, but->rnaprop, rnaindex, adt, action, r_driven, r_special);
|
2009-07-12 02:06:15 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void ui_but_anim_flag(uiBut *but, float cfra)
|
|
|
|
{
|
2014-11-16 20:24:38 +13:00
|
|
|
AnimData *adt;
|
|
|
|
bAction *act;
|
2009-07-12 02:06:15 +00:00
|
|
|
FCurve *fcu;
|
2013-03-17 19:13:04 +00:00
|
|
|
bool driven;
|
2014-01-24 17:09:21 +13:00
|
|
|
bool special;
|
|
|
|
|
2012-03-30 01:51:25 +00:00
|
|
|
but->flag &= ~(UI_BUT_ANIMATED | UI_BUT_ANIMATED_KEY | UI_BUT_DRIVEN);
|
2014-01-24 17:09:21 +13:00
|
|
|
|
|
|
|
/* NOTE: "special" is reserved for special F-Curves stored on the animation data
|
|
|
|
* itself (which are used to animate properties of the animation data).
|
|
|
|
* We count those as "animated" too for now
|
|
|
|
*/
|
|
|
|
fcu = ui_but_get_fcurve(but, &adt, &act, &driven, &special);
|
|
|
|
|
2012-03-24 07:09:57 +00:00
|
|
|
if (fcu) {
|
|
|
|
if (!driven) {
|
2009-07-12 02:06:15 +00:00
|
|
|
but->flag |= UI_BUT_ANIMATED;
|
|
|
|
|
2014-11-16 20:24:38 +13:00
|
|
|
/* T41525 - When the active action is a NLA strip being edited,
|
|
|
|
* we need to correct the frame number to "look inside" the
|
|
|
|
* remapped action
|
|
|
|
*/
|
|
|
|
if (adt)
|
|
|
|
cfra = BKE_nla_tweakedit_remap(adt, cfra, NLATIME_CONVERT_UNMAP);
|
|
|
|
|
2012-03-24 07:09:57 +00:00
|
|
|
if (fcurve_frame_has_keyframe(fcu, cfra, 0))
|
2009-07-12 02:06:15 +00:00
|
|
|
but->flag |= UI_BUT_ANIMATED_KEY;
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
but->flag |= UI_BUT_DRIVEN;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-01-20 11:13:53 +11:00
|
|
|
bool ui_but_anim_expression_get(uiBut *but, char *str, size_t maxlen)
|
2009-07-12 02:06:15 +00:00
|
|
|
{
|
|
|
|
FCurve *fcu;
|
|
|
|
ChannelDriver *driver;
|
2014-01-24 17:09:21 +13:00
|
|
|
bool driven, special;
|
|
|
|
|
|
|
|
fcu = ui_but_get_fcurve(but, NULL, NULL, &driven, &special);
|
|
|
|
|
2012-03-24 07:09:57 +00:00
|
|
|
if (fcu && driven) {
|
2012-03-30 01:51:25 +00:00
|
|
|
driver = fcu->driver;
|
2009-07-12 02:06:15 +00:00
|
|
|
|
2012-03-24 07:09:57 +00:00
|
|
|
if (driver && driver->type == DRIVER_TYPE_PYTHON) {
|
2009-07-12 02:06:15 +00:00
|
|
|
BLI_strncpy(str, driver->expression, maxlen);
|
2014-01-20 11:13:53 +11:00
|
|
|
return true;
|
2009-07-12 02:06:15 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-01-20 11:13:53 +11:00
|
|
|
return false;
|
2009-07-12 02:06:15 +00:00
|
|
|
}
|
|
|
|
|
2014-01-20 11:13:53 +11:00
|
|
|
bool ui_but_anim_expression_set(uiBut *but, const char *str)
|
2009-07-12 02:06:15 +00:00
|
|
|
{
|
|
|
|
FCurve *fcu;
|
|
|
|
ChannelDriver *driver;
|
2014-01-24 17:09:21 +13:00
|
|
|
bool driven, special;
|
2009-07-12 02:06:15 +00:00
|
|
|
|
2014-01-24 17:09:21 +13:00
|
|
|
fcu = ui_but_get_fcurve(but, NULL, NULL, &driven, &special);
|
2009-07-12 02:06:15 +00:00
|
|
|
|
2012-03-24 07:09:57 +00:00
|
|
|
if (fcu && driven) {
|
2012-03-30 01:51:25 +00:00
|
|
|
driver = fcu->driver;
|
First stages of easier "expressions" creation...
It is now possible to create "scripted expression" drivers by simply
clicking on some property, and typing some short Python expression
prefixed with a '#'. This will result in a scripted expression driver,
with the typed-in text being created.
For example, you can click on X-Location of the default cube, and
type:
#sin(frame)
and a new driver will be created for the x-location of the cube. This
will use the current frame value, and modulate this with a sine wave.
Do note though, that the current frame is a special case here. In the
current implementation, a special "frame" driver variable, which
references the current scene frame is created automatically, so that
this simple and (assumed) common case will work straight out of the
box.
Future improvements:
- Explore possibilities of semi-automated extraction of variables from
such expressions, resulting in automated variable extraction. (Doing
away with variables completely is definitely 100% off the agenda
though)
- Look into some ways of defining some shorthands for referencing
local data (possibly related to variable extraction?)
2011-07-04 03:12:28 +00:00
|
|
|
|
2014-05-08 17:57:11 +12:00
|
|
|
if (driver && (driver->type == DRIVER_TYPE_PYTHON)) {
|
2011-10-20 07:12:14 +00:00
|
|
|
BLI_strncpy_utf8(driver->expression, str, sizeof(driver->expression));
|
2014-05-08 17:57:11 +12:00
|
|
|
|
|
|
|
/* tag driver as needing to be recompiled */
|
2010-12-13 19:10:35 +00:00
|
|
|
driver->flag |= DRIVER_FLAG_RECOMPILE;
|
2014-05-08 17:57:11 +12:00
|
|
|
|
|
|
|
/* clear invalid flags which may prevent this from working */
|
|
|
|
driver->flag &= ~DRIVER_FLAG_INVALID;
|
2014-05-08 19:54:04 +10:00
|
|
|
fcu->flag &= ~FCURVE_DISABLED;
|
2014-05-08 17:57:11 +12:00
|
|
|
|
|
|
|
/* this notifier should update the Graph Editor and trigger depsgraph refresh? */
|
2012-03-30 01:51:25 +00:00
|
|
|
WM_event_add_notifier(but->block->evil_C, NC_ANIMATION | ND_KEYFRAME, NULL);
|
2014-05-08 17:57:11 +12:00
|
|
|
|
2014-01-20 11:13:53 +11:00
|
|
|
return true;
|
2009-07-12 02:06:15 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-01-20 11:13:53 +11:00
|
|
|
return false;
|
2009-07-12 02:06:15 +00:00
|
|
|
}
|
|
|
|
|
First stages of easier "expressions" creation...
It is now possible to create "scripted expression" drivers by simply
clicking on some property, and typing some short Python expression
prefixed with a '#'. This will result in a scripted expression driver,
with the typed-in text being created.
For example, you can click on X-Location of the default cube, and
type:
#sin(frame)
and a new driver will be created for the x-location of the cube. This
will use the current frame value, and modulate this with a sine wave.
Do note though, that the current frame is a special case here. In the
current implementation, a special "frame" driver variable, which
references the current scene frame is created automatically, so that
this simple and (assumed) common case will work straight out of the
box.
Future improvements:
- Explore possibilities of semi-automated extraction of variables from
such expressions, resulting in automated variable extraction. (Doing
away with variables completely is definitely 100% off the agenda
though)
- Look into some ways of defining some shorthands for referencing
local data (possibly related to variable extraction?)
2011-07-04 03:12:28 +00:00
|
|
|
/* create new expression for button (i.e. a "scripted driver"), if it can be created... */
|
2014-01-20 11:13:53 +11:00
|
|
|
bool ui_but_anim_expression_create(uiBut *but, const char *str)
|
First stages of easier "expressions" creation...
It is now possible to create "scripted expression" drivers by simply
clicking on some property, and typing some short Python expression
prefixed with a '#'. This will result in a scripted expression driver,
with the typed-in text being created.
For example, you can click on X-Location of the default cube, and
type:
#sin(frame)
and a new driver will be created for the x-location of the cube. This
will use the current frame value, and modulate this with a sine wave.
Do note though, that the current frame is a special case here. In the
current implementation, a special "frame" driver variable, which
references the current scene frame is created automatically, so that
this simple and (assumed) common case will work straight out of the
box.
Future improvements:
- Explore possibilities of semi-automated extraction of variables from
such expressions, resulting in automated variable extraction. (Doing
away with variables completely is definitely 100% off the agenda
though)
- Look into some ways of defining some shorthands for referencing
local data (possibly related to variable extraction?)
2011-07-04 03:12:28 +00:00
|
|
|
{
|
|
|
|
bContext *C = but->block->evil_C;
|
|
|
|
ID *id;
|
|
|
|
FCurve *fcu;
|
|
|
|
char *path;
|
2013-01-31 21:56:14 +00:00
|
|
|
bool ok = false;
|
First stages of easier "expressions" creation...
It is now possible to create "scripted expression" drivers by simply
clicking on some property, and typing some short Python expression
prefixed with a '#'. This will result in a scripted expression driver,
with the typed-in text being created.
For example, you can click on X-Location of the default cube, and
type:
#sin(frame)
and a new driver will be created for the x-location of the cube. This
will use the current frame value, and modulate this with a sine wave.
Do note though, that the current frame is a special case here. In the
current implementation, a special "frame" driver variable, which
references the current scene frame is created automatically, so that
this simple and (assumed) common case will work straight out of the
box.
Future improvements:
- Explore possibilities of semi-automated extraction of variables from
such expressions, resulting in automated variable extraction. (Doing
away with variables completely is definitely 100% off the agenda
though)
- Look into some ways of defining some shorthands for referencing
local data (possibly related to variable extraction?)
2011-07-04 03:12:28 +00:00
|
|
|
|
|
|
|
/* button must have RNA-pointer to a numeric-capable property */
|
|
|
|
if (ELEM(NULL, but->rnapoin.data, but->rnaprop)) {
|
2012-03-31 00:59:17 +00:00
|
|
|
if (G.debug & G_DEBUG)
|
First stages of easier "expressions" creation...
It is now possible to create "scripted expression" drivers by simply
clicking on some property, and typing some short Python expression
prefixed with a '#'. This will result in a scripted expression driver,
with the typed-in text being created.
For example, you can click on X-Location of the default cube, and
type:
#sin(frame)
and a new driver will be created for the x-location of the cube. This
will use the current frame value, and modulate this with a sine wave.
Do note though, that the current frame is a special case here. In the
current implementation, a special "frame" driver variable, which
references the current scene frame is created automatically, so that
this simple and (assumed) common case will work straight out of the
box.
Future improvements:
- Explore possibilities of semi-automated extraction of variables from
such expressions, resulting in automated variable extraction. (Doing
away with variables completely is definitely 100% off the agenda
though)
- Look into some ways of defining some shorthands for referencing
local data (possibly related to variable extraction?)
2011-07-04 03:12:28 +00:00
|
|
|
printf("ERROR: create expression failed - button has no RNA info attached\n");
|
2014-01-20 11:13:53 +11:00
|
|
|
return false;
|
First stages of easier "expressions" creation...
It is now possible to create "scripted expression" drivers by simply
clicking on some property, and typing some short Python expression
prefixed with a '#'. This will result in a scripted expression driver,
with the typed-in text being created.
For example, you can click on X-Location of the default cube, and
type:
#sin(frame)
and a new driver will be created for the x-location of the cube. This
will use the current frame value, and modulate this with a sine wave.
Do note though, that the current frame is a special case here. In the
current implementation, a special "frame" driver variable, which
references the current scene frame is created automatically, so that
this simple and (assumed) common case will work straight out of the
box.
Future improvements:
- Explore possibilities of semi-automated extraction of variables from
such expressions, resulting in automated variable extraction. (Doing
away with variables completely is definitely 100% off the agenda
though)
- Look into some ways of defining some shorthands for referencing
local data (possibly related to variable extraction?)
2011-07-04 03:12:28 +00:00
|
|
|
}
|
|
|
|
|
2013-09-16 01:35:52 +00:00
|
|
|
if (RNA_property_array_check(but->rnaprop) != 0) {
|
2013-01-31 16:19:44 +00:00
|
|
|
if (but->rnaindex == -1) {
|
|
|
|
if (G.debug & G_DEBUG)
|
|
|
|
printf("ERROR: create expression failed - can't create expression for entire array\n");
|
2014-01-20 11:13:53 +11:00
|
|
|
return false;
|
2013-01-31 16:19:44 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
First stages of easier "expressions" creation...
It is now possible to create "scripted expression" drivers by simply
clicking on some property, and typing some short Python expression
prefixed with a '#'. This will result in a scripted expression driver,
with the typed-in text being created.
For example, you can click on X-Location of the default cube, and
type:
#sin(frame)
and a new driver will be created for the x-location of the cube. This
will use the current frame value, and modulate this with a sine wave.
Do note though, that the current frame is a special case here. In the
current implementation, a special "frame" driver variable, which
references the current scene frame is created automatically, so that
this simple and (assumed) common case will work straight out of the
box.
Future improvements:
- Explore possibilities of semi-automated extraction of variables from
such expressions, resulting in automated variable extraction. (Doing
away with variables completely is definitely 100% off the agenda
though)
- Look into some ways of defining some shorthands for referencing
local data (possibly related to variable extraction?)
2011-07-04 03:12:28 +00:00
|
|
|
/* make sure we have animdata for this */
|
2012-07-07 22:51:57 +00:00
|
|
|
/* FIXME: until materials can be handled by depsgraph, don't allow drivers to be created for them */
|
First stages of easier "expressions" creation...
It is now possible to create "scripted expression" drivers by simply
clicking on some property, and typing some short Python expression
prefixed with a '#'. This will result in a scripted expression driver,
with the typed-in text being created.
For example, you can click on X-Location of the default cube, and
type:
#sin(frame)
and a new driver will be created for the x-location of the cube. This
will use the current frame value, and modulate this with a sine wave.
Do note though, that the current frame is a special case here. In the
current implementation, a special "frame" driver variable, which
references the current scene frame is created automatically, so that
this simple and (assumed) common case will work straight out of the
box.
Future improvements:
- Explore possibilities of semi-automated extraction of variables from
such expressions, resulting in automated variable extraction. (Doing
away with variables completely is definitely 100% off the agenda
though)
- Look into some ways of defining some shorthands for referencing
local data (possibly related to variable extraction?)
2011-07-04 03:12:28 +00:00
|
|
|
id = (ID *)but->rnapoin.id.data;
|
2012-03-30 01:51:25 +00:00
|
|
|
if ((id == NULL) || (GS(id->name) == ID_MA) || (GS(id->name) == ID_TE)) {
|
2012-03-31 00:59:17 +00:00
|
|
|
if (G.debug & G_DEBUG)
|
2016-09-19 16:46:20 +02:00
|
|
|
printf("ERROR: create expression failed - invalid data-block for adding drivers (%p)\n", id);
|
2014-01-20 11:13:53 +11:00
|
|
|
return false;
|
First stages of easier "expressions" creation...
It is now possible to create "scripted expression" drivers by simply
clicking on some property, and typing some short Python expression
prefixed with a '#'. This will result in a scripted expression driver,
with the typed-in text being created.
For example, you can click on X-Location of the default cube, and
type:
#sin(frame)
and a new driver will be created for the x-location of the cube. This
will use the current frame value, and modulate this with a sine wave.
Do note though, that the current frame is a special case here. In the
current implementation, a special "frame" driver variable, which
references the current scene frame is created automatically, so that
this simple and (assumed) common case will work straight out of the
box.
Future improvements:
- Explore possibilities of semi-automated extraction of variables from
such expressions, resulting in automated variable extraction. (Doing
away with variables completely is definitely 100% off the agenda
though)
- Look into some ways of defining some shorthands for referencing
local data (possibly related to variable extraction?)
2011-07-04 03:12:28 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* get path */
|
|
|
|
path = RNA_path_from_ID_to_property(&but->rnapoin, but->rnaprop);
|
2014-05-21 16:33:48 +10:00
|
|
|
if (path == NULL) {
|
|
|
|
return false;
|
|
|
|
}
|
First stages of easier "expressions" creation...
It is now possible to create "scripted expression" drivers by simply
clicking on some property, and typing some short Python expression
prefixed with a '#'. This will result in a scripted expression driver,
with the typed-in text being created.
For example, you can click on X-Location of the default cube, and
type:
#sin(frame)
and a new driver will be created for the x-location of the cube. This
will use the current frame value, and modulate this with a sine wave.
Do note though, that the current frame is a special case here. In the
current implementation, a special "frame" driver variable, which
references the current scene frame is created automatically, so that
this simple and (assumed) common case will work straight out of the
box.
Future improvements:
- Explore possibilities of semi-automated extraction of variables from
such expressions, resulting in automated variable extraction. (Doing
away with variables completely is definitely 100% off the agenda
though)
- Look into some ways of defining some shorthands for referencing
local data (possibly related to variable extraction?)
2011-07-04 03:12:28 +00:00
|
|
|
|
|
|
|
/* create driver */
|
|
|
|
fcu = verify_driver_fcurve(id, path, but->rnaindex, 1);
|
|
|
|
if (fcu) {
|
2012-03-30 01:51:25 +00:00
|
|
|
ChannelDriver *driver = fcu->driver;
|
First stages of easier "expressions" creation...
It is now possible to create "scripted expression" drivers by simply
clicking on some property, and typing some short Python expression
prefixed with a '#'. This will result in a scripted expression driver,
with the typed-in text being created.
For example, you can click on X-Location of the default cube, and
type:
#sin(frame)
and a new driver will be created for the x-location of the cube. This
will use the current frame value, and modulate this with a sine wave.
Do note though, that the current frame is a special case here. In the
current implementation, a special "frame" driver variable, which
references the current scene frame is created automatically, so that
this simple and (assumed) common case will work straight out of the
box.
Future improvements:
- Explore possibilities of semi-automated extraction of variables from
such expressions, resulting in automated variable extraction. (Doing
away with variables completely is definitely 100% off the agenda
though)
- Look into some ways of defining some shorthands for referencing
local data (possibly related to variable extraction?)
2011-07-04 03:12:28 +00:00
|
|
|
|
|
|
|
if (driver) {
|
|
|
|
/* set type of driver */
|
|
|
|
driver->type = DRIVER_TYPE_PYTHON;
|
2012-07-06 23:56:59 +00:00
|
|
|
|
First stages of easier "expressions" creation...
It is now possible to create "scripted expression" drivers by simply
clicking on some property, and typing some short Python expression
prefixed with a '#'. This will result in a scripted expression driver,
with the typed-in text being created.
For example, you can click on X-Location of the default cube, and
type:
#sin(frame)
and a new driver will be created for the x-location of the cube. This
will use the current frame value, and modulate this with a sine wave.
Do note though, that the current frame is a special case here. In the
current implementation, a special "frame" driver variable, which
references the current scene frame is created automatically, so that
this simple and (assumed) common case will work straight out of the
box.
Future improvements:
- Explore possibilities of semi-automated extraction of variables from
such expressions, resulting in automated variable extraction. (Doing
away with variables completely is definitely 100% off the agenda
though)
- Look into some ways of defining some shorthands for referencing
local data (possibly related to variable extraction?)
2011-07-04 03:12:28 +00:00
|
|
|
/* set the expression */
|
2012-07-06 23:56:59 +00:00
|
|
|
/* TODO: need some way of identifying variables used */
|
2011-10-20 07:12:14 +00:00
|
|
|
BLI_strncpy_utf8(driver->expression, str, sizeof(driver->expression));
|
2011-11-17 07:08:09 +00:00
|
|
|
|
First stages of easier "expressions" creation...
It is now possible to create "scripted expression" drivers by simply
clicking on some property, and typing some short Python expression
prefixed with a '#'. This will result in a scripted expression driver,
with the typed-in text being created.
For example, you can click on X-Location of the default cube, and
type:
#sin(frame)
and a new driver will be created for the x-location of the cube. This
will use the current frame value, and modulate this with a sine wave.
Do note though, that the current frame is a special case here. In the
current implementation, a special "frame" driver variable, which
references the current scene frame is created automatically, so that
this simple and (assumed) common case will work straight out of the
box.
Future improvements:
- Explore possibilities of semi-automated extraction of variables from
such expressions, resulting in automated variable extraction. (Doing
away with variables completely is definitely 100% off the agenda
though)
- Look into some ways of defining some shorthands for referencing
local data (possibly related to variable extraction?)
2011-07-04 03:12:28 +00:00
|
|
|
/* updates */
|
|
|
|
driver->flag |= DRIVER_FLAG_RECOMPILE;
|
2012-03-30 01:51:25 +00:00
|
|
|
WM_event_add_notifier(C, NC_ANIMATION | ND_KEYFRAME, NULL);
|
2013-01-31 21:56:14 +00:00
|
|
|
ok = true;
|
First stages of easier "expressions" creation...
It is now possible to create "scripted expression" drivers by simply
clicking on some property, and typing some short Python expression
prefixed with a '#'. This will result in a scripted expression driver,
with the typed-in text being created.
For example, you can click on X-Location of the default cube, and
type:
#sin(frame)
and a new driver will be created for the x-location of the cube. This
will use the current frame value, and modulate this with a sine wave.
Do note though, that the current frame is a special case here. In the
current implementation, a special "frame" driver variable, which
references the current scene frame is created automatically, so that
this simple and (assumed) common case will work straight out of the
box.
Future improvements:
- Explore possibilities of semi-automated extraction of variables from
such expressions, resulting in automated variable extraction. (Doing
away with variables completely is definitely 100% off the agenda
though)
- Look into some ways of defining some shorthands for referencing
local data (possibly related to variable extraction?)
2011-07-04 03:12:28 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
MEM_freeN(path);
|
|
|
|
|
|
|
|
return ok;
|
|
|
|
}
|
|
|
|
|
2010-01-12 03:01:19 +00:00
|
|
|
void ui_but_anim_autokey(bContext *C, uiBut *but, Scene *scene, float cfra)
|
2009-07-12 02:06:15 +00:00
|
|
|
{
|
|
|
|
ID *id;
|
|
|
|
bAction *action;
|
|
|
|
FCurve *fcu;
|
2013-03-17 19:13:04 +00:00
|
|
|
bool driven;
|
2014-01-24 17:09:21 +13:00
|
|
|
bool special;
|
2009-07-12 02:06:15 +00:00
|
|
|
|
2014-01-24 17:09:21 +13:00
|
|
|
fcu = ui_but_get_fcurve(but, NULL, &action, &driven, &special);
|
2015-07-24 14:15:28 +12:00
|
|
|
|
|
|
|
if (fcu == NULL)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (special) {
|
|
|
|
/* NLA Strip property */
|
|
|
|
if (IS_AUTOKEY_ON(scene)) {
|
|
|
|
ReportList *reports = CTX_wm_reports(C);
|
2016-03-13 03:49:26 +13:00
|
|
|
ToolSettings *ts = scene->toolsettings;
|
2015-07-24 14:15:28 +12:00
|
|
|
|
2016-05-05 02:21:29 +10:00
|
|
|
insert_keyframe_direct(reports, but->rnapoin, but->rnaprop, fcu, cfra, ts->keyframe_type, 0);
|
2015-07-24 14:15:28 +12:00
|
|
|
WM_event_add_notifier(C, NC_ANIMATION | ND_KEYFRAME | NA_EDITED, NULL);
|
|
|
|
}
|
|
|
|
}
|
Driver Keyframing: Some tweaks to make inserting keyframes on Driver F-Curves easier
Now, when trying to insert a keyframe on a driven property (using IKEY, or with
autokeying enabled), the keyframes will get created on the Driver's F-Curve
(instead of creating a new FCurve that goes into the active action, but will never
do anything). Furthermore, the x-value of the new keyframe will be the current
result of the driver expression.
Why/Motivations:
This way, it becomes easier to create corrective drivers, as you can position all
the targets the driver depends on, then adjust the driver value until it does what
you need, and then you keyframe that value to bake it into the Driver F-Curve
(in effect, "training" the computer how to behave in that case).
Usage Notes:
* In practice, that particular workflow is still quite clunky to achieve, due to some
quirks of how the driver system and the UI widgets interact. Specifically, you'll
need to disable/mute the driver before trying to edit the setting (to prevent the
driver from immediately resetting the value - before even autokey fires!). However,
if you're using the Graph Editor to preview/monitor/manage the keying process, you'll
then want to re-enable the driver before changing the targets, so that you can see
how much of a change you'll want to be applying!
* The warning about editing driver values may need to be disabled or selectively
knocked out. I had it disabled while testing this functionality, but it's actually
harmless in its current state (if just a bit annoying).
2016-03-24 19:33:13 +13:00
|
|
|
else if (driven) {
|
|
|
|
/* Driver - Try to insert keyframe using the driver's input as the frame,
|
|
|
|
* making it easier to set up corrective drivers
|
|
|
|
*/
|
|
|
|
if (IS_AUTOKEY_ON(scene)) {
|
|
|
|
ReportList *reports = CTX_wm_reports(C);
|
|
|
|
ToolSettings *ts = scene->toolsettings;
|
|
|
|
|
2016-05-05 02:21:29 +10:00
|
|
|
insert_keyframe_direct(reports, but->rnapoin, but->rnaprop, fcu, cfra, ts->keyframe_type, INSERTKEY_DRIVER);
|
Driver Keyframing: Some tweaks to make inserting keyframes on Driver F-Curves easier
Now, when trying to insert a keyframe on a driven property (using IKEY, or with
autokeying enabled), the keyframes will get created on the Driver's F-Curve
(instead of creating a new FCurve that goes into the active action, but will never
do anything). Furthermore, the x-value of the new keyframe will be the current
result of the driver expression.
Why/Motivations:
This way, it becomes easier to create corrective drivers, as you can position all
the targets the driver depends on, then adjust the driver value until it does what
you need, and then you keyframe that value to bake it into the Driver F-Curve
(in effect, "training" the computer how to behave in that case).
Usage Notes:
* In practice, that particular workflow is still quite clunky to achieve, due to some
quirks of how the driver system and the UI widgets interact. Specifically, you'll
need to disable/mute the driver before trying to edit the setting (to prevent the
driver from immediately resetting the value - before even autokey fires!). However,
if you're using the Graph Editor to preview/monitor/manage the keying process, you'll
then want to re-enable the driver before changing the targets, so that you can see
how much of a change you'll want to be applying!
* The warning about editing driver values may need to be disabled or selectively
knocked out. I had it disabled while testing this functionality, but it's actually
harmless in its current state (if just a bit annoying).
2016-03-24 19:33:13 +13:00
|
|
|
WM_event_add_notifier(C, NC_ANIMATION | ND_KEYFRAME | NA_EDITED, NULL);
|
|
|
|
}
|
|
|
|
}
|
2016-04-01 10:02:59 +11:00
|
|
|
else {
|
2012-03-30 01:51:25 +00:00
|
|
|
id = but->rnapoin.id.data;
|
Driver Keyframing: Some tweaks to make inserting keyframes on Driver F-Curves easier
Now, when trying to insert a keyframe on a driven property (using IKEY, or with
autokeying enabled), the keyframes will get created on the Driver's F-Curve
(instead of creating a new FCurve that goes into the active action, but will never
do anything). Furthermore, the x-value of the new keyframe will be the current
result of the driver expression.
Why/Motivations:
This way, it becomes easier to create corrective drivers, as you can position all
the targets the driver depends on, then adjust the driver value until it does what
you need, and then you keyframe that value to bake it into the Driver F-Curve
(in effect, "training" the computer how to behave in that case).
Usage Notes:
* In practice, that particular workflow is still quite clunky to achieve, due to some
quirks of how the driver system and the UI widgets interact. Specifically, you'll
need to disable/mute the driver before trying to edit the setting (to prevent the
driver from immediately resetting the value - before even autokey fires!). However,
if you're using the Graph Editor to preview/monitor/manage the keying process, you'll
then want to re-enable the driver before changing the targets, so that you can see
how much of a change you'll want to be applying!
* The warning about editing driver values may need to be disabled or selectively
knocked out. I had it disabled while testing this functionality, but it's actually
harmless in its current state (if just a bit annoying).
2016-03-24 19:33:13 +13:00
|
|
|
|
2012-07-06 23:56:59 +00:00
|
|
|
/* TODO: this should probably respect the keyingset only option for anim */
|
2012-03-24 07:09:57 +00:00
|
|
|
if (autokeyframe_cfra_can_key(scene, id)) {
|
2010-11-17 12:02:36 +00:00
|
|
|
ReportList *reports = CTX_wm_reports(C);
|
2016-03-13 03:49:26 +13:00
|
|
|
ToolSettings *ts = scene->toolsettings;
|
2009-12-14 12:09:20 +00:00
|
|
|
short flag = ANIM_get_keyframing_flags(scene, 1);
|
Driver Keyframing: Some tweaks to make inserting keyframes on Driver F-Curves easier
Now, when trying to insert a keyframe on a driven property (using IKEY, or with
autokeying enabled), the keyframes will get created on the Driver's F-Curve
(instead of creating a new FCurve that goes into the active action, but will never
do anything). Furthermore, the x-value of the new keyframe will be the current
result of the driver expression.
Why/Motivations:
This way, it becomes easier to create corrective drivers, as you can position all
the targets the driver depends on, then adjust the driver value until it does what
you need, and then you keyframe that value to bake it into the Driver F-Curve
(in effect, "training" the computer how to behave in that case).
Usage Notes:
* In practice, that particular workflow is still quite clunky to achieve, due to some
quirks of how the driver system and the UI widgets interact. Specifically, you'll
need to disable/mute the driver before trying to edit the setting (to prevent the
driver from immediately resetting the value - before even autokey fires!). However,
if you're using the Graph Editor to preview/monitor/manage the keying process, you'll
then want to re-enable the driver before changing the targets, so that you can see
how much of a change you'll want to be applying!
* The warning about editing driver values may need to be disabled or selectively
knocked out. I had it disabled while testing this functionality, but it's actually
harmless in its current state (if just a bit annoying).
2016-03-24 19:33:13 +13:00
|
|
|
|
2009-07-12 02:06:15 +00:00
|
|
|
fcu->flag &= ~FCURVE_SELECTED;
|
Driver Keyframing: Some tweaks to make inserting keyframes on Driver F-Curves easier
Now, when trying to insert a keyframe on a driven property (using IKEY, or with
autokeying enabled), the keyframes will get created on the Driver's F-Curve
(instead of creating a new FCurve that goes into the active action, but will never
do anything). Furthermore, the x-value of the new keyframe will be the current
result of the driver expression.
Why/Motivations:
This way, it becomes easier to create corrective drivers, as you can position all
the targets the driver depends on, then adjust the driver value until it does what
you need, and then you keyframe that value to bake it into the Driver F-Curve
(in effect, "training" the computer how to behave in that case).
Usage Notes:
* In practice, that particular workflow is still quite clunky to achieve, due to some
quirks of how the driver system and the UI widgets interact. Specifically, you'll
need to disable/mute the driver before trying to edit the setting (to prevent the
driver from immediately resetting the value - before even autokey fires!). However,
if you're using the Graph Editor to preview/monitor/manage the keying process, you'll
then want to re-enable the driver before changing the targets, so that you can see
how much of a change you'll want to be applying!
* The warning about editing driver values may need to be disabled or selectively
knocked out. I had it disabled while testing this functionality, but it's actually
harmless in its current state (if just a bit annoying).
2016-03-24 19:33:13 +13:00
|
|
|
|
2014-11-15 17:57:29 +01:00
|
|
|
/* Note: We use but->rnaindex instead of fcu->array_index,
|
|
|
|
* because a button may control all items of an array at once.
|
|
|
|
* E.g., color wheels (see T42567). */
|
|
|
|
BLI_assert((fcu->array_index == but->rnaindex) || (but->rnaindex == -1));
|
|
|
|
insert_keyframe(reports, id, action, ((fcu->grp) ? (fcu->grp->name) : (NULL)),
|
2016-03-13 03:49:26 +13:00
|
|
|
fcu->rna_path, but->rnaindex, cfra, ts->keyframe_type, flag);
|
Driver Keyframing: Some tweaks to make inserting keyframes on Driver F-Curves easier
Now, when trying to insert a keyframe on a driven property (using IKEY, or with
autokeying enabled), the keyframes will get created on the Driver's F-Curve
(instead of creating a new FCurve that goes into the active action, but will never
do anything). Furthermore, the x-value of the new keyframe will be the current
result of the driver expression.
Why/Motivations:
This way, it becomes easier to create corrective drivers, as you can position all
the targets the driver depends on, then adjust the driver value until it does what
you need, and then you keyframe that value to bake it into the Driver F-Curve
(in effect, "training" the computer how to behave in that case).
Usage Notes:
* In practice, that particular workflow is still quite clunky to achieve, due to some
quirks of how the driver system and the UI widgets interact. Specifically, you'll
need to disable/mute the driver before trying to edit the setting (to prevent the
driver from immediately resetting the value - before even autokey fires!). However,
if you're using the Graph Editor to preview/monitor/manage the keying process, you'll
then want to re-enable the driver before changing the targets, so that you can see
how much of a change you'll want to be applying!
* The warning about editing driver values may need to be disabled or selectively
knocked out. I had it disabled while testing this functionality, but it's actually
harmless in its current state (if just a bit annoying).
2016-03-24 19:33:13 +13:00
|
|
|
|
2012-03-30 01:51:25 +00:00
|
|
|
WM_event_add_notifier(C, NC_ANIMATION | ND_KEYFRAME | NA_EDITED, NULL);
|
2009-07-12 02:06:15 +00:00
|
|
|
}
|
|
|
|
}
|
2009-04-03 23:30:32 +00:00
|
|
|
}
|
|
|
|
|
2009-09-25 04:51:04 +00:00
|
|
|
void ui_but_anim_copy_driver(bContext *C)
|
|
|
|
{
|
2014-11-09 21:20:40 +01:00
|
|
|
/* this operator calls UI_context_active_but_prop_get */
|
2009-09-25 04:51:04 +00:00
|
|
|
WM_operator_name_call(C, "ANIM_OT_copy_driver_button", WM_OP_INVOKE_DEFAULT, NULL);
|
|
|
|
}
|
|
|
|
|
|
|
|
void ui_but_anim_paste_driver(bContext *C)
|
|
|
|
{
|
2014-11-09 21:20:40 +01:00
|
|
|
/* this operator calls UI_context_active_but_prop_get */
|
2009-09-25 04:51:04 +00:00
|
|
|
WM_operator_name_call(C, "ANIM_OT_paste_driver_button", WM_OP_INVOKE_DEFAULT, NULL);
|
|
|
|
}
|