how to see trajectory of Object

[ngrava]

This also reminds me that no 3d animation program that I know of (other then Reflex) does it right in the first place. The problem is that, say you have an arch of motion and you want to change the timing. Say you want to have an object ease out of the arch and then hit hard at the next keyframe. Normally, you go into the f-Curve window and adjust the tangent handles but When you do this, it alters the shape of the arch. This isn’t right, timing (or spacing) between keyframes should be independent of the path of motion. Digital Fish realized this and this is the way it works in Reflex but that app isn’t even out yet. In Reflex, you see the path of motion (trajectory) but you also see little dots along it. You can actually grab those dots and move them along the path to change the spacing or timing without altering the curve. This is the way it should be in all 3D animation programs. I feel sad that it’s probably the most advanced animation program out there but it may never see the light of day.

3DSMax has Trajectory paths that are editable but only in the trajectory’s “Sub-object” mode so you can’t quickly jump between different objects and make adjustments. Lightwave and Messiah have motion paths that can be adjusted with TCB controls (tension, continuity and bias which can be little weird but does work). C4D has some of the best motion paths because you can actually see and edit the tangent handles in the 3D view. But unfortunately, in all these applications, doing this doesn’t change the timing along the curve, just the shape of the curve.

At this point the accepted method for getting around this idiotic issue is just to keep shaping the curve with extra “breakdown” keyframes. This really shouldn’t be the norm. As many computer animators know, the more keyframes you add, the more you compromise the continuity of the curve and the perceived “Smoothness”. Animators must constantly keep an eye on the F-Curves and arcs of motion to keep them from fighting each other.
Computers are smart enough to help us out here, it’s just that most 3D graphics programers don’t even know that this is a problem.

Here’s the solution: What I want is a tangent handle to adjust the curve and a handle on the curve to adjust the timing. Does anyone else feel this way too?

[JDex]

This also reminds me that no 3d animation program that I know of (other then Reflex) does it right in the first place. The problem is that, say you have an arch of motion and you want to change the timing. Say you want to have an object ease out of the arch and then hit hard at the next keyframe. Normally, you go into the f-Curve window and adjust the tangent handles but When you do this, it alters the shape of the arch. This isn’t right, timing (or spacing) between keyframes should be independent of the path of motion. Digital Fish realized this and this is the way it works in Reflex but that app isn’t even out yet. In Reflex, you see the path of motion (trajectory) but you also see little dots along it. You can actually grab those dots and move them along the path to change the spacing or timing without altering the curve. This is the way it should be in all 3D animation programs. I feel sad that it’s probably the most advanced animation program out there but it may never see the light of day.

3DSMax has Trajectory paths that are editable but only in the trajectory’s “Sub-object” mode so you can’t quickly jump between different objects and make adjustments. Lightwave and Messiah have motion paths that can be adjusted with TCB controls (tension, continuity and bias which can be little weird but does work). C4D has some of the best motion paths because you can actually see and edit the tangent handles in the 3D view. But unfortunately, in all these applications, doing this doesn’t change the timing along the curve, just the shape of the curve.

At this point the accepted method for getting around this idiotic issue is just to keep shaping the curve with extra “breakdown” keyframes. This really shouldn’t be the norm. As many computer animators know, the more keyframes you add, the more you compromise the continuity of the curve and the perceived “Smoothness”. Animators must constantly keep an eye on the F-Curves and arcs of motion to keep them from fighting each other.
Computers are smart enough to help us out here, it’s just that most 3D graphics programers don’t even know that this is a problem.

Here’s the solution: What I want is a tangent handle to adjust the curve and a handle on the curve to adjust the timing. Does anyone else feel this way too?

Ah, I couldn’t recall the name of that app. After seeing a video demo of Reflex a two or three years ago, a couple co-workers and I started thinking about how we could implement that sort of functionality in 5.11/6, but production schedules never allowed the effort needed. I’ve never seen an addon for XSI that offered any substantial part of the functionality. I’d love to though.

[ThE_JacO]

Say you want to have an object ease out of the arch and then hit hard at the next keyframe. Normally, you go into the f-Curve window and adjust the tangent handles but When you do this, it alters the shape of the arch.

Just a note on this: If you change the fcurve handles of a position it’s obvious that you are changing the arc, and it should be that way.
To do something where you only want to affect things temporally that is the wrong way to do it, reason a lot of people do it is that most animators only have a superficial grasp of the idea of function curves and what they really are and do.

The correct way to change the acceleration or the speed of something without altering its trajectory is compressing time and keeping tangency handles in the right place (in the space between keyframes).
Timewarping a clip in the mixer, or region scaling parts of the curves and the tangents correctly will do that, moving the handles is as wrong as it gets, because you aren’t changing just the time element of the function, you are leaving waypoints constant and changing the arc in-between.
The handles thing only works if you are working between two keyframes on fairly linear elements.

Reflex has a great way to deal with this and I’ll happily subscribe to the rest of your post, but the handles thing has to go

[ngrava]

The correct way to change the acceleration or the speed of something without altering its trajectory is compressing time and keeping tangency handles in the right place (in the space between keyframes).
Timewarping a clip in the mixer, or region scaling parts of the curves and the tangents correctly will do that, moving the handles is as wrong as it gets, because you aren’t changing just the time element of the function, you are leaving waypoints constant and changing the arc in-between.
The handles thing only works if you are working between two keyframes on fairly linear elements.

Reflex has a great way to deal with this and I’ll happily subscribe to the rest of your post, but the handles thing has to go

Hi Jaco,

Unfortunately, I think you misunderstood what I was trying to say or I simply didn’t explain myself very well. Ok, let’s look at the bouncing ball example: One key at the base, next is up in the air, next back down on the ground rinse and repeat down the street. Now, in order to actually get the ball to bounce and not just move up and down you need to alter the tangent handles on those keys. Also, this is where you can see that since you have to break the tangent handles (or add a double key… Actually there’s all kinds of way to that but anyway…) in the F-Curve window. And, depending on the curvature/arch that you form with the handle, you will be controlling the curvature/arch of the resulting motion trajectory AND defining the spacing of the frames (between keyframes) as the ball accelerates to the last key frame. Say, you want to make it is so that the ball doesn’t hit so hard. Again, you have to alter the tangents of the ‘hit’ keyframe… And, again, this changes the curvature/arch of the resulting motion. I don’t see how scaling the action would do this so I think we are just talking about two different things here.

With a bouncing ball this isn’t to much of an issue but say you where bouncing a flying insect all over the place and at odd angles where you are not simply making peeks on the ‘Y’ channel at the hits but instead, a combination of all three channels. Say the insect is a big one and heavy too. It’s not going to hit as hard on the ceiling as it is on the walls or the floor. Now, this is where changes in the tangency can really mess up the timing and the arch. I actually had to do something similar for a commercial one time. Imagine that all you had to do was to concentrate on the arcs and make them look good. Then (or during if you prefer) you could adjust the ease without affecting the arcs. Does that make more sense?

Sorry if this is still confusing.

[ThE_JacO]

You are talking about acceleration between two keyframes in a linear movement, that’s why the example works.
If you describe an arc with multiple keyframes, and want to retime the progression in time of an object on that arc, you wouldn’t deal with the handles at all, you would be dealing with the keyframes, and the handles inbetween would have to stay unaltered in the normalized space between the keys.

That is what the dots in reflex do, they move the keyframes that describe that arc over time and keep the handles length in normalized space constant.

[Stoehr]

Oh, Jaco. Now you got me thinkin’ on how to do this. You probably already know, but don’t tell me. I’m going to try and figure this out.

[Ohmanoggin]

Galen Beals,
You stated: “What I want is a tangent handle to adjust the curve and a handle on the curve to adjust the timing. Does anyone else feel this way too?”

I’ve seen this feature and I am not convinced it is very useful. I can see how on the surface it looks impressive, but I am not sure what use having a graphic handle on a tragectory would be except in the most basic animations.

On any curve you may have any number of things that need to happen on the same point. Just making a character plant their foot would require some kind of pause, and how would you say move backwards? A graphics handle will have to become more complex than any other method if it is to have the same flexibility.

You also state:
“At this point the accepted method for getting around this idiotic issue is just to keep shaping the curve with extra “breakdown” keyframes.”

Using the U parameter of a 3D curve to control timing is 70’s technnology. Perhaps I am misunderstanding you, but to me this would be a step backwards against any other method.

In the end path constraints seem to be the best way to control timing and position on a tragectory. Also let me stress that I am puzzled why anyone would try to do character work with tragectories. I could see turning on ghosting with trails, but to actually use 3D paths to control a character’s limbs, just doesn’t make sense to me when you factor in timing.

Just my two cents.
Ohmanoggin

[grahamef]

In the end path constraints seem to be the best way to control timing and position on a tragectory. Also let me stress that I am puzzled why anyone would try to do character work with tragectories. I could see turning on ghosting with trails, but to actually use 3D paths to control a character’s limbs, just doesn’t make sense to me when you factor in timing.

The way to get complete control over timing and position is to use Set Trajectory instead of Set Path. Trajectories use one knot per frame (paths use % distance over time) so you have complete control over the position at each frame. It could be useful if you have a digital character interacting with objects in a live plate, e.g, a cartoon holding a real lit cigarette.

[ngrava]

Galen Beals,
You stated: “What I want is a tangent handle to adjust the curve and a handle on the curve to adjust the timing. Does anyone else feel this way too?”

I’ve seen this feature and I am not convinced it is very useful. I can see how on the surface it looks impressive, but I am not sure what use having a graphic handle on a tragectory would be except in the most basic animations.

On any curve you may have any number of things that need to happen on the same point. Just making a character plant their foot would require some kind of pause, and how would you say move backwards? A graphics handle will have to become more complex than any other method if it is to have the same flexibility.

You also state:
“At this point the accepted method for getting around this idiotic issue is just to keep shaping the curve with extra “breakdown” keyframes.”

Using the U parameter of a 3D curve to control timing is 70’s technnology. Perhaps I am misunderstanding you, but to me this would be a step backwards against any other method.

In the end path constraints seem to be the best way to control timing and position on a tragectory. Also let me stress that I am puzzled why anyone would try to do character work with tragectories. I could see turning on ghosting with trails, but to actually use 3D paths to control a character’s limbs, just doesn’t make sense to me when you factor in timing.

Just my two cents.
Ohmanoggin

OK, obviously I’m not explaining myself very well here. JaKO: Yes, I’m only talking about adjusting the timing between keyframes. Changing the timing over a number of keyframes is done by scaling the those keys. Yes, I understand that but I’m not talking about that. I think my first mistake was using the word “Timing”. This usually refers to the positioning of keyframes in a range in the timeline. My mistake there. I guess “Timing” as I was referring to, is actually called “Spacing”… Or ease… Or even Bias… Man there is just to many ways to describe the same thing…

I’ll try and be as clear as possible: There is a direct relationship between a 2D animator and an in-betweener and a 3D animator and a computer. 2D animators have a system of relating the spacing of an action between the keyframe drawings. Usually with a little graph in the corner of the frame that shows the action biased toward one key drawing or the other. This is also referred to as defining the “Easing” in or out of a keyframe.

Obviously, this is done in 3D with the F-Curves or, as I mentioned earlier, by adding more breakdowns.

I’m sure you all understand this, and again, I think we are all using different language to describe the same things or the other way around. Another problem is that these things that we have been talking about are called different things in different programs. For instance, it seems like maybe Ohmanoggin has mistaken the term “Trajectory” to mean, animating by attaching an object to a spline moving it along that over time. Yes, that would be cumbersome but that’s not what I’m talking about. In 3DSMax, Trajectories are similar to turning on ghosting with trails. Other programs call these “Motion Paths”. The difference is that in XSI you can’t see the keyframes or frames along the trails/curve/path/trajectory/whatever.

When you can see them, it’s a simple extrapolation of functionality to be able to manipulate them in the 3D view. I’ve worked in a few programs where you can do this and it’s a huge time saver and helps a lot with making good arcs. So, I think it’s a reasonable extrapolation from there to want to take it a step farther and control the easing/spacing/timing, in-between the keyframes, right on the curve/path/trajectory. I apologize if this is sounding terse and pedantic and I’m certainly not trying to offend anyone. I’ve been working in computer animation and developing these ideas for over 15 years. I’m not some student trying to work my way around some concept that I just don’t understand. Maybe I do have some part of this messed up in the explanation… It all seemed to natural in my head.

[ngrava]

OMG! LOL! I just got it. “Set Trajectory!” You know, I’ve never even seen that feature. Now Ohmanoggin’s comment makes way more sense. My apologies. And again, this is a perfect example of what I was talking about: Different programs using different words to describe the same things and vis-a-versa. Sorry about that.

[toonafish]

Wow, disconnect keyframes from the path or trajectory and make both visible and adjustable in the viewport. Great idea!! And it all sounds so logical, it’s surprising this is not standard functionality in every 3D animation app already.

[ThE_JacO]

I’m still sort of struggling trying to understand exactly what you’re trying to get at ngrava

You brought up reflex, their motion arcs, and how moving a dot on their arc alters the spatial distribution of time, which is what I was talking about when I explained how distribution of the arc works.
To debate that you moved moved that to acceleration and deceleration with handles changing the spatial values of the arc as if it was related to that, which was what I objected to.

Then you shifted that on how it’s inter keys (at which point the examples of how reflex works become kinda moot) and how you would like tangency controls on the arc display, at which point you go back into exactly the same situation you described as negative (spatial changes of the arc when adjusting handles), which goes all the way back to asking for something that does exactly what you flag as a negative.

Seems to me you’re mixing a few things together here that needn’t be mixed, which is what makes the conversation hard to follow.

Distribution of time over the spatial trajectory of an object is key dependent, that I find useful and I like how reflex deals with it.
Tweaking of the handles in viewport seems rather ininfluential in keyframe heavy character animation to me to be honest, it’s nice, but nowhere as important for timing, interaction and simplicity as being able to affect the arc itself over multiple keyframes and the distribution of those.
For that to work handles need to stay derivative, and the price to get them freeform (unlocking/locking mechanism) is potentially a complication of a workflow that should remain simple to be useful.

So, what exactly are we discussing here?

[Ohmanoggin]

The way to get complete control over timing and position is to use Set Trajectory instead of Set Path. Trajectories use one knot per frame (paths use % distance over time) so you have complete control over the position at each frame. It could be useful if you have a digital character interacting with objects in a live plate, e.g, a cartoon holding a real lit cigarette.

Thanks for your input. It seems to have solved the original posters questions. Although, I think I should clarify something, because I am still not convinced this is a solution to their concerns.

Yes, someone might use a trajectory (set path or set trajectory) for character work, but it is not the primary way to key something. In the case of set trajectory, such as syncing a cg character with a live action, a live object is driving the postion of the cg limb. The animator is not really trying to create their own motion, just simply match the motion of something else. So, sure why not use set trajectory? However, to use set trajectories to animate an entire character would be counter intuitive when the animator starts trying to do something as simple as a walk cycle or heck how would you keep a foot planted with set trajectory- key 30 knots in the same spot?..and getting one position/frame for one curve knot is going to produce some pretty nasty curves.

Honestly, I could be wrong, but over the years I have come across many new animators who hate fcurves and try to avoid them. Then after they have had some time on their own trying to key stuff, they actually invent the need for fcurves themselves and then love them.
Ohmanoggin

[grahamef]

Thanks for your input. It seems to have solved the original posters questions. Although, I think I should clarify something, because I am still not convinced this is a solution to their concerns.

Yes, someone might use a trajectory (set path or set trajectory) for character work, but it is not the primary way to key something. In the case of set trajectory, such as syncing a cg character with a live action, a live object is driving the postion of the cg limb. The animator is not really trying to create their own motion, just simply match the motion of something else. So, sure why not use set trajectory? However, to use set trajectories to animate an entire character would be counter intuitive when the animator starts trying to do something as simple as a walk cycle or heck how would you keep a foot planted with set trajectory- key 30 knots in the same spot?..and getting one position/frame for one curve knot is going to produce some pretty nasty curves.

Honestly, I could be wrong, but over the years I have come across many new animators who hate fcurves and try to avoid them. Then after they have had some time on their own trying to key stuff, they actually invent the need for fcurves themselves and then love them.
Ohmanoggin

No arguments from me. I was just pointing out a little-known command that might be useful in some circumstances.

I think that IF you were going to use something like this, the best workflow would probably be to block out some keyframes initially and then plot to trajectory or path. Alternatively, build up the path using Set Locked Key on Path (another little-known command). That would at least avoid some of the issues you mention.

[ngrava]

Thanks for your input. It seems to have solved the original posters questions. Although, I think I should clarify something, because I am still not convinced this is a solution to their concerns.

Yes, someone might use a trajectory (set path or set trajectory) for character work, but it is not the primary way to key something. In the case of set trajectory, such as syncing a cg character with a live action, a live object is driving the postion of the cg limb. The animator is not really trying to create their own motion, just simply match the motion of something else. So, sure why not use set trajectory? However, to use set trajectories to animate an entire character would be counter intuitive when the animator starts trying to do something as simple as a walk cycle or heck how would you keep a foot planted with set trajectory- key 30 knots in the same spot?..and getting one position/frame for one curve knot is going to produce some pretty nasty curves.

Honestly, I could be wrong, but over the years I have come across many new animators who hate fcurves and try to avoid them. Then after they have had some time on their own trying to key stuff, they actually invent the need for fcurves themselves and then love them.
Ohmanoggin

Yeah, that wasn’t really what I was suggesting. I never meant to suggest that someone attempt to do character animation with Set Trajectory. I thought I made that clear in my last post. But I can see that it was another example of the same term being used differently in two separate apps. I just found out that there even was a “Set Trajectory” feature. I knew you could attach an object to a path and animate it but I didn’t know it used the word “Trajectory”. I can understand the confusion. But again, not at all what I was talking about.

[ngrava]

Ahhh! I think we are finally starting to define a more common language. Thanks for that JacO. “Spatial distribution of time” is a much better way of putting.

I’m still sort of struggling trying to understand exactly what you’re trying to get at ngrava

You brought up reflex, their motion arcs, and how moving a dot on their arc alters the spatial distribution of time, which is what I was talking about when I explained how distribution of the arc works.
To debate that you moved moved that to acceleration and deceleration with handles changing the spatial values of the arc as if it was related to that, which was what I objected to.

Hmm. Changing the “spatial distribution of time” is changing the acceleration or deceleration… Is it not? I guess I don’t understand what that the difference is. If I change the tangent handle of a keyframe in the F-Curve window, pull it in closer to the keyframe for example, it’s going accelerate and thus change the spatial distribution of time… Isn’t it? And, it’s also going to change the curvature of the arch… You’re saying that’s not correct?

Then you shifted that on how it’s inter keys (at which point the examples of how reflex works become kinda moot) and how you would like tangency controls on the arc display, at which point you go back into exactly the same situation you described as negative (spatial changes of the arc when adjusting handles), which goes all the way back to asking for something that does exactly what you flag as a negative.

Ah… What? I totally don’t understand what you are saying here. What do you mean by “inter Keys”?

Maybe my understanding of how reflex works is incorrect in the first place. There is a picture that I posted in the above post that shows a curve with it’s tangent handles being manipulated, you can see the little dots on the curve that represent the frames and their distribution along the curve. my understanding is that if you grab one of those dots, you can move them and thus change the “spatial distribution of time” between the keyframes. It doesn’t move the actual keyframes, just changes the distribution of time specially. Right? My understanding is that you can also change the tangent handle too in order to work on the arch of motion. Doing this doesn’t change the spacial distribution of time along the arch. It that still true?

So, the issue for me with the way things currently work is that, if I change the tangent handles in the F-Curve window it will change the curvature of the arch and the spacial distribution of time along that arch… What I’ve been asking for this whole time is the decoupling of arch controls from affecting spatial distribution of time so that I can define my arch and then adjust the ease without messing up that arch. It’s just a more flexible way of working in my mind. I’m not saying that I want o get rid of F-Curves all together. I just want to flexibility to use whatever control works best in that situation. As far as I was aware, this is how Reflex works. But, maybe I have it wrong to begin with.

Seems to me you’re mixing a few things together here that needn’t be mixed, which is what makes the conversation hard to follow.

Distribution of time over the spatial trajectory of an object is key dependent, that I find useful and I like how reflex deals with it.
Tweaking of the handles in viewport seems rather ininfluential in keyframe heavy character animation to me to be honest, it’s nice, but nowhere as important for timing, interaction and simplicity as being able to affect the arc itself over multiple keyframes and the distribution of those.
For that to work handles need to stay derivative, and the price to get them freeform (unlocking/locking mechanism) is potentially a complication of a workflow that should remain simple to be useful.

So, what exactly are we discussing here?

[Ohmanoggin]

I want to apologize to anyone if it looked like I was ragging you. My post were not really intended to be directed at anyone in particular but merely an effort to prevent others who may read this thread from interpretting things in ways that send them off in the wrong direction.

We are all Softies and I really didn’t mean to make things unfriendly.

Respectfully,
Ohmanoggin

[ngrava]

Not at all. If anything, I should apologies for a number of things myself, the least of which is being generally offensive or difficult to understand. And, I certainly didn’t mean to sound like I was trying to scolded you in my responce. Unfortunately I re-read it and it definitely sound that way. I hate it when I re-read a post and realize what a dork I am. Like I need to be reminded of that.

P.S. I seems I got a little messy with the word “Spatial” in the post to JacO. Kept typing “Spacial” instead. Sorry about that guys it’s supposed to read as Spatial… I guess I could edit the post…

[LucentDreams]

Open Cinema 4D R7 and you can do this, they did it for years before adopting fcurves because no one seemed to be able to use it well before.

Kind of wish they’d kept both myself instead of totally removing the old accelleration curve system.

[CGTalk_Moderation]

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.