Expression value offseted over time

[thelvin-c]

Hey all!

I want to know if there is a way to "lag" an expression.
Say a simple expression of a ball Y attribute driving a cone Y attribute.
ball.y = cone.y

Simple, but now I want the Y attribute of the cone to LAG or stay behind from the real attribute given by the ball.Y.

I am not talking about ofsseting the value but offseting the time of the cone's expression.

There is probably a simple solution and I am just braindead.

Thanks in advance

[markwilkins]

Julian Mann just posted a response to this same question on the maya-dev mailing list. Here's what he said.

---

There's a dependency node called frameCache which will store the values
of some data over time.
So for example make a sphere with animated tx.
Connect sphere.tx to frameCache1.stream.
Connect time1.outTime to frameCache1.varyTime
If you want pCube1 to follow 3 frames later then connect
frameCache1.past[3] to pCube1.tx

If you want a duplicate of pCube to follow the original sphere then
duplicate with input connections, or if you want a new sphere too then
duplicate with upstream graph.

Whatever, it's cleaner than using getAttr in an expression.

Hope it helps

---

Mark R. Wilkins
author of MEL Scripting for Maya Animators
www.melscripting.com

[thelvin-c]

Thanks for the info Mark!!

I try this frameCache. It does work but I can't animate interactively the object (sphere in Julians example) that drives the second "lagged" object.
When I try to move it, I get some flickering on the object but I can't move it freely.
And also the second object (pCube) doesn't update as I expected.

Anyways for those interest, I came out with another way and it works great.

here's the expression making a cube's TX move 3 frames behind a spheres TX.

float $T = time1.outTime - 3 ;
Cube.translateX = getAttr -time $T sphere.translateX;

thanks again

[markwilkins]

The point of the frameCache node is to keep you from using a getAttr in your expressions.

Putting calls to getAttr for a different time in your expressions can GREATLY slow down scene evaluation because Maya has to recalculate much more of the DG to find the result. It's fine when you're making a cone follow a sphere, but when you're doing something really complex the frameCache node will be much, much faster to execute.

There are times when getAttr is the only way to do what you're trying to do in an expression, but if there's any other way I advise taking it.

-- Mark

[campbell]

just disable the caching node to do your animatn, or edit anim crvs.

[thelvin-c]

thank you all for the replies!! I really appretiate it

[mantrid]

...well, if you like, there is a mych simpler way to create a time offset expression...:

1) create a locator.

2) type the following expression :

float $offset = locator1.ty;
cone.ty = getAttr -t (frame - $offset) ball.ty;

Now what ever the translateY attribute of the locator is, will determine the number of frames that the cone.ty is following the ball.ty by. So you can animate the lag itself just by keying the height of the locator. This is more convenient then using an attribute for offsetting as it is more visual.

[markwilkins]

Hey, pootang (nice nickname), we discussed that idea above. Once again, it's a bad idea to use getAttr in expressions unless you have to, and with frameCache, you don't have to do so for this.

Better to use a MEL script that bakes the t-3 animation into a new curve with getAttr than use an expression like that, because with a scene with rigged characters in it, for example, it's likely to be too slow.

-- Mark

---

Mark R. Wilkins
author of MEL Scripting for Maya Animators
www.melscripting.com

[joojaa]

Yes this was discussed before but potang having more than a few getAtrs will slow maya to a crawl! I wish atleast this data qocould be querried directly since its a pain to use cache for this sort of stuff! hmm sort of thing tro put on the maya wish list!

[mantrid]

true...but then if you are only using it for one or two things it is just fine...why go for overkill on a simple solution! If you want to use lots of things, fair enough, use the solutions above.

And besides, I have used it for a few dozen objects in the scene in the past and it was performing quite satisfactuarally. Was part of a very quick flocking system I needed to get working in one lunch hour....exchanging rotations for translations that is. I have always heard lots of comments on this getAttr being slow...but I really havn't experienced it slowing down beyond complete acceptability. Maybe its just my machine, who knows.

[pete68547]

the exact thing you are looking for is on my fellow classmates website checkout http://www.swanimator.com
hope it helps

[nonquad]

Well it probably has a lot to do with what you're gettingAttr on.

If you're gettingAttr on a top-level node, then maya just has to look at the animation curves at that time point, and the operation is likely to be more or less transparent.

But if you're gettingAttr on, say, an object pointConstrained to a character's hand, then maya has to resolve almost the entire scene to give you the information you want. I can see how a couple of calls like that could quickly slow a scene to a crawl.

Worst case, would be gettingAttr on something driven by a dynamics effect like a rigidbody. To give an accurate result (and I suspect maya would try to do that) the program would have to replay the entire course of the animation, complete with dynamics, for each out-of-frame call to getAttr. In such a situation a frame cache, either manual or automated, would really be the only reasonable solution.

Oh and by the way, I didn't know about that cache node - so I'm extra glad I stumbled in here. That rocks. Thanks!

[markwilkins]

Unfortunately, more often than not the impulse to use a getAttr in an expression ONLY strikes me when it's an attribute being driven by a deformer on a character constrained to something like a procedurally-generated surface that takes twenty minutes a frame to calculate...

-- Mark

---

Mark R. Wilkins
author of MEL Scripting for Maya Animators
www.melscripting.com

[joojaa]

Yes one other stupid thing is that you cannot wery edfectively do particle expressions where particles querry walues from each other without caching. And offcourse this runs into the problem of what order they are evaluated, which would be a nice thing to controll too by the way.

Anyway the bottomline advice is not to use getattr for anything that you could do other ways if its a large job. But it could be nice if stuff that is allready computed could be querried quickly without the need for re-calc

[warpcat]

While the frameCache node seems pretty cool, I ran into the same issue as Thelvin C. Once the node has been created and connected, the animation feeding into it gets... "cached". If you change the animation of the original node, the frameCache node dosen't seem to update, or updates very strangely. Is there a workaround for this? I tried the clearCache -all command, but no beans.