## gdalgorithms-list

 [Algorithms] The whole frame zero thang.. From: John Connors - 2006-04-05 14:34:08 ```Frame zero. It drives me nuts. What am I talking about? Well, for the sake of argument, lets suppose I have a 4 - frame, keyframed animation, with the simulation and the renderer stepped at 1/30sec per frame. The artist sees 4 frames in Maya/Max/Blender/WhizzosAtomicModeller t +-----------+-----------+-----------+------------+ | | | | | +-----------+-----------+-----------+------------+ 0 1 2 3 4 To play a complete animation, we have to render at 5 intervals, starting with t=0 and ending with t=4. Great, so thats what you do, after all, the artists want to see *all* of their lovely animation, right? So along comes someone else, actually observing the behavior of the animation and says "hey, our x frame animation is playing over x+1 frames", and the guy/thing/car is overshooting their turn/cutscene spot/fov At this point a number of things can happen. 1> We rejig the logic/calling order so that animation_update() always gets called before animation_render() and we never see the t=0 frame. Everything seems right. There's no "unstated state", the animation is always playing - that has to be right, no? Er..as along as none of the more bright artists realize and get upset (rightly) that they are losing a frame of their lovingly hand-crafted animation every time. 2> We add one to the number of frames of animation every time the AI asks what the frame count is going to be. Velocities, etc get scaled accordingly. This can annoy AI people, if things take a frame longer than they think they will, especially when doing things like cornering. The API/Interface has to be bulletproof. 3> The opposite of 1>. Have every animation signal its desire to terminate a frame before the end and never play t=4 except either to hold a pose, or blended in with another animation that is transitioning in. I've worked in shops that have used each. My personal preference is probably 3, but I've met people quite vehement about 1. I have never had the chutzpah to pull 2, myself, but I've seen people do it successfully. Before I write yet another animation engine (properly, this time, I always tell myself!) I'd like to sound out the opinions of the crowd. Anyone have any strong arguments pro and con for any of these three? -- +--------------------------------------------------------+ |Cyborg Animation Programmer | johnc@...| |http://badbyteblues.blogspot.com -----------------------| +--------------------------------------------------------+ ```
 Re: [Algorithms] The whole frame zero thang.. From: Jonathan Blow - 2006-04-05 14:50:17 ```I don't see that there's a big deal here. Call the animation that you are talking about (the one that has 4 frames) animation A. What happens when animation A finishes playing on your object? Ideally you switch to some animation B, which matches up precisely to animation A at its endpoint. (So the keyframe at t=4 of A is the same as the keyframe at t=0 of B). In practice this is not always true, but it's the animation system's job to do extra legwork and make up for the fact that animations don't always meet. So you can assume that that part works, and think of an ideal world where they do always meet. In that case, clearly a right answer is just to drop the last frame of A, because it is duplicated at the beginning of B anyway. So you play A0, A1, A2, A3, B0, B1, ... And because A4 and B0 are the same, everything is great. John Connors wrote: > > Frame zero. It drives me nuts. What am I talking about? Well, for the > sake of argument, lets suppose I have a 4 - frame, keyframed > animation, with the simulation and the renderer stepped at 1/30sec per > frame. The artist sees 4 frames in Maya/Max/Blender/WhizzosAtomicModeller > > t > +-----------+-----------+-----------+------------+ > | | | | | > +-----------+-----------+-----------+------------+ > 0 1 2 3 4 > > To play a complete animation, we have to render at 5 intervals, > starting with t=0 and ending with t=4. Great, so thats what you do, > after all, the artists want to see *all* of their lovely animation, > right? > > So along comes someone else, actually observing the behavior of the > animation and says "hey, our x frame animation is playing over x+1 > frames", and the guy/thing/car is overshooting their turn/cutscene > spot/fov > > At this point a number of things can happen. > > 1> We rejig the logic/calling order so that animation_update() always > gets called before animation_render() and we never see the t=0 frame. > Everything seems right. There's no "unstated state", the animation is > always playing - that has to be right, no? Er..as along as none of the > more bright artists realize and get upset (rightly) that they are > losing a frame of their lovingly hand-crafted animation every time. > > 2> We add one to the number of frames of animation every time the AI > asks what the frame count is going to be. Velocities, etc get scaled > accordingly. This can annoy AI people, if things take a frame longer > than they think they will, especially when doing things like > cornering. The API/Interface has to be bulletproof. > > 3> The opposite of 1>. Have every animation signal its desire to > terminate a frame before the end and never play t=4 except either to > hold a pose, or blended in with another animation that is > transitioning in. > > I've worked in shops that have used each. My personal preference is > probably 3, but I've met people quite vehement about 1. I have never > had the chutzpah to pull 2, myself, but I've seen people do it > successfully. > > Before I write yet another animation engine (properly, this time, I > always tell myself!) I'd like to sound out the opinions of the crowd. > Anyone have any strong arguments pro and con for any of these three? > ```
 RE: [Algorithms] The whole frame zero thang.. From: Robert Dibley - 2006-04-05 15:04:12 ```Alternatively don't think of frames, but times, use interpolation between frames, and allow longer gaps between them. That way it even works when your frame rate varies, when you have to slow down and animation slightly, when you have to rewind one, all kinds of things. Robert > -----Original Message----- > From: gdalgorithms-list-admin@... [mailto:gdalgorithms- > list-admin@...] On Behalf Of Jonathan Blow > Sent: 05 April 2006 15:50 > To: gdalgorithms-list@... > Subject: Re: [Algorithms] The whole frame zero thang.. > > I don't see that there's a big deal here. > > Call the animation that you are talking about (the one that has 4 > frames) animation A. What > happens when animation A finishes playing on your object? Ideally you > switch to some > animation B, which matches up precisely to animation A at its endpoint. > (So the keyframe > at t=4 of A is the same as the keyframe at t=0 of B). In practice this > is not always true, > but it's the animation system's job to do extra legwork and make up for > the fact that > animations don't always meet. So you can assume that that part works, > and think of an > ideal world where they do always meet. > > In that case, clearly a right answer is just to drop the last frame of > A, because it is duplicated > at the beginning of B anyway. So you play A0, A1, A2, A3, B0, B1, ... > And because > A4 and B0 are the same, everything is great. > > > > John Connors wrote: > > > > Frame zero. It drives me nuts. What am I talking about? Well, for the > > sake of argument, lets suppose I have a 4 - frame, keyframed > > animation, with the simulation and the renderer stepped at 1/30sec per > > frame. The artist sees 4 frames in > Maya/Max/Blender/WhizzosAtomicModeller > > > > t > > +-----------+-----------+-----------+------------+ > > | | | | | > > +-----------+-----------+-----------+------------+ > > 0 1 2 3 4 > > > > To play a complete animation, we have to render at 5 intervals, > > starting with t=0 and ending with t=4. Great, so thats what you do, > > after all, the artists want to see *all* of their lovely animation, > > right? > > > > So along comes someone else, actually observing the behavior of the > > animation and says "hey, our x frame animation is playing over x+1 > > frames", and the guy/thing/car is overshooting their turn/cutscene > > spot/fov > > > > At this point a number of things can happen. > > > > 1> We rejig the logic/calling order so that animation_update() always > > gets called before animation_render() and we never see the t=0 frame. > > Everything seems right. There's no "unstated state", the animation is > > always playing - that has to be right, no? Er..as along as none of the > > more bright artists realize and get upset (rightly) that they are > > losing a frame of their lovingly hand-crafted animation every time. > > > > 2> We add one to the number of frames of animation every time the AI > > asks what the frame count is going to be. Velocities, etc get scaled > > accordingly. This can annoy AI people, if things take a frame longer > > than they think they will, especially when doing things like > > cornering. The API/Interface has to be bulletproof. > > > > 3> The opposite of 1>. Have every animation signal its desire to > > terminate a frame before the end and never play t=4 except either to > > hold a pose, or blended in with another animation that is > > transitioning in. > > > > I've worked in shops that have used each. My personal preference is > > probably 3, but I've met people quite vehement about 1. I have never > > had the chutzpah to pull 2, myself, but I've seen people do it > > successfully. > > > > Before I write yet another animation engine (properly, this time, I > > always tell myself!) I'd like to sound out the opinions of the crowd. > > Anyone have any strong arguments pro and con for any of these three? > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting > language > that extends applications into web and mobile media. Attend the live > webcast > and join the prime developer group breaking into this new coding > territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > GDAlgorithms-list mailing list > GDAlgorithms-list@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 ```
 Re: [Algorithms] The whole frame zero thang.. From: Glenn Fiedler - 2006-04-05 16:56:43 Attachments: Message as HTML ```the only case where you dont want to drop the frame is when you sample the root motion from it (eg. for walk cycles) -- in which case you want to have a fat export that includes the extra frame, sample the root motion from that, then for all other channels in a looping animation, you know the firs= t frame is the same as the last (and you should CHECK this within a tolerance), so you wrap this is assuming a non-linear root. On 4/5/06, Jonathan Blow wrote: > > I don't see that there's a big deal here. > > Call the animation that you are talking about (the one that has 4 > frames) animation A. What > happens when animation A finishes playing on your object? Ideally you > switch to some > animation B, which matches up precisely to animation A at its endpoint. > (So the keyframe > at t=3D4 of A is the same as the keyframe at t=3D0 of B). In practice th= is > is not always true, > but it's the animation system's job to do extra legwork and make up for > the fact that > animations don't always meet. So you can assume that that part works, > and think of an > ideal world where they do always meet. > > In that case, clearly a right answer is just to drop the last frame of > A, because it is duplicated > at the beginning of B anyway. So you play A0, A1, A2, A3, B0, B1, ... > And because > A4 and B0 are the same, everything is great. > > > > John Connors wrote: > > > > Frame zero. It drives me nuts. What am I talking about? Well, for the > > sake of argument, lets suppose I have a 4 - frame, keyframed > > animation, with the simulation and the renderer stepped at 1/30sec per > > frame. The artist sees 4 frames in > Maya/Max/Blender/WhizzosAtomicModeller > > > > t > > +-----------+-----------+-----------+------------+ > > | | | | | > > +-----------+-----------+-----------+------------+ > > 0 1 2 3 4 > > > > To play a complete animation, we have to render at 5 intervals, > > starting with t=3D0 and ending with t=3D4. Great, so thats what you do, > > after all, the artists want to see *all* of their lovely animation, > > right? > > > > So along comes someone else, actually observing the behavior of the > > animation and says "hey, our x frame animation is playing over x+1 > > frames", and the guy/thing/car is overshooting their turn/cutscene > > spot/fov > > > > At this point a number of things can happen. > > > > 1> We rejig the logic/calling order so that animation_update() always > > gets called before animation_render() and we never see the t=3D0 frame. > > Everything seems right. There's no "unstated state", the animation is > > always playing - that has to be right, no? Er..as along as none of the > > more bright artists realize and get upset (rightly) that they are > > losing a frame of their lovingly hand-crafted animation every time. > > > > 2> We add one to the number of frames of animation every time the AI > > asks what the frame count is going to be. Velocities, etc get scaled > > accordingly. This can annoy AI people, if things take a frame longer > > than they think they will, especially when doing things like > > cornering. The API/Interface has to be bulletproof. > > > > 3> The opposite of 1>. Have every animation signal its desire to > > terminate a frame before the end and never play t=3D4 except either to > > hold a pose, or blended in with another animation that is > > transitioning in. > > > > I've worked in shops that have used each. My personal preference is > > probably 3, but I've met people quite vehement about 1. I have never > > had the chutzpah to pull 2, myself, but I've seen people do it > > successfully. > > > > Before I write yet another animation engine (properly, this time, I > > always tell myself!) I'd like to sound out the opinions of the crowd. > > Anyone have any strong arguments pro and con for any of these three? > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting > language > that extends applications into web and mobile media. Attend the live > webcast > and join the prime developer group breaking into this new coding > territory! > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat= =3D121642 > _______________________________________________ > GDAlgorithms-list mailing list > GDAlgorithms-list@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 > ```
 Re: [Algorithms] The whole frame zero thang.. From: Mick West - 2006-04-05 17:30:40 ```I think in part the problem is a conceptual misunderstanding about what constitutes a "frame" of animation. If the animator gives you four key-frames of animation, then any way you look at it, those are point samples of a continuum. So either they are the state of the animation at t=(0,1,2,3), t=(1,2,3,4) or t =(0.5, 1.5, 2.5, 3.5) (where 1 here is 1/30th of a second). When you play the animation, you are sampling for various values of t. Assuming you are not interpolating, then if your four frames are from t=(0,1,2,3) then it makes no sense to talk of "t=4" for this animation. The animation has finished, and you are playing the first frame of the next animation. I'm basically agreeing with Jonathan, but I don't think you should look at it as "drop the last frame of A, because it is the same as the first frame of B", since in terms of what the animators have given you there should be no overlap. Either there is no A4, or there is no B0. It's either A0,A1,A2,A3,B0,B1... or A1,A2,A3,A4,B1,B2..., depending on how you look at it. This seems equivalent to your options 1) and 3) (except your are NOT loosing a frame), and since they are variants of the same thing some people prefer one over the other, depending on what they first thought of. There is not a big deal here, it's just a communication issue. I'd sit down with an animator, and draw a frame by frame diagram of how an animation is played, and how it transitions to the next animation. Once you are on the same page, all will become clear. Mick. Jonathan Blow wrote: > I don't see that there's a big deal here. > > Call the animation that you are talking about (the one that has 4 > frames) animation A. What > happens when animation A finishes playing on your object? Ideally you > switch to some > animation B, which matches up precisely to animation A at its > endpoint. (So the keyframe > at t=4 of A is the same as the keyframe at t=0 of B). In practice > this is not always true, > but it's the animation system's job to do extra legwork and make up > for the fact that > animations don't always meet. So you can assume that that part works, > and think of an > ideal world where they do always meet. > > In that case, clearly a right answer is just to drop the last frame of > A, because it is duplicated > at the beginning of B anyway. So you play A0, A1, A2, A3, B0, B1, > ... And because > A4 and B0 are the same, everything is great. > > > > John Connors wrote: >> >> Frame zero. It drives me nuts. What am I talking about? Well, for the >> sake of argument, lets suppose I have a 4 - frame, keyframed >> animation, with the simulation and the renderer stepped at 1/30sec >> per frame. The artist sees 4 frames in >> Maya/Max/Blender/WhizzosAtomicModeller >> >> t >> +-----------+-----------+-----------+------------+ >> | | | | | >> +-----------+-----------+-----------+------------+ >> 0 1 2 3 4 >> >> To play a complete animation, we have to render at 5 intervals, >> starting with t=0 and ending with t=4. Great, so thats what you do, >> after all, the artists want to see *all* of their lovely animation, >> right? >> >> So along comes someone else, actually observing the behavior of the >> animation and says "hey, our x frame animation is playing over x+1 >> frames", and the guy/thing/car is overshooting their turn/cutscene >> spot/fov >> >> At this point a number of things can happen. >> >> 1> We rejig the logic/calling order so that animation_update() always >> gets called before animation_render() and we never see the t=0 frame. >> Everything seems right. There's no "unstated state", the animation is >> always playing - that has to be right, no? Er..as along as none of >> the more bright artists realize and get upset (rightly) that they are >> losing a frame of their lovingly hand-crafted animation every time. >> >> 2> We add one to the number of frames of animation every time the AI >> asks what the frame count is going to be. Velocities, etc get scaled >> accordingly. This can annoy AI people, if things take a frame longer >> than they think they will, especially when doing things like >> cornering. The API/Interface has to be bulletproof. >> >> 3> The opposite of 1>. Have every animation signal its desire to >> terminate a frame before the end and never play t=4 except either to >> hold a pose, or blended in with another animation that is >> transitioning in. >> >> I've worked in shops that have used each. My personal preference is >> probably 3, but I've met people quite vehement about 1. I have never >> had the chutzpah to pull 2, myself, but I've seen people do it >> successfully. >> >> Before I write yet another animation engine (properly, this time, I >> always tell myself!) I'd like to sound out the opinions of the crowd. >> Anyone have any strong arguments pro and con for any of these three? >> > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting > language > that extends applications into web and mobile media. Attend the live > webcast > and join the prime developer group breaking into this new coding > territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > GDAlgorithms-list mailing list > GDAlgorithms-list@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > ```
 Re: [Algorithms] The whole frame zero thang.. From: Paul at Home - 2006-04-05 18:24:12 ```I'd go even further. If an artist gives you an animation with 4 keyframes, then you simply have a set of four keyframes to describe an animation. The *actual* animation is to be programmer defined from the get-go. (ie tweening them into something useful) There are a (practically) infinite number of actual frames by the definition of what you were given as being *key* frames. You blend between them based on time-step and a variety of other things to suit. It would be pretty rare for you to drop exactly 100% right on a given keyframe due to the vagaries of frame-rate independence and animational behaviour, therefore your artist should *never* expect to see "frame n" in the game. Caveat: Just make sure a "stopped" animation does indeed pose in the last frame he gave you so he can't poke a hole in that argument! :) Regards, Paul Johnson. Managing Director, Rubicon Mobile, Ltd. http://www.rubiconmobile.com ----- Original Message ----- From: "Mick West" To: Sent: Wednesday, April 05, 2006 6:30 PM Subject: Re: [Algorithms] The whole frame zero thang.. >I think in part the problem is a conceptual misunderstanding about what >constitutes a "frame" of animation. If the animator gives you four >key-frames of animation, then any way you look at it, those are point >samples of a continuum. So either they are the state of the animation at >t=(0,1,2,3), t=(1,2,3,4) or t =(0.5, 1.5, 2.5, 3.5) (where 1 here is 1/30th >of a second). > > When you play the animation, you are sampling for various values of t. > Assuming you are not interpolating, then if your four frames are from > t=(0,1,2,3) then it makes no sense to talk of "t=4" for this animation. > The animation has finished, and you are playing the first frame of the > next animation. > I'm basically agreeing with Jonathan, but I don't think you should look at > it as "drop the last frame of A, because it is the same as the first frame > of B", since in terms of what the animators have given you there should be > no overlap. Either there is no A4, or there is no B0. It's either > A0,A1,A2,A3,B0,B1... or A1,A2,A3,A4,B1,B2..., depending on how you look at > it. This seems equivalent to your options 1) and 3) (except your are NOT > loosing a frame), and since they are variants of the same thing some > people prefer one over the other, depending on what they first thought of. > > There is not a big deal here, it's just a communication issue. I'd sit > down with an animator, and draw a frame by frame diagram of how an > animation is played, and how it transitions to the next animation. Once > you are on the same page, all will become clear. > > Mick. > > Jonathan Blow wrote: >> I don't see that there's a big deal here. >> >> Call the animation that you are talking about (the one that has 4 frames) >> animation A. What >> happens when animation A finishes playing on your object? Ideally you >> switch to some >> animation B, which matches up precisely to animation A at its endpoint. >> (So the keyframe >> at t=4 of A is the same as the keyframe at t=0 of B). In practice this >> is not always true, >> but it's the animation system's job to do extra legwork and make up for >> the fact that >> animations don't always meet. So you can assume that that part works, >> and think of an >> ideal world where they do always meet. >> >> In that case, clearly a right answer is just to drop the last frame of A, >> because it is duplicated >> at the beginning of B anyway. So you play A0, A1, A2, A3, B0, B1, ... >> And because >> A4 and B0 are the same, everything is great. >> >> >> >> John Connors wrote: >>> >>> Frame zero. It drives me nuts. What am I talking about? Well, for the >>> sake of argument, lets suppose I have a 4 - frame, keyframed animation, >>> with the simulation and the renderer stepped at 1/30sec per frame. The >>> artist sees 4 frames in Maya/Max/Blender/WhizzosAtomicModeller >>> >>> t >>> +-----------+-----------+-----------+------------+ >>> | | | | | >>> +-----------+-----------+-----------+------------+ >>> 0 1 2 3 4 >>> >>> To play a complete animation, we have to render at 5 intervals, starting >>> with t=0 and ending with t=4. Great, so thats what you do, after all, >>> the artists want to see *all* of their lovely animation, right? >>> >>> So along comes someone else, actually observing the behavior of the >>> animation and says "hey, our x frame animation is playing over x+1 >>> frames", and the guy/thing/car is overshooting their turn/cutscene >>> spot/fov >>> >>> At this point a number of things can happen. >>> >>> 1> We rejig the logic/calling order so that animation_update() always >>> gets called before animation_render() and we never see the t=0 frame. >>> Everything seems right. There's no "unstated state", the animation is >>> always playing - that has to be right, no? Er..as along as none of the >>> more bright artists realize and get upset (rightly) that they are losing >>> a frame of their lovingly hand-crafted animation every time. >>> >>> 2> We add one to the number of frames of animation every time the AI >>> asks what the frame count is going to be. Velocities, etc get scaled >>> accordingly. This can annoy AI people, if things take a frame longer >>> than they think they will, especially when doing things like cornering. >>> The API/Interface has to be bulletproof. >>> >>> 3> The opposite of 1>. Have every animation signal its desire to >>> terminate a frame before the end and never play t=4 except either to >>> hold a pose, or blended in with another animation that is transitioning >>> in. >>> >>> I've worked in shops that have used each. My personal preference is >>> probably 3, but I've met people quite vehement about 1. I have never had >>> the chutzpah to pull 2, myself, but I've seen people do it successfully. >>> >>> Before I write yet another animation engine (properly, this time, I >>> always tell myself!) I'd like to sound out the opinions of the crowd. >>> Anyone have any strong arguments pro and con for any of these three? >>> >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by xPML, a groundbreaking scripting >> language >> that extends applications into web and mobile media. Attend the live >> webcast >> and join the prime developer group breaking into this new coding >> territory! >> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 >> _______________________________________________ >> GDAlgorithms-list mailing list >> GDAlgorithms-list@... >> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >> Archives: >> http://sourceforge.net/mailarchive/forum.php?forum_id=6188 >> >> > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting > language > that extends applications into web and mobile media. Attend the live > webcast > and join the prime developer group breaking into this new coding > territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > GDAlgorithms-list mailing list > GDAlgorithms-list@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > > > ```
 RE: [Algorithms] The whole frame zero thang.. From: Andrew Vidler - 2006-04-05 14:56:54 ```Hi, I'm not sure I understand what you're saying about playing x+1 frames with x keyframes so maybe this isn't what you're after, but... In general you're never actually playing "a keyframe", you're always blending between two keyframes. Because of this it doesn't make much sense to have an animation on the last keyframe - for example, if the animation time is set right to the end of the animation then I'd have the current keyframe be n-1 and then blend between keyframes n-1 and n with a 100% blend to n (for an n-keyframe animation). So while it's true that you never consider the animation to be on keyframe "n", you still get to see the last keyframe as it blends in from the previous one. You should probably let the user specify whether they want the animation to hold on the last keyframe or just be automatically removed (or, of course, loop - if it's an animation that loops, that is). Cheers, Andrew. > -----Original Message----- > From: gdalgorithms-list-admin@... > [mailto:gdalgorithms-list-admin@...] On > Behalf Of John Connors > Sent: 05 April 2006 15:34 > To: gdalgorithms-list@... > Subject: [Algorithms] The whole frame zero thang.. > > > Frame zero. It drives me nuts. What am I talking about? Well, > for the sake of argument, lets suppose I have a 4 - frame, > keyframed animation, with the simulation and the renderer > stepped at 1/30sec per frame. The artist sees 4 frames in > Maya/Max/Blender/WhizzosAtomicModeller > > t > +-----------+-----------+-----------+------------+ > | | | | | > +-----------+-----------+-----------+------------+ > 0 1 2 3 4 > > To play a complete animation, we have to render at 5 > intervals, starting with t=0 and ending with t=4. Great, so > thats what you do, after all, the artists want to see *all* > of their lovely animation, right? > > So along comes someone else, actually observing the behavior > of the animation and says "hey, our x frame animation is > playing over x+1 frames", and the guy/thing/car is > overshooting their turn/cutscene spot/fov > > At this point a number of things can happen. > > 1> We rejig the logic/calling order so that animation_update() always > gets called before animation_render() and we never see the t=0 frame. > Everything seems right. There's no "unstated state", the > animation is always playing - that has to be right, no? > Er..as along as none of the more bright artists realize and > get upset (rightly) that they are losing a frame of their > lovingly hand-crafted animation every time. > > 2> We add one to the number of frames of animation every time the AI > asks what the frame count is going to be. Velocities, etc get > scaled accordingly. This can annoy AI people, if things take > a frame longer than they think they will, especially when > doing things like cornering. > The API/Interface has to be bulletproof. > > 3> The opposite of 1>. Have every animation signal its desire to > terminate a frame before the end and never play t=4 except > either to hold a pose, or blended in with another animation > that is transitioning in. > > I've worked in shops that have used each. My personal > preference is probably 3, but I've met people quite vehement > about 1. I have never had the chutzpah to pull 2, myself, but > I've seen people do it successfully. > > Before I write yet another animation engine (properly, this > time, I always tell myself!) I'd like to sound out the > opinions of the crowd. > Anyone have any strong arguments pro and con for any of these three? > > -- > +--------------------------------------------------------+ > |Cyborg Animation Programmer | johnc@...| > |http://badbyteblues.blogspot.com -----------------------| > +--------------------------------------------------------+ > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking > scripting language that extends applications into web and > mobile media. Attend the live webcast and join the prime > developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&; > dat=121642 > _______________________________________________ > GDAlgorithms-list mailing list > GDAlgorithms-list@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > ```
 Re: [Algorithms] The whole frame zero thang.. From: Alex_C - 2006-04-05 14:59:53 Attachments: Message as HTML ```Frame 4 is really the first frame of the next animation, you probably don't know that at export time, but you ought to know that at run time. So the first 3 time intervals are defined by the animator, and the fourth one is defined by the code based on the next animation. This should work correctly with looping animation, and lists of animations, including ones with only one keyframe. Alex Clarke Sony Computer Entertainment Europe http://www.scee.com gdalgorithms-list-admin@... wrote on 05/04/2006 15:34:10: > > Frame zero. It drives me nuts. What am I talking about? Well, for the > sake of argument, lets suppose I have a 4 - frame, keyframed animation, > with the simulation and the renderer stepped at 1/30sec per frame. The > artist sees 4 frames in Maya/Max/Blender/WhizzosAtomicModeller > > t > +-----------+-----------+-----------+------------+ > | | | | | > +-----------+-----------+-----------+------------+ > 0 1 2 3 4 > > To play a complete animation, we have to render at 5 intervals, starting > with t=0 and ending with t=4. Great, so thats what you do, after all, > the artists want to see *all* of their lovely animation, right? > > So along comes someone else, actually observing the behavior of the > animation and says "hey, our x frame animation is playing over x+1 > frames", and the guy/thing/car is overshooting their turn/cutscene spot/fov > > At this point a number of things can happen. > > 1> We rejig the logic/calling order so that animation_update() always > gets called before animation_render() and we never see the t=0 frame. > Everything seems right. There's no "unstated state", the animation is > always playing - that has to be right, no? Er..as along as none of the > more bright artists realize and get upset (rightly) that they are losing > a frame of their lovingly hand-crafted animation every time. > > 2> We add one to the number of frames of animation every time the AI > asks what the frame count is going to be. Velocities, etc get scaled > accordingly. This can annoy AI people, if things take a frame longer > than they think they will, especially when doing things like cornering. > The API/Interface has to be bulletproof. > > 3> The opposite of 1>. Have every animation signal its desire to > terminate a frame before the end and never play t=4 except either to > hold a pose, or blended in with another animation that is transitioning in. > > I've worked in shops that have used each. My personal preference is > probably 3, but I've met people quite vehement about 1. I have never had > the chutzpah to pull 2, myself, but I've seen people do it successfully. > > Before I write yet another animation engine (properly, this time, I > always tell myself!) I'd like to sound out the opinions of the crowd. > Anyone have any strong arguments pro and con for any of these three? > > -- > +--------------------------------------------------------+ > |Cyborg Animation Programmer | johnc@...| > |http://badbyteblues.blogspot.com -----------------------| > +--------------------------------------------------------+ > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > GDAlgorithms-list mailing list > GDAlgorithms-list@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify postmaster@... This footnote also confirms that this email message has been checked for all known viruses. ********************************************************************** Sony Computer Entertainment Europe ```
 RE: [Algorithms] The whole frame zero thang.. From: Tom Forsyth - 2006-04-05 18:19:36 ```> To play a complete animation, we have to render at 5=20 > intervals, starting=20 > with t=3D0 and ending with t=3D4. Great, so thats what you do, after = all,=20 > the artists want to see *all* of their lovely animation, right? You instantaneously play t=3D4, but then time stops at t=3D4. The first = four frames blend into the next frame, so t=3D0.5 is half way between t=3D0 = and t=3D1. But there is no t=3D4.5, or indeed any t=3D4.00001. Indeed, you could = argue there is no t=3D4, there's just t=3D3.99999999999. The artist, unless they were an idiot, made sure that the t=3D4 frame = cut cut'n'pasted from the start of whatever animation plays next - or, if = it's a looping anim, from t=3D0 (though some exporters will automatically = replicate the 0 frame for looping anims, so the artist really does only make = 0,1,2,3 and the 4th is implicitly copied - but either way it's copied). So the artist should have only "lovingly crafted" four frames - t =3D 0, 1, 2, = 3 - and the fourth one is just "where I end up" and is really from another animation. This is a variant of the old "there's a road 100m long with a telegraph = pole every 10m - how many poles are there?" (answer =3D 11). Frames are not = periods of time, they are snapshots of instants, whereas animation playback = deals with the times in between those instants. > Before I write yet another animation engine (properly, this time, I=20 > always tell myself!) Or there's some other far more interesting problems you could be solving instead :-) TomF. > -----Original Message----- > From: gdalgorithms-list-admin@...=20 > [mailto:gdalgorithms-list-admin@...] On=20 > Behalf Of John Connors > Sent: 05 April 2006 07:34 > To: gdalgorithms-list@... > Subject: [Algorithms] The whole frame zero thang.. >=20 >=20 >=20 > Frame zero. It drives me nuts. What am I talking about? Well, for the=20 > sake of argument, lets suppose I have a 4 - frame, keyframed=20 > animation,=20 > with the simulation and the renderer stepped at 1/30sec per=20 > frame. The=20 > artist sees 4 frames in Maya/Max/Blender/WhizzosAtomicModeller >=20 > t > +-----------+-----------+-----------+------------+ > | | | | | > +-----------+-----------+-----------+------------+ > 0 1 2 3 4 >=20 > To play a complete animation, we have to render at 5=20 > intervals, starting=20 > with t=3D0 and ending with t=3D4. Great, so thats what you do, after = all,=20 > the artists want to see *all* of their lovely animation, right? >=20 > So along comes someone else, actually observing the behavior of the=20 > animation and says "hey, our x frame animation is playing over x+1=20 > frames", and the guy/thing/car is overshooting their=20 > turn/cutscene spot/fov >=20 > At this point a number of things can happen. >=20 > 1> We rejig the logic/calling order so that animation_update() always=20 > gets called before animation_render() and we never see the t=3D0 = frame.=20 > Everything seems right. There's no "unstated state", the animation is=20 > always playing - that has to be right, no? Er..as along as=20 > none of the=20 > more bright artists realize and get upset (rightly) that they=20 > are losing=20 > a frame of their lovingly hand-crafted animation every time. >=20 > 2> We add one to the number of frames of animation every time the AI=20 > asks what the frame count is going to be. Velocities, etc get scaled=20 > accordingly. This can annoy AI people, if things take a frame longer=20 > than they think they will, especially when doing things like=20 > cornering.=20 > The API/Interface has to be bulletproof. >=20 > 3> The opposite of 1>. Have every animation signal its desire to=20 > terminate a frame before the end and never play t=3D4 except either to = > hold a pose, or blended in with another animation that is=20 > transitioning in. >=20 > I've worked in shops that have used each. My personal preference is=20 > probably 3, but I've met people quite vehement about 1. I=20 > have never had=20 > the chutzpah to pull 2, myself, but I've seen people do it=20 > successfully. >=20 > Before I write yet another animation engine (properly, this time, I=20 > always tell myself!) I'd like to sound out the opinions of the crowd.=20 > Anyone have any strong arguments pro and con for any of these three? >=20 > --=20 > +--------------------------------------------------------+ > |Cyborg Animation Programmer | johnc@...| > |http://badbyteblues.blogspot.com -----------------------| > +--------------------------------------------------------+ >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking=20 > scripting language > that extends applications into web and mobile media. Attend=20 > the live webcast > and join the prime developer group breaking into this new=20 > coding territory! > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&; dat=3D121642 _______________________________________________ GDAlgorithms-list mailing list GDAlgorithms-list@... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 ```
 Re: [Algorithms] The whole frame zero thang.. From: Dave Moore - 2006-04-05 18:59:53 ``` Whoops, sent a reply from the wrong account and got stuck in moderation jail. Tom covered it, but I'll add my mini-rant about Maya's timeline interface. ==== The confusion is not helped by some interface problems in some of the 3-d packages. For instance, in Maya, the timeline shows "on frame 3" as a solid bar covering the timeline from frame 3 to frame 4. Disastrously, it also shows frame 4 in your example as a bar extending from 4 to the non-existent 5. If you look at the curves, the function ends at exactly t=4, but they manage to imply that the animation is longer than it is. (Not to mention that the default timeline is 1 based rather than 0 based, increasing the change of programmer/artist disconnect.) This is clearer in Max, where the time slider's interface indicates pretty clearly that you're dealing with an instant in time, rather than a range. And, hey, they're 0 based by default. :) ==== Dave Moore - Granny Coder, RAD Game Tools Tom Forsyth wrote: >>To play a complete animation, we have to render at 5 >>intervals, starting >>with t=0 and ending with t=4. Great, so thats what you do, after all, >>the artists want to see *all* of their lovely animation, right? > > > You instantaneously play t=4, but then time stops at t=4. The first four > frames blend into the next frame, so t=0.5 is half way between t=0 and t=1. > But there is no t=4.5, or indeed any t=4.00001. Indeed, you could argue > there is no t=4, there's just t=3.99999999999. > > The artist, unless they were an idiot, made sure that the t=4 frame cut > cut'n'pasted from the start of whatever animation plays next - or, if it's a > looping anim, from t=0 (though some exporters will automatically replicate > the 0 frame for looping anims, so the artist really does only make 0,1,2,3 > and the 4th is implicitly copied - but either way it's copied). So the > artist should have only "lovingly crafted" four frames - t = 0, 1, 2, 3 - > and the fourth one is just "where I end up" and is really from another > animation. > > This is a variant of the old "there's a road 100m long with a telegraph pole > every 10m - how many poles are there?" (answer = 11). Frames are not periods > of time, they are snapshots of instants, whereas animation playback deals > with the times in between those instants. > > >>Before I write yet another animation engine (properly, this time, I >>always tell myself!) > > > Or there's some other far more interesting problems you could be > solving instead :-) > > TomF. > > >>-----Original Message----- >>From: gdalgorithms-list-admin@... >>[mailto:gdalgorithms-list-admin@...] On >>Behalf Of John Connors >>Sent: 05 April 2006 07:34 >>To: gdalgorithms-list@... >>Subject: [Algorithms] The whole frame zero thang.. >> >> >> >>Frame zero. It drives me nuts. What am I talking about? Well, for the >>sake of argument, lets suppose I have a 4 - frame, keyframed >>animation, >>with the simulation and the renderer stepped at 1/30sec per >>frame. The >>artist sees 4 frames in Maya/Max/Blender/WhizzosAtomicModeller >> >>t >>+-----------+-----------+-----------+------------+ >>| | | | | >>+-----------+-----------+-----------+------------+ >>0 1 2 3 4 >> >>To play a complete animation, we have to render at 5 >>intervals, starting >>with t=0 and ending with t=4. Great, so thats what you do, after all, >>the artists want to see *all* of their lovely animation, right? >> >>So along comes someone else, actually observing the behavior of the >>animation and says "hey, our x frame animation is playing over x+1 >>frames", and the guy/thing/car is overshooting their >>turn/cutscene spot/fov >> >>At this point a number of things can happen. >> >>1> We rejig the logic/calling order so that animation_update() always >>gets called before animation_render() and we never see the t=0 frame. >>Everything seems right. There's no "unstated state", the animation is >>always playing - that has to be right, no? Er..as along as >>none of the >>more bright artists realize and get upset (rightly) that they >>are losing >>a frame of their lovingly hand-crafted animation every time. >> >>2> We add one to the number of frames of animation every time the AI >>asks what the frame count is going to be. Velocities, etc get scaled >>accordingly. This can annoy AI people, if things take a frame longer >>than they think they will, especially when doing things like >>cornering. >>The API/Interface has to be bulletproof. >> >>3> The opposite of 1>. Have every animation signal its desire to >>terminate a frame before the end and never play t=4 except either to >>hold a pose, or blended in with another animation that is >>transitioning in. >> >>I've worked in shops that have used each. My personal preference is >>probably 3, but I've met people quite vehement about 1. I >>have never had >>the chutzpah to pull 2, myself, but I've seen people do it >>successfully. >> >>Before I write yet another animation engine (properly, this time, I >>always tell myself!) I'd like to sound out the opinions of the crowd. >>Anyone have any strong arguments pro and con for any of these three? >> >>-- >>+--------------------------------------------------------+ >>|Cyborg Animation Programmer | johnc@...| >>|http://badbyteblues.blogspot.com -----------------------| >>+--------------------------------------------------------+ >> >> >>------------------------------------------------------- >>This SF.Net email is sponsored by xPML, a groundbreaking >>scripting language >>that extends applications into web and mobile media. Attend >>the live webcast >>and join the prime developer group breaking into this new >>coding territory! >>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&; > > dat=121642 > _______________________________________________ > GDAlgorithms-list mailing list > GDAlgorithms-list@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=k&kid0944&bid\$1720&dat1642 > _______________________________________________ > GDAlgorithms-list mailing list > GDAlgorithms-list@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_ida88 > > ```