Well, we feel ourselves a bit uncomfortable - we were not learned in maya classes, so our explanation about what Driven Key is would look like we “teach teachers” So let us just note: IMO it’s a good and effective tool to collect animation into “buckets” and do control it much more simpler and effectiver.
From technical point of view:
- Driven Key is quite realistic to implement - it does not require to rebuild EI architecture. Please don’t get us wrong - “realistic” does not mean “easy/tomorrow”. Please also don’t think like “Igors willing..” - we want just to discuss an idea that IMO is interested/perspective - nothing more
- EI animation channels = a bit “low-level” system. It’s good and bad same time. But this low-level is very suitable for Driven Key
- some Driven Key features can be “shared” with XP - at least it would be usable to show (with color) that a channel is “controlled”
We realize we cannot hope for a storm of users’ enthusiasm here - the feature is a bit unusual/unfamiliar for EI user (same as “vertex cache"). But all can be changed if it’s well-explained/promoted
Would it also be possible to add Custom Attributes to objects or nulls? I suppose this would be an empty animation channel where the user supplies the name, data type, and allowable range of values.
Also, many software packages offer Virtual Sliders to control the value of the attribute. Currently EI is very numeric, with data entry fields. Could a virtual slider be implemented?
I apologize if this is listing two additional features, when you only proposed the Driven Key feature.
Just the fact that we’re discussing these types of issues & tools is very encouraging. I feel we’ve reached a certain level of understanding that there are a large number of animation tools we’d like to see implimented, but only a certain amount of resources available to get them done… and there’s no way to get them all done by v8. lol. So do not feel uncomfortable. Users will not blame you if there is a dialog of communication and understanding going on. Its also ok if you’re not familiar with any particular tool or suggestion that’s brought up. No one expects you to know everything. (I’ll also work not to imply that I know everything either...lol. No one likes a know it all) Its just little gestures of understanding from both party’s parts that keeps things civil. We also understand that EITG is driving the big picture which may place emphasis on upgrading specific areas of EIAS above others. However, if we can holistically address all aspects of upgrading the program to a certain degree, you’ll have a happier user base. Thank you for listening.
Thus we should always try to:
1. Do some bug fixes.
2. Address core problems. (Which we should work to identify)
3. Impliment some infrastructure improvements.
4. Add new features (in all disciplines when possible)
Now..as for set driven key.. well I’m for it too. How would you like to proceed on this front?
[ Edited: 01 September 2008 06:33 PM by Paralumino]
Would it also be possible to add Custom Attributes to objects or nulls? I suppose this would be an empty animation channel where the user supplies the name, data type, and allowable range of values.
Yes, no way to avoid this, at least need a room for “driver channel” itself. In EI terms “custom attributes” = just additional bunch of animation channels (like “Sockets” for a plug-in group).
KurtF - 01 September 2008 05:47 PM
Also, many software packages offer Virtual Sliders to control the value of the attribute. Currently EI is very numeric, with data entry fields. Could a virtual slider be implemented?
This idea “has a long beard” , and can be very usable even without Driven Key. Ramjac can story a lot about this. A positive note: EI already has “custom graph” (although not perfect) that, most probably, will be needed here. But, of course, it deserves a separated thread.
Back to Driven Key: it would be nice to see detailed explanations about what benefits a user can get from it.
Back to Driven Key: it would be nice to see detailed explanations about what benefits a user can get from it.
Hello Igors,
How do character animators utilize set driven key? Wow… that’s a big question and its filled with numerous answers. I think I’ve used set driven key in nearly every character I’ve set up. Here’s a list of a couple of ways how I use it.
1. The biggest usage of set driven key for CA users is to drive the relative rotation of forward kinematic joints. The best example here would be the FK joints of the fingers. Its impractical to use IK for fingers, and while FK will work just fine, sometimes having to rotate so many joints in the fingers gets time consuming. By establishing Set Driven Keys for FK joints in the hand, the CA artist can create multiple finger positions and easily animate between them by sliding a single virtual slider.
2. Set driven keys can also be used to drive any number of potential conditions or collections of animated values. They can be tied into material settings to alter RGB values. I’ll use this with my universal human rigs to alter the color of the character’s skin just by changing a single attribute value.
3. They could be tied in to driving animated values of potential deformations without having to go into the deformation editor or perhaps drive animated morph values for pheonomes for the face or any potential collection of animated values that would require multiple keys to accomplish. They would be GREAT to drive potential CV positions in Trestle rather than having to open the interface and move every CV by hand.
4. Even every day mundane things can benefit from SDK. Creating relationships between the translation of one object to alter the position or rotation of another all without having to write an expression.
As Kurt pointed out, it would be great to continue expanding EI’s ability to create custom animation channels which can be dictated by an animatable range of values and what kind of data it would process like Vectors, Floats, Integers, Booleans, Strings and so forth.
Set Driven Keys are a tremendous asset.
[ Edited: 02 September 2008 05:50 AM by Paralumino]
if i understand correctly, set driven keys are similar in concept to a master light function? i would definitely make use of that. i don’t have time(or really even the will) to learn Xpressionist, so the ability to control a bunch of keyframes with one or a slider or something would be phenomenal....
if i understand correctly, set driven keys are similar in concept to a master light function? i would definitely make use of that. i don’t have time(or really even the will) to learn Xpressionist, so the ability to control a bunch of keyframes with one or a slider or something would be phenomenal....
We propose to implement Driven Key as a “time projection” - it’s a bit different as in maya, although a basic idea is same. Example:
Imagine you created an animation with 10 keys only. Even with this (very little) count of keys it’s not very easy to control animation speed here and there, duplicate, loop, play back it etc. Everything requires moving keys, dup keys etc.
Let’s link all 10 channels to a single “driver” channel. Specify driver’s time range. For example 0.0 = time 0 seconds, and 1.0 = time 10 seconds. Now let’s animate driver channel. All driven channels pass to host their values corresponded to a time defined by driver. For example, actual time 5 second, but driver channel value = 0.25. So now every driven will pass a value at time = 2.5 second.
Driven channels are disabled and shown with some color (maybe even their keys should be hidden). Drivers - with another color. Click on driver/driven (contextual menu) helps to find relation. A dialog can be called for driver to show all driven(s). Of course, driver can be driven with another driver etc.
Hi Igors,
Is there a chance that we can get Xpressionist to act visually more interesting. I´ve found that Xpressionist is so powerful if it was visually appealing, for example select 4 channels of object A and link these with a pick whip to object B kind lie the StrenghtMap tab only you will have object A on one side and object B in the other. Than you can customize however you want these channel to be displayed in your world window, by sliders, by integers, by percentage,etc
Now that you mentioned Driven Key and Xpressionist i was wondering if these could be possible? Or is it too much work than live it.
Is there a chance that we can get Xpressionist to act visually more interesting. I´ve found that Xpressionist is so powerful if it was visually appealing, for example select 4 channels of object A and link these with a pick whip to object B kind lie the StrenghtMap tab only you will have object A on one side and object B in the other. Than you can customize however you want these channel to be displayed in your world window, by sliders, by integers, by percentage,etc
Now that you mentioned Driven Key and Xpressionist i was wondering if these could be possible? Or is it too much work than live it.
There is no any contradiction/competition between XP and Driven Key (DK). They can work together and some DK features (if it would be implemented) are usable for XP as well, because both provide a relation driver/driven (master/slave) so it needs to be at least visualized with channels colors etc. But XP goal is an “active” calculations by using formulas etc. DK calculates nothing but can handle “basic animation” in many ways. Examples of “happy work together” (XP + DK) are easy to imagine:
- XP provides a complex formula for driver channel
- DK handles driven channels that are XP input
Ok.. lots of potential here. Lets start with establishing the basic premise of DK: DK is a relationship between the animation channels of the driver, affecting the multiple (or single) channels of the driven (one object or many). You’re correct, DK is a sophisticated, but simple method to permit the actions of one object to drive the actions of another. But its not necessarily a direct channel routing procedure.
For example, in its simplest form… DK could be used to create a relationship of the translating an object1 from point A to point B to cause object2 to scale in Y size. Xpressionist could certainly handling this type of situation on a one to one basis by routing channel data from one object to the other… but without additional modifications to the expression, the values transferred from object1.translation x = object2.scale y would be true values being passed.
In DK, the goal is to “record” the potential animated values of object2’s Y scale dependent on the x position of object A. Users can use inherit animation channels to do this, but a more common approach is to create something unique. This is why DK is so commonly tied in with custom attributes/channels. Users like to define their own attributes, data types, and ranges that are used as drivers to alter the animated state of multiple driven objects. Since the drivers can have arbitrary values, they don’t actually route those values into the driven, they just determine the state of the driven’s recorded animation. This is very helpful for creating custom controls in an animation rig.
I can see the time projection as working to do this...thus providing “time” as the method to drive recorded driven animation...however, is there no way to allow an existing object, whether it be geometry or a null, to be given new, user defined animation channels that possess their own unique range and data type? If we can’t add animation channels to an existing object or null in EI, can we create a new class of object that permits for the creation of custom user animation channels/attributes (as many as a user wants) that would specifically be designed to address the DK situation? Maybe for custom situations we should consider a DK plugin instead of using inherit animation channels of an existing object? A DK plugin could allow the user to create custom channels and specific data ranges and being its a plugin, its always evaluated.
[ Edited: 04 September 2008 06:52 AM by Paralumino]
I apologize if my comment is brief. I am busy with other things and can’t fully elaborate.
However I would like to mention two quick comment. SDK is paramount to intuitive animation controls.
Spread fingers and heel/ball/toe controls can be achieved with XP, but a GUI where you just position for fingers where
you want, then hit Set Driven Key has more aesthetic control than sweeping mathematic values for a finger position.
Just place the hand with just the right amount of curl and hit key. The key is then attached to a controller where the value for that hand position can be dialed in and out. Nice thing is you can put 3 or 4 key on that one variable range (1-10)
That means finger spread at 1, fingers together at 5 and fist at 10. A whole gesture into one slider (value range 1-10)
Also important, each keyframe for that range of motion can be edited as animation curves. This allows the artist to tweak say a Foot roll sequence, The heel back, ball of foot rool and the toe tap.
Finally the range of motion is set to a value range which is set/attached to a object (custom attribute) or bucket as you say. But mind you, this bucket (kontreuller) is a separate dialog. Artist like to have access to the variable via the Icon controllers of the rig...say a hand control brings up the bucket.
It would be nice if the bucket have a variable slider.
Lastly, I’m also really happy to see EI users/programmers talking about SDK.
So let us just note: IMO it’s a good and effective tool to collect animation into “buckets” and do control it much more simpler and effectiver.
(I’ll also work not to imply that I know everything either...lol. No one likes a know it all) Its just little gestures of understanding from both party’s parts that keeps things civil. We also understand that EITG is driving the big picture which may place emphasis on upgrading specific areas of EIAS above others. However, if we can holistically address all aspects of upgrading the program to a certain degree, you’ll have a happier user base. Thank you for listening.
