Thread: [K3d-development] Animation
Brought to you by:
barche
From: Daniel G. <ove...@ho...> - 2003-02-21 13:22:12
|
To what extent is animation currently supported in K3d? I can't seem to figure out how to animate position/orientation of objects or the camera, is this not implemented yet? I saw some brief mention of paths in the documentation, but no mention of how to create or use them, are they motion paths for animation? Thanks for any info. Dan _________________________________________________________________ |
From: Bart J. <bar...@li...> - 2007-07-14 23:06:17
|
Hello, I have added a short description of the current state of the animation code to the end of: http://www.k-3d.org/wiki/Animation_Design Comments welcome, especially on the "Issues" paragraph. regards, Bart |
From: Timothy M. S. <ts...@k-...> - 2007-07-20 23:45:04
|
Bart Janssens wrote: > I have added a short description of the current state of the animation code to > the end of: > > http://www.k-3d.org/wiki/Animation_Design > > Comments welcome, especially on the "Issues" paragraph. > Bart: This is a great prototype - it opens-up many interesting questions. Some random thoughts: * As a general observation, we should be careful not to allow the limitations of the current Node Properties Panel to drive the design. I can envision multiple specialized controls and panels for manipulating track data. As a concrete example, I have my doubts about whether keyframes (or parts of keyframes) should be properties, or whether they should be represented by some more specialized data structure. * Putting icommand_node in a property is some cool hacking, but not a long-term viable option. An observation about OO programs is that their components can be broken-down into three broad categories: state (K-3D properties), behavior (K-3D interfaces/nodes) and events (K-3D command-node commands). Putting a command-node in a property mixes metaphors, and doesn't make any sense in the context of the pipeline. A better solution (one that I've had in mind for awhile) is for a node to implement icommand_node and provide some API (either part of icommand_node or in a separate new interface) to enumerate over the set of available commands. * I like the notion of interpolators as separate strategy nodes, but they will have to be handled on a per-track-segment basis rather than per-track. There is a much tougher issue regarding the relationship between keyframes and control points. Many useful interpolators will require varying numbers of control points adjacent to keyframes to function - think Bezier spline interpolation. This is one reason that my scripted animation stuff used NURBS as the underlying data structure - NURBS provided a lot of flexibility to handle differing interpolations, while the whole thing could be treated in a consistent way. * The suggestion for easy "Create Track" functionality in the plug icons makes perfect sense. Cheers, Tim Cheers, Tim |
From: Bart J. <bar...@li...> - 2007-07-23 21:46:23
|
On Tuesday 17 July 2007 06:38:56 Timothy M. Shead wrote: > * Putting icommand_node in a property is some cool hacking, but not a > long-term viable option. An observation about OO programs is that their > components can be broken-down into three broad categories: state (K-3D > properties), behavior (K-3D interfaces/nodes) and events (K-3D > command-node commands). Putting a command-node in a property mixes > metaphors, and doesn't make any sense in the context of the pipeline. A > better solution (one that I've had in mind for awhile) is for a node to > implement icommand_node and provide some API (either part of > icommand_node or in a separate new interface) to enumerate over the set > of available commands. I've put a proposal to implement this at http://www.k-3d.org/wiki/CommandSet This ensures actual command execution will always happen through the established icommand_node interface. Cheers, Bart |
From: Timothy M. S. <ts...@k-...> - 2007-07-24 01:07:19
|
Bart Janssens wrote: > I've put a proposal to implement this at http://www.k-3d.org/wiki/CommandSet > This ensures actual command execution will always happen through the > established icommand_node interface. Upon deeper reflection, I'm regretting this suggestion. There's nothing wrong with your proposal, it's just that icommand_node is the wrong tool for the job, and I should have recognized that sooner, my apologies ;) The problem with icommand_node is that it's a very "low bandwidth" way to communicate capabilities to the UI layer - in the case of CommandSet, all you get is a name, which you can slap on a button. What if you want to provide icons? You could add icons to the CommandSet interface, but what about tooltips, etc? What about disabling commands based on state? Pretty soon, the UI layer has crept down into the plugin implementations. Further, you can't reasonably decompose the interface to a track into just events. Imagine the hypothetical curve editor - you'll have to have access to the underlying curve data to display and modify it graphically. So, what we really need to do is start working on higher-level animation interfaces, and let the UI adapt itself to them. Off the top of my head, I could imagine "ikeyframable" which manages a collection of keyframes with add/delete functionality, then supplemental interfaces for accessing interpolators, control points, etc. These interfaces might (or might not) be templated based on keyframe type. Cheers, Tim |
From: Bart J. <bar...@li...> - 2007-07-24 06:12:38
|
On 7/24/07, Timothy M. Shead <ts...@k-...> wrote: > So, what we really need to do is start working on higher-level animation > interfaces, and let the UI adapt itself to them. Off the top of my > head, I could imagine "ikeyframable" which manages a collection of > keyframes with add/delete functionality, then supplemental interfaces > for accessing interpolators, control points, etc. These interfaces > might (or might not) be templated based on keyframe type. > OK, if I understand correctly, I would then just leave the current track without the buttons for keyframe deletion and manual key setting, and leave that functionality to a dedicated keyframe panel (using the new UI module system), that would be implemented on top of the ikeyframable interface? I think the keyframe "time" and "value" should still be exposed as properties, since this allows them to be connected to other inputs, which is something Joe also suggested in his animation design writeup. regards, -- Bart |
From: Bart J. <bar...@li...> - 2007-07-24 20:35:44
|
On 7/24/07, Bart Janssens <bar...@li...> wrote: > On 7/24/07, Timothy M. Shead <ts...@k-...> wrote: > > > So, what we really need to do is start working on higher-level animation > > interfaces, and let the UI adapt itself to them. Off the top of my > > head, I could imagine "ikeyframable" which manages a collection of > > keyframes with add/delete functionality, then supplemental interfaces > > for accessing interpolators, control points, etc. These interfaces > > might (or might not) be templated based on keyframe type. > > > > OK, if I understand correctly, I would then just leave the current > track without the buttons for keyframe deletion and manual key > setting, and leave that functionality to a dedicated keyframe panel > (using the new UI module system), that would be implemented on top of > the ikeyframable interface? > As a follow-up, I'm thinking of implementing this as an addition to the timeline, with an optional display of a user-defined number of tracks under the timeline, where each track could be represented using a Gtk::HScale widget with multiple markers. There would also be a context menu to manually add/remove keys. I'll have to study the GTK API on how to implement this, though. regards, -- Bart |
From: Timothy M. S. <ts...@k-...> - 2007-07-26 00:40:01
|
Bart Janssens wrote: >> OK, if I understand correctly, I would then just leave the current >> track without the buttons for keyframe deletion and manual key >> setting, and leave that functionality to a dedicated keyframe panel >> (using the new UI module system), that would be implemented on top of >> the ikeyframable interface? >> > > As a follow-up, I'm thinking of implementing this as an addition to > the timeline, with an optional display of a user-defined number of > tracks under the timeline, where each track could be represented using > a Gtk::HScale widget with multiple markers. There would also be a > context menu to manually add/remove keys. I'll have to study the GTK > API on how to implement this, though. For prototyping purposes, I'd encourage you to start your own new panel. Copy 'n' paste the original timeline as a starting-point, and we can adopt your modified version as the default once it's matured. You can use "Layout > Save Layout" to create your own layout during development, I'm doing the same thing with the Pipeline Panel. Cheers, Tim |
From: Timothy M. S. <ts...@k-...> - 2007-07-26 00:35:04
|
Bart Janssens wrote: > On 7/24/07, Timothy M. Shead <ts...@k-...> wrote: > >> So, what we really need to do is start working on higher-level animation >> interfaces, and let the UI adapt itself to them. Off the top of my >> head, I could imagine "ikeyframable" which manages a collection of >> keyframes with add/delete functionality, then supplemental interfaces >> for accessing interpolators, control points, etc. These interfaces >> might (or might not) be templated based on keyframe type. >> > > OK, if I understand correctly, I would then just leave the current > track without the buttons for keyframe deletion and manual key > setting, and leave that functionality to a dedicated keyframe panel > (using the new UI module system), that would be implemented on top of > the ikeyframable interface? > > I think the keyframe "time" and "value" should still be exposed as > properties, since this allows them to be connected to other inputs, > which is something Joe also suggested in his animation design writeup. Seems reasonable, with the caveat that there's no reason why the properties panel can't test for ikeyframable and alter its functionality accordingly. You can see an example of this with camera / render engine nodes, where we display buttons for rendering based on those interfaces. Cheers, Tim |
From: Timothy M. S. <ts...@k-...> - 2007-07-21 00:34:54
|
I am resending this, it didn't seem to make it to the list the first time ... Bart Janssens wrote: > I have added a short description of the current state of the animation code to > the end of: > > http://www.k-3d.org/wiki/Animation_Design > > Comments welcome, especially on the "Issues" paragraph. > Bart: This is a great prototype - it opens-up many interesting questions. Some random thoughts: * As a general observation, we should be careful not to allow the limitations of the current Node Properties Panel to drive the design. I can envision multiple specialized controls and panels for manipulating track data. As a concrete example, I have my doubts about whether keyframes (or parts of keyframes) should be properties, or whether they should be represented by some more specialized data structure. * Putting icommand_node in a property is some cool hacking, but not a long-term viable option. An observation about OO programs is that their components can be broken-down into three broad categories: state (K-3D properties), behavior (K-3D interfaces/nodes) and events (K-3D command-node commands). Putting a command-node in a property mixes metaphors, and doesn't make any sense in the context of the pipeline. A better solution (one that I've had in mind for awhile) is for a node to implement icommand_node and provide some API (either part of icommand_node or in a separate new interface) to enumerate over the set of available commands. * I like the notion of interpolators as separate strategy nodes, but they will have to be handled on a per-track-segment basis rather than per-track. There is a much tougher issue regarding the relationship between keyframes and control points. Many useful interpolators will require varying numbers of control points adjacent to keyframes to function - think Bezier spline interpolation. This is one reason that my scripted animation stuff used NURBS as the underlying data structure - NURBS provided a lot of flexibility to handle differing interpolations, while the whole thing could be treated in a consistent way. * The suggestion for easy "Create Track" functionality in the plug icons makes perfect sense. Cheers, Tim Cheers, Tim |
From: Romain B. <rom...@ya...> - 2003-02-21 14:14:45
|
There is no motion path yet, but you can animate most parameters through 'channels'. All is explained in tutorials you can run in Help menu > Tutorials. Cheers, Romain > To what extent is animation currently supported in > K3d? I can't seem to figure out how to animate > position/orientation of objects or the camera, is > this not implemented yet? I saw some brief mention > of paths in the documentation, but no mention of > how to create or use them, are they motion > paths for animation? Thanks for any info. > Dan __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ |
From: Brett W. M. <bm...@ch...> - 2003-02-21 14:47:02
|
On Fri, 2003-02-21 at 08:22, Daniel Gonzalez wrote: > To what extent is animation currently supported in K3d? I can't seem to > figure out how to animate position/orientation of objects or the camera, is > this not implemented yet? I saw some brief mention of paths in the > documentation, but no mention of how to create or use them, are they motion > paths for animation? Thanks for any info. This is all supported in K-3D. A sample animation of a object moving across a surface with a panning camera is on the website. How did you try to animate your object or camera? The simplest way to do it is to create a Transformer object and then make the objects you want to move children of that object. You can do the same for the camera also. When you open the Transformer dialog, you'll see several paramters you can animate. Each parameter has 3 boxes -- one is starting value, one is current value (it changes as you preview the animation), and the third is final value. You can modify these values manually or open the channel (arror button to the right) and create a curve to designate the motion (the object doesn't follow this curve, the curve is an indication of how the paramter changes over time). -- Brett |
From: Timothy M. S. <ts...@k-...> - 2003-02-21 19:16:46
|
Daniel Gonzalez wrote: > To what extent is animation currently supported in K3d? I can't seem to > figure out how to animate position/orientation of objects or the camera, > is this not implemented yet? I saw some brief mention of paths in the > documentation, but no mention of how to create or use them, are they > motion paths for animation? Thanks for any info. > Dan As the rest of the gang has mentioned, you can animate position, orientation, and scale through the Transformer object. I'll just point out that the Transformer object (misleadingly) has some obsolete controls that imply a path-following capability - ignore 'em. I'm surprised no-one has called us on this before ;) Cheers, Tim |