PDA

View Full Version : Scene Editor Keyframe management question



drclare
07-12-2003, 02:07 PM
How come when i try to drag one of the master keyframes in the scene editor it drags the whole track, instead of just the one keyframe. What i end up having to do is opening up the object and dragging each properties keyframe. The manual says that you can drag an individual keyframe, but it does not work for me. Is this a mac bug or something?

As a side note, does anyone use the KeyTrak plugin from spatial designs? It is by the same person who created motionmixer. It wish the current scene editor was like this.

drclare
07-15-2003, 12:48 AM
Does anyone know what's going on with this?

toby
07-15-2003, 03:04 AM
actually that's one thing I never use the scene editor for - are you sure the manual wasn't refering to the graph editor?

Beamtracer
07-15-2003, 04:32 AM
Why drag all the keyframes of an object? Why not use the Scene Editor's "shift Keyframes" function in the menu, and get a precise amount?

I agree that the graph editor is a better place to tinker with keyframes. For some strange reason, vital menus are secretly hidden in the graph editor. Hold down control+shift, then click on one of the graphs.

DaveW
07-15-2003, 05:51 AM
How come when i try to drag one of the master keyframes in the scene editor it drags the whole track, instead of just the one keyframe. What i end up having to do is opening up the object and dragging each properties keyframe. The manual says that you can drag an individual keyframe, but it does not work for me. Is this a mac bug or something?


That purple row of keys can only be shifted all together, you have to expand it to the individual channels to drag a key frame. You can only drag one key from one channel at a time, and you need to click directly in the middle of the little + (it should turn into a yellow dot) or you'll drag all the keys. This function of the scene editor is NewTek's very poor attempt at dopesheet functionality. You should learn to use the graph editor for this sort of thing until NewTek figures out how to make a real dopesheet or someone makes a plugin for it.





I agree that the graph editor is a better place to tinker with keyframes. For some strange reason, vital menus are secretly hidden in the graph editor. Hold down control+shift, then click on one of the graphs.

None of the vital menus are hidden in the ctrl-shift menus. ctrl-shift-rmb is the selection menu (first menu on the top-left), ctrl-shift-mmb is the display menu (fith menu on top-left) and ctrl-shift-lmb is the keys menu.

drclare
07-15-2003, 10:58 AM
Well, im not talking about dragging all of the keyframes of an object. For that i do use shift or scale keys. Im talking about moving the keyframes of all properties of an object at a given keyframe. Sometimes i just want to change the timing of something, say by having the object's motion end 2 frames earlier. So if the object has keyframes for it's position and rotation properties i have to drage the keyframes of each property. In the manual, on page 12.5 "The Scene Editor" under "Adjusting Channels" there is a "Note: You can also drag keys on the master channel, which will affect only the appropriate underlying channels." So i take it to mean that you should be able to drag a keyframe on the top, purple bar, and the will move the keys of the channels under it that have keys.

I do use the graph editor for playing with the values of keyframes, but for changing timing values i think if the scene editor worked they way it says it should, it would be better.

eblu
07-15-2003, 11:18 AM
the scene editor always seemed to me to be a "me-too" feature. They quickly threw it together, added functionality that was untested, and not altogether useful, just so they could round out the specs on the Box that LW shipped in.

unfortunately so does the graph editor. and these are the 2 main tools for timeline/ keyframe manipulation.

at the moment all i use the scene editor for is setting visibility of objects, and parenting them. If i have to scale keys or shift them, then I begrudgingly attempt it, but only after i have saved a copy of my scene under a different name.

and in the graph editor... I have one of the short keyboards so i don't know how it works with an extended keyboard... just try selecting a keyframe and then hitting the delete key. It brings up the standard delete key panel. Not correct behavior. so in order to delete a key I have selected in the graph editor, I must use a menu command which has No apparent shortcut, or any way to add one.

its gonna take more than spit and polish to clear up the mess made by these "tools".

Newtek, take note:
this thread is a discussion by people who have been mislead by the appearance of functionality, and people who are living with the reality. there is no reason why the scene editor couldn't be a fully functional dope sheet, especially since it bears a striking and misleading resemblance to one.

DaveW
07-15-2003, 01:11 PM
drclare: you're right that if the scene editor worked like a real dopesheet it would be better for adjusting timing than the graph editor, but it would take a whole lot more than just fixing the broken key-dragging.

eblu: You think LW's graph editor feels quickly thrown together? I would strongly disagree. It's one of Layouts stronger points. I've used Cinema4d, Messiah, Maya, and XSI and I think LW's graph editor is better than all of them with one exception, and that is the speed of item tracking/selection. The delete key issue you're having could be either a keyboard problem or a Mac problem. But if you want to assign shortcuts for the graph editor, go to the layout->interface->edit keyboard shortcuts and pick graph editor from the window menu at the top of the panel.

eblu
07-15-2003, 02:22 PM
dave,
the workflow for the graph editor is terrible.
its very difficult to change the graph editor's live channels, without closing the window. this is a deal-breaker for me. It leads to perceptual problems that Other packages do not have.

for example:
I can have the animation channels of one object loaded in the graph editor while having another object selected. Because the time scrubber of the main window and the graph editor are linked, it incorrectly suggests through UI feedback that all of the data in the main window and the Graph editor are updated live, and so the user is fooled into thinking he is editing the animation of the object he has selected in the main window. This is a Huge No - no, if this was handed in in a UI programming course it would Fail outright.

I agree with you about the speed, except to say that it has been getting better.

thanks for the tip about the shortcuts... just another design flaw in the UI. That pull down "window" menu is inappropriate there. Theres no options for the scene editor, none for MotionMixer, or any of the numerous panels. Logically, the menu should be removed and its information converted into a heading in the list at the left of the panel.

I can nitpick the graph editor all day, but it is essentially usable, there are other areas in LW that need some serious attention. I just think it bears pointing out that The UI is at fault here. The scene editor sells itself as a dope sheet, and the graph editor displays Feedback that is misleading.

DaveW
07-15-2003, 03:30 PM
Originally posted by eblu
dave,
the workflow for the graph editor is terrible.
its very difficult to change the graph editor's live channels, without closing the window. this is a deal-breaker for me. It leads to perceptual problems that Other packages do not have.


What do you think is so difficult about changing live channels? You can create favorites, get/add layout selection, track layout selection, or drag/drop from the channel list below the bin. There's also the filtering, invert selection, removing unused channels, filtering static channels, ect.



for example:
I can have the animation channels of one object loaded in the graph editor while having another object selected. Because the time scrubber of the main window and the graph editor are linked, it incorrectly suggests through UI feedback that all of the data in the main window and the Graph editor are updated live, and so the user is fooled into thinking he is editing the animation of the object he has selected in the main window. This is a Huge No - no, if this was handed in in a UI programming course it would Fail outright.

I don't find that an issue at all. I know what channels are being edited in the graph editor and I would hate it if it changed my channel selection based on what I had selected in Layout. If you prefer working that way then just turn on item tracking. I'd rather use the get/add options for more control.

eblu
07-15-2003, 10:41 PM
"What do you think is so difficult about changing live channels?"

in many other packages, the 2-d representation of animation in spline format, is treated as the same kind of view as a 3-d view. They both share the same selection information, but display different kinds of data. Approaching the design problem like this, you:
1. make a much cleaner/simpler interface.
2. dont neccessarily need a giant window that covers up your main window, all the time btw...
3. get rid of DOZENS of extraneous keystrokes, which changes the steep learning curve into A Much More Shallow learning curve.

this kind of design is essential. It brings users closer to the data and puts the interface where it belongs from first glance, in the background.

"I don't find that an issue at all. I know what channels are being edited in the graph editor and I would hate it if it changed my channel selection based on what I had selected in Layout. If you prefer working that way then just turn on item tracking. I'd rather use the get/add options for more control."

i can cede the point that its subjective, people like different things. Its funny that even though you are defending this approach, you take the time to illustrate my point. You have to keep the graph editor's selected object in your mind while you work. This is just one more piece of data that should be transparent to the user, negligent, in the background, taken care of.

for me I have been using dozens of channel editors for many years, and the LW graph editor in its current incarnation, is the least of the rest. In my opinion, LW has taken a giant leap backwards from the straight-forward and clean approach that Lightwave used to use. Sure its more flexible, but its UI is cumbersome, extraneous, and almost at its limits.
but my original point is that the UI is misleading. And that is not opinion. The time scrubber for both the graph editor and the main window are linked, this is misleading about the rest of the "features" of the graph editor. While this may not stymie an experienced Lightwaver, its is:
1. poor design
2. confusing for people who have too much to contend with already (newbies), creating a steeper learning curve,
3. and a good example of the UI design challeneges facing lightwave, as Newtek moves forward.

I know I'm suggesting that the graph editor be re-designed, but I dont really like that idea myself (i'm used to it now, even though its got problems). but when push comes to shove, and someone has difficulty with a "feature" of LW that is obviously poorly designed, I have no qualms about calling it what it is. I like to comfort the poor guys and tell them that they aren't stupid, it really is confusing. And if Newtek gloms on to my preaching, and suddenly starts listening to my heavy handed suggestions, then all the better for them, and all the better for me as well.

toby
07-15-2003, 11:51 PM
" The time scrubber for both the graph editor and the main window are linked, this is misleading about the rest of the "features" of the graph editor"

I don't get it, how is it misleading? You want the selection to be linked, (you can set it that way) but you don't want the timescrubber to be linked? If it wasn't linked, how would you see any changes you made in the graph editor? You couldn't see what you were doing!?

LW's graph editor is the 1st I ever used, which puts me behind in experience but I have to mention that I never had any problem learning it.

I respect your opinion I just don't understand it or am missing something -

DaveW
07-16-2003, 12:28 AM
So, what is "unclean" about the current interface? It all seems pretty straight-forward to me. The graph editor doesn't need to cover up your entire window, it can be resized, minimized, hidden, or moved to a seperate monitor. That's the way most other graph editors work too. I would like to see LW's graph editor be available as a viewport mode (along with all the other panels), but you can size it so it only takes up the same amount of space as if it was in a viewport. I like to keep it on my second monitor so that it's always available and never in the way. What are the dozens of extraneous keystrokes?

As for keeping the object selections in my mind, no I don't need to do that. The item that the channel belongs to is listed right there in the channel bin. In addition to that, I usually work with favorite sets, so I know that if I'm working on the hand then even though I only have the index finger bones selected, the graph editor will contain all the rotation channels for all the fingers of that hand. When I move to the legs, I use the favorite set that contains the leg channels. But like I said before, if you want it to work like other packages all you need to do is turn on item selection tracking. There are projects where I turn that on, but usually I find it annoying. It's good to have options.

I don't see the Layout/Graph editor timeline as being misleading at all. The channel bin clearly states what is being shown in the graph editor, and if you want it to show the same items you have selected in Layout, there is a very simple option that turns it on. Being a newbie to LW or 3d in general isn't an excuse for not reading the manual or even looking at what options are available when you click that big button clearly labeled "options".

I'm curious to know exactly what you think is wrong with the graph editor, and what packages have graph editors that you feel are superior. I can understand that you would like a different graph editor better, but you seem to have a very low opinion of LW's graph editor and I can only assume it's because you haven't learned how to use LW's editor efficiently. I had a similar experience going from Maya's dopesheet editor to XSI's, XSI's dopesheet editor workflow seems very odd and not well thought out at first, so I decided to spend a few hours focusing soley on XSI's dopesheet editor so I could learn all the ins and outs. By the end of the day I decided XSI's dopesheet editor is better than Maya's. You might not come to the same conclusion about LW's graph editor, but I think that if you learn to use LW's graph editor the way it wasmeant to be used, you might realize it's not a bad way of doing things, just different.

eblu
07-16-2003, 08:55 AM
rather than use many words...
I thought i'd supply a picture.

it is a screen capture of the current graph editor, and a quick mockup that is blended more cleanly into LW's interface.
things to note:
theres no time scrubber in the mockup, its extraneous because that graph editor is Owned by the main window, and shares the time scrubber with every other view.
there are less controls in the mockup. Since the mockup is tied into the rest of the interface, it simply works with the tools you already know.
the mockup's main window takes up less room that the Two windows in the screen capture, and still gives you more Graph to work with.

the way the graph editor has been designed, it shares nothing in common with the rest of the application. When a user encounters it for the first time, he must learn from scratch how to use it. There is no leveraged learning going on, there is no advantage from learning the rest of the package. It is essentially a mini program, a plug-in. It is exactly the opposite of what Newtek has been working towards in Modeller. Every kind of data in Modeller has been carefully made so that each tool works with it (as always, there are exceptions). When you modify a UV map, you use the same tools that you always used, in a view that is part of the main window. When you work with skelegons, all of the modification tools work. The result of this? the learning curve is near flat for those elements of the program, and the tools are now more useful than ever, without becoming more complex.


its funny. I look at the schematic view (in Lightwave), and its very much the way I think it should be, a child view of the main window, no extraneous options, confusing tabs, no new tools to learn.... simple straight forward design and a seriously different way of looking at the same data, without inventing new poorly thought out UI.
the odd thing is, its out of place in Lightwave. Without it, we can say that Newtek reserves the viewports only for 3d opengl views, or that Newtek creates complete solutions to each individual design problem (motionmixer, scene editor, graph editor, surface panel, MD, ParticleFX, etc...) and thats the way it is like it or not.
But the schematic view IS there, the viewports are perceived as generic rectangles in which to display generic information, and somebody likes the idea of one main window for most of the data display. Hopefully Newtek isnt afraid to break with the past in order to shore up the future.

DaveW
07-16-2003, 01:18 PM
I half disagree with your statement that the graph editor shares nothing in common with the rest of LW and there is no advantage from learning the rest of the program. The graph editor is almost like a seperate program within Layout, so you're right that it functions a little differently. But it also works like the rest of Lightwave, with the same menu and field concepts, an info window that tells you how to use the current tool, and many of the same shortcut keys. It's not like being in a totally foreign environment, it works just like the rest of Lightwave.

I like your concept screenshot, this is what I was saying when I said the graph editor and all the other panels should be available as viewport options. I do think the graph editor specific menus and tools should be in the graph editor interface, it would slow down workflow to keep switching to the graph editor tab on the Layout interface to get to your graph editor tools/menus, then switching back to the previous tab to continue editing in the other viewports; I have limited experience with Cinema4d's graph editor but when I did use it I hated having to mouse around the whole interface on two monitors to get to everything I needed in the graph editor; with LW's graph editor everything there for quick access. The graph editor would also need to be detatchable so you can move it to another window. That's one thing about Messiah's interface that bugs the hell out of me. Their graph editor isn't detatchable; it's a great setup for single-monitor users because it saves a lot of space, but it really sucks when you have a second monitor and no way to take advantage of it. That's why I like XSI and Maya, you can have it both ways.

BTW, on your screenshot of the way LW currently works, you do realize what those purple arrows are for right? Turn on the Layout item tracking, hide the channel bin with the purple arrow(the message window will tell you what channel you're working on and you can alt-rmb to pick background curves) and you can usually get away with hiding the tabs at the bottom too; rmb on a key and you can pick the curve type, and if the curve is TCB you can use ease in/out to set the tension to 1. Once you've got everything roughed out you can show the tabs again and fine tune the TCB splines if necessary, but most of the time a tension of 1 is what you need, anything more complicated that would require using the continuity or bias and it's usually easier to just use bezier curves.

eblu
07-16-2003, 02:01 PM
yep thats what those arrows are for.
but its a half a$$ed solution, because most of the functions you Can hide/show are an important part of the workflow of the graph editor. So hiding/showing them is Counter-intuitive, takes extra keystrokes, and slows down the process of working directly with the data. In addition, because the graph editor is a mini program all to itself, it duplicates much of the functionality of the main window without any benefits. the time scrubber is a wonderful example of this. Just consider the space being wasted by two time scrubbers, you cant use both of them, and they both display the same data in a very similar way. and as far as i know (havent looked into this) you cant hide either of them. The options for the graph editor are not apparent from anywhere but in the top of the Graph editor window, duplicating the work already put into making an options panel for the main app, and undermining the idea that Options are centrally located in the "layout" menu in the toolbar of the main window (period).
the graph editor's window itself Always stays on top of the main window and because it was designed to duplicate many of the functions of the main window, it takes up much more space than is strictly necessary.

daveW,
there are some things i like about the graph editor as it stands, many of the points that you make are valid. I think there is a lot of room to debate what elements are necessary in a graph editor that has been welded to the main window, and I really dont mind working in it... in short, it works. but there is a difference between something that works and something that is well designed. if the guys who are responsible for it were students of mine, I'd send them back to the drawing board. Its an example of "code bloat", and "counter intuitive design". It shows no understanding of "Memory Muscle", classic UI design principles, or of code re-use. Its great work for 1989, not for 2003.

anyway, have a good one,
eblu

toby
07-16-2003, 02:03 PM
hey! I want it both ways!

I think we can all agree that the viewport option would be great for everyone - feature request!

toby
07-16-2003, 02:10 PM
It seems like the improvements you would make would make it a pain to have the graph editor on a second monitor - no scrubber and all the controls on the main window - and the option to have it both ways would just be more 'code bloat'

DaveW
07-16-2003, 03:19 PM
Originally posted by eblu
yep thats what those arrows are for.
but its a half a$$ed solution, because most of the functions you Can hide/show are an important part of the workflow of the graph editor. So hiding/showing them is Counter-intuitive, takes extra keystrokes, and slows down the process of working directly with the data.

The tabs can be hidden most of the time, the only time you really need them there are when you're working on expressions or adding a modifier. For TCB splines a tension of 1 usually all you need, and that can be done by selecting the key(s) you want to edit and rmb on one and pick ease in/out. When the tension needs to be something else, you can keep it at 1 or 0 until you do a beauty pass, select all the keys you want to edit, pop up the curve tab, apply your changes to all keys in one fell swoop. Usually if you need to edit the continuity or bias, it ends up being easier to just change to curves to bezier which can also be done from the rmb menu.






In addition, because the graph editor is a mini program all to itself, it duplicates much of the functionality of the main window without any benefits. the time scrubber is a wonderful example of this. Just consider the space being wasted by two time scrubbers, you cant use both of them, and they both display the same data in a very similar way.


The time scrubber in the graph editor takes up no extra space at all, and the benefit is that you can scrub with it more quickly than the Layout scrubber because you don't need to wait for Layout to update. It also gives you a faster visual representation of what the current frame is. When the graph editor is detatched and on a second monitor it would slow workflow to have to keep going to the first monitor to move the time scrubber.




The options for the graph editor are not apparent from anywhere but in the top of the Graph editor window, duplicating the work already put into making an options panel for the main app, and undermining the idea that Options are centrally located in the "layout" menu in the toolbar of the main window (period).


I agree with you on this, all the options should be available from a central location.



the graph editor's window itself Always stays on top of the main window and because it was designed to duplicate many of the functions of the main window, it takes up much more space than is strictly necessary.


Which functions duplicate functions of the main window? All I can think of are the pan/zoom buttons, but those don't take up extra space because it's in the same space as the collapse button and the menus. Getting rid of the menus would interrupt workflow imo, especially if you were to detatch the graph editor and move it to a different monitor.



I think there is a lot of room to debate what elements are necessary in a graph editor that has been welded to the main window, and I really dont mind working in it... in short, it works. but there is a difference between something that works and something that is well designed.


Different strokes for different folks, as they say. I've got a lot of experience with Messiah and Maya's graph editors, and a fair amount of experience with XSI and Cinema 4D's, and aside from speed issues I think LW's is better than all of them.

What app do you think has a well designed graph editor? Messiah uses the welded graph editor like you want, but I found that having the graph editor options on one of the main tabs rather than within the graph editor slowed down the workflow because I had to keep switching tabs, and no dual monitor support is a huge waste of space. Cinema 4D has a floating graph editor but I found myself having to leave the graph editor too often and with it on a second monitor that really slowed workflow. Maya and XSI both have their graph editors like LW's, with all the options/menus directly in the graph editor, but unlike LW they can show the graph editor in a viewport, saving space for single-monitor users. Their channel bins aren't quite as versatile as LW and Messiah's though, but that's a bigger problem for the dopesheet editor than the graph editor.

I'm no programmer, but I don't see how LW's graph editor is code bloat. Moving the menus and options to somewhere else in the interface would still take up the same amount of code wouldn't it? I think LW's problem is inefficient code, and it's throughout the whole app not just the graph editor. It's far less responsive than any other 3d app I've used.