BTW, I was just digging around in the code, particularly Campbell’s way of ghosting the original Ipo along with the edited version. It’s a lot less straightforward than I thought, and not really as adaptable to this usage as I had hoped. Urk.
So, for users of other software packages, what is the ideal behavior do you think? Should you be able to visualize an arbitrary number of objects’ Ipos in a single window? Should they all be editable at once, or only the active object’s Ipo editable with the others just there for reference?
Ideally the curves for all selected objects/bones should be able to be seen and edited together. Some provision for locking a channel against editing in the window would also be very useful, as would the option to not display keypoint handles.
Locking a channel should be an easy feature for the Action Editor.
I conceptually understand it this way: Ipo->Action->NLA. The Ipo is the individual motions for an individual thing, like a bone. The Action editor is the editor for the pose of the whole Armature, to define reusable Amrature Actions that say WHAT is to happen. The NLA blends Actions to say WHEN the action should occur, and to blend multiple actions (breath and walk at the same time). My tutorial on using an mocap library might help in this regard, where we go from IPO curves to Actions to NLA.
I too would like to see the Ipo, Action, and NLA editors to display linked datablocks for something other than the active object, but additional info (in the header?) as to the object being represented would have to be added.
Tip: Adding a key in the Action editor for selected bones is the same as selecting each bone individually and adding a pose key in the Ipo Window.
Firstly, whenever I want to edit animation I rarely if ever need to move the whole curve at once which is the default action in the IPO when first opening it.
I normally want to move/edit keys only. That’s why I think that having all keys open for edit from the outset is important.
Secondly, being able to see only what matters to you when editing is vital. I want to be able to say “Show me only the rotations of these 10 objects.” and assess the curves against each other.
I think filtering the data is important. Having too much on screen at once is as bad as too little.
Check these out…
THIS is how everyone else is doing it. Multiple objects in the one view, intelligent filtering, key frame editing as initial, base functionality and a displayed line of icons for important things like key tangents.
Now, this may be just me and I hope there is a simple workflow solution for it but It trips me up all the time…
Nice one, Glenn!
I was just in the process of grabbing some screen shots in reply to Harkyman when I saw your post. As far as how to filter what curves are being shown, I think the example from 3D Max is a good one. (… and BTW if you’re ever getting really pissed off with the IPO editor, try using the curve editor on a Flint or a Flame… ugh!)
Also, on the subject of accidentally grabbing handles, would it be reasonable to say that when selecting and moving multiple keys, you almost never want to select and move individual tangent handles?
In other words:
a border select should ignore the handles entirely,
when moving multiple keys, the handles for the selected keys (and only those keys) move automatically with them.
Would this be too limiting? How about if it was an option you could turn on or off?
Yep, you’re right. That works well. But the fact that I didn’t remember it re-enforces the need for an icon IMOHO. But let’s not allow Freen and my brain fades from detracting from the topic.
This is a little off-topic, but it reinforces that fact that this type of workflow is fairly consistent across programs.
In almost all music production software, there is a similar window for editing MIDI tracks. You have the option to view the data for all selected tracks, lock tracks from being edited, hide tracks that you don’t want temporarily, or edit all track simultaneously.
I know it’s not animation, but even in other digital media fields, this seems to be the default way of working with multiple sets of data like this.
I haven’t delved deeply into animation yet, but the system grsaaynoel has been describing fits better with the way my brain is trained to think about editing data. While the NLA and Action editors are powerful tools, IPO curves can convey very quickly what an object or bone is doing and how it is doing it. The other editors seem to require a good amount of cross referencing between a 3D view and the keyframe view in order to determine what each little diamond actually represents in terms of the object’s position.
The visual reminder is that the header menu says “Curve” in Curve mode. When you View->Show Keys the menu changes to Keys. This is consistent throughout Blender, such as an object/edit mode, in Edit the header menu changes to context-sensitive commands relative to the object being edited. I thnk that once you know that Blender can work with both curves and keys, looking at the display or at the menu tells you what set you are working with.
In Curve mode, the menu Curve->Handle->xxx allows you to select/change handle behaviour.
You can also select curves to work on, which carries over into key mode. So if in curve mode you shift-select only the Loc curves, when you switch to key mode, you only see the Loc keys.
Also, I correct myself: there arlready is a lock channel button in the Action Editor.
The source file for working on Ipos contains this note from Ton:
“this code feels over-complex, mostly because I choose in the past to devise a system that converts the Ipo blocks (linked to Object, Material, etc), into a copy of that data which is being worked on… However, getting this beast under control was hard, even for me… (ton)”
Which does not inspire my confidence to effect useful change in this portion of the code myself.
In short, the IPO Editor as it currently exists is not really suitable for any further tweaks on top of what is already a rather patchy base. There are some things which also tie in to this - such as the way the whole IPO system works - which doesn’t help the situation (i.e. to add a new IPO curve type, defines need to be added in 5 different places, several of which are nasty static arrays). Another area in which the IPO editor is currently quite dodgy is the whole “context sensitivity/changing” businness it does, as sometimes, it doesn’t seem to work that well (it often results in invalid contexts).
Therefore, IMO, no further work can proceed on this editor until the underlying system is recoded, at which point the editor can also be refactored to be much cleaner.
The sorts of issues that would need to be worked out include:
Is there are need for animatable variables to be separated in strictly enforced groups based on where they come from (i.e. Object transforms can only go in “Object” datablock, Material settings can only go in “Material” datablock, etc. as is the case now)?
Should the ability for IPO blocks to be linked to multiple users be maintained? I get the impression that this is not used that much, and more often than not, is a cause of hinderance for newer users at least (i.e. “HHHEEELLLPPP!!! Why does Object B, duplicated from Object A, stick to Object A when I change the frame?”). It seems that the NLA would be a better place for this…
IPO blocks per datablock, or only for Objects and a few other free-standing datablocks? There are merits to both systems, but an option I’ve been considering is to maintain the current system of datablocks being able to have their own set of animdata that may be overridden by the owning object’s animdata. This does raise some possible issues regarding motion retargetting, and bones/constraints do pose a bit of a problem for this concept too.
In addition to these issues, a new system would need the following things:
Dynamic inclusion of types, which is not dependant on needing ugly static arrays/defines all over the place
Ability to access most settings in Blender (i.e. the infamous “all things animatable”), which can be solved with a data-access api in place, which would also solve the first issue
Only at this point, can the possibility of having data from multiple sources be shown in the IPO editor, and for that data to be filterable, be possible. As the system currently stands, it is strongly adapted to the whole IPO->Action->NLA central dogma. Also, as the name suggests, the animation editors (with the exception being the NLA editor) are strongly based around the concept that they are only acting on a certain datablock at a time.
As such, mixing multiple sources of animation data doesn’t really fit well with this concept. The benefit of such a system, is that there is a clear data-flow (I-A-N). From what I understand of XSI’s system, animation only exists in IPO’s (in Blender terms) belonging per node or such. It can then be ‘stored’ in an “Action”, which can then be used in the “NLA” (or ‘Mixer’ in XSI terms). Now, the accessing of the animation data once it exists as an Action for further editing is not so clear (at least until I do further digging).
Anyways, hopefully that answers a few questions here
Now, regarding various glitches people may have experienced with the IPO editor: once again it is due to the rather archaic (and somewhat confusing) way some things are presented. The various highlighting schemes employed in the “names” panel are quite often confusing, and I too often find myself confused as to what exactly each highlighting state means. This should definitely be addressed in any cleanup work that occurs here.
Regarding the lack of any ability to not show unused ‘channels’ in the “names” panel, the shortness of the names, and the lack of tooltips for them, this is all related to the stupid and insane way the IPO editor is currently put together, with the “editipo” data. One of the reasons for all of this evil static stuff is that it makes it easier for the “rainbow” colouring code to work (among other uses).
As is usual for these discussions, the old Quats vs Eulers issue pops up. The only reliable method for providing any euler support is by physically making bones able to be set to use eulers or quats. It should be noted that Ton is quite opposed to the idea of Eulers, due to their tendency to produce gimble lock, but I guess some tradeoffs need to be made sometimes
There are also some shortcomings in general about the way IPO’s are evaluated. Currently, the situation of animating anything other than object transforms and bones is not ideal, as only those two types of animation are accounted for by the depsgraph. This makes IPO-drivers behave rather dodgy if used on anything other than those two types of anim data, as all of the others are just evaluated in a fixed order based on alphabetical order or such. In future, IPO-drivers need to be completely separated from IPO’s in order to provide a kind of barrier between “Rigging” stuff and “Animation” stuff, making it harder for animators to break rigs. This is a common problem that many people would have run into if working with IPO drivers on certain things (i.e. IK/FK switches)
After looking at xsi ice, and seeing the nodal type programming, and thinking about constraints and influences, and MySQL integration, and frustration with driven shape keys (predominantly the UI I think) it seems to me that a better visual “programming” metaphor might be possible, where you have a input “node” that takes a value-object-channel from some source and puts it into a noodle, which is then influenced/modified by other things (a la mix nodes) that is then timed to happen, all of which is used to determine a final value for that channel at a particular frame.
An issue I have with re-using IPOs is that they are locked to time. Right now I am making a silly little flash animation, and I want a series of lines of text to fade in over ten frames, but in sequence. The current system is handy in that I can make a driven “fade in”, or duplicate the ipo, single user it, and then grab the keys and move them over 10 frames. But, it seems silly, like I should be able to define an object called “Fade in Text” and then just say when I want that text to fade in, much like OOP. Drivers are a good work-around, but they require yet another object with yet another ipo to control the “when”.
In future, IPO-drivers need to be completely separated from IPO’s in order to provide a kind of barrier between “Rigging” stuff and “Animation” stuff, making it harder for animators to break rigs. This is a common problem that many people would have run into if working with IPO drivers on certain things (i.e. IK/FK switches)
I second this. A way of visualizing the rigging depsgraph like that one in XSI would prevent a lot of common mistakes in rigging. E.g. IK-constraining some parent bones to its children, and getting circular dependencies. Obviously this is a mistake on the riggers part, but its not easy to visualize this with just a 3d viewport.
And as Papasmurf said, the driven key setup works, but is very limited.
