how to see trajectory of Object

[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.