Creating a node that computes velocity

[paulmais]

Hi all,

I've been toying with creating a DG node that will compute the velocity of one of it's input attributes. It's fairly easy to do as an expression, but runs slow (two getAttr's in the expression), and isn't very portable when you want to make copies, or have to change unit settings.

However when I sat down to code up the node, I having trouble getting it to do what I want.

My thinking was that I could create two MDGContext-s, one for the current time and one for one frame ahead. Since the calculation is happening inside the compute() block, I don't get to use the MPlug.getValue with a MDGContext arg. The best I could figure was to set the context on the MDataBlock that gets passed into compute as below:

// Grab distInput
// First for "delta" time
data.setContext (deltaContext);
distInputHandle = data.inputValue (distInput, &returnStatus);
if (returnStatus != MS::kSuccess)
dataAccessErrorCount++;
else
{
nextInputDist = distInputHandle.asDistance();
nextInputCm = nextInputDist.asCentimeters();
}

// Then for current time
data.setContext (currentContext);
distInputHandle = data.inputValue (distInput, &returnStatus);
if (returnStatus != MS::kSuccess)
dataAccessErrorCount++;
else
{
currentInputDist = distInputHandle.asDistance();
currentInputCm = currentInputDist.asCentimeters();
}

This doesn't work, and causes strange side effects, such as making setting distinct keys on distInput difficult.

Is there a way to get the value of an input attribute at a time other than the current time while inside a compute() block ?

Should I be using an MPlug to grab the value at the non-current time ?

Or is a completely different approach necessary ?
For instance, caching values during the compute, then using a previously stored value to determine the attribute's change in value over time, and from that a velocity ?

Thanks,

Paul

[joojaa]

this is a nontrivial issue. As in general nodes arent by design allowed to do this. Alltough there is a nodes in maya that do break this rule but they are rather specialized ones. but directly form the manual "A node must not know anything outside of its attributes and plugs" wich inidrectly states you may not querry them at other times as time is a node outside yours. (there is way tough more on this later)

Well as with the expression you dont actualy need to use gatAttr at all if you can contend with a caching solution. Also the velocity has allmost no meaning if your not stepping the animation at frame by frame basis, wich means cached soultiions are not realy all that optimal.

And it doe snot sho correctly in the graph editor.

Se if you cache the position of this frame and in next frame us e new value - cached value you get MUCH faster preformance, and the expression is totaly possible to copy without a problem (if you enable the duplicate input graph option). The beauty of expression nodel les in NOT using mel inside them, since mel does not know the connections its static and stupid.

here let me show you how to do such a expression, its not optimal but works in numer of situations such as when needing to roll wheels in final rendered animations! tough not whan scrubbing around.

sphere -p 0 0 0 -ax 0 1 0 -ssw 0 -esw 360 -r 1 -d 3 -ut 0 -tol 0.01 -s 8 -nsp 4 -ch 1;
addAttr -ln velocityX -at double |nurbsSphere1;
setAttr -e -keyable true |nurbsSphere1.velocityX;
addAttr -ln velocityCacheX -at double |nurbsSphere1;
addAttr -ln timeCache -at double |nurbsSphere1;
$expr="nurbsSphere1.velocityX=(nurbsSphere1.translateX-nurbsSphere1.velocityCacheX)/(time-nurbsSphere1.timeCache);rn";
$expr+="nurbsSphere1.velocityCacheX=nurbsSphere1.translateX;";
$expr+="rnnurbsSphere1.timeCache=time;";
expression -s $expr -o nurbsSphere1 -ae 1 -uc all -n "nurbsSphere1Velocity";
//steps out well but does not bake all that well with bakeResults but does with bakeSimulation!

im only doing this on one channel but nothing says you cant do this for more then one. (im lazy), but theres still a problem it only works in a timely fashion so if you jump around in the anim it will NOT work.

The same applies as a plugin too.

Now for the tough part future/past lookup, well its certainly possible BUT its allways expensive at the same magnitude as getAttr is because it does refresh (since the dg needs to refresh more then one time per frame), because it might happen that the data isnt computed yet (but unlike getattr its possible to handle cached values!). Secondly its a against the design of the dg so you would constantly be working against it. Se dg nodes are meant to not know their parents.

There is way to do this STRICTLY within the design parameter tough, and its to make a node thet actualy handles looping and use the loop node to feed data to your curves time. and loop 1 extra time to obtain it. Note such a loop node can do all manner of other cool stuff too! So its actualy worthwhile for other resons ebyond this. Se iits not agianst to modify the flow! its stille xpensive tough compared to caching.

Other solutions. If you just wish to see the vellocity curve! the i suggest doing something like the resultCurve node, as it doe smaple the entire time for you to see! You could try to overload it!

Edity improoved the legibility of the expression slightly

[joojaa]

But to answer your question more directly (needed to test this and consult the manual, i had done it but didnt remeber how you can find ths topic in the api faq)

use MDGContext and init it to the custom time then pass this to getvalue of mplug... and then it eveluates only whats needed.

Its like the dg loop but slightly outside of the normal dg evaluation context. But theres no guerantee thet maya actualy happened to cache tehe result it might or it might not. (so try to ask for something maya plays more often such as last frame becuse the next frame is most likely not yet cvached on the first run)

[paulmais]

Hi Joojaa,

Could you describe the curve method in more detail ?

Are you essentially building an animCurve internal to the node that is storing all the position versus time data ?

What are the mechanics for implementing something like that ?

Also, before reading your second reply about using MDGContext with an MPlug I did that on my own. It seems like it works, but I not totally convinced that it always updates properly.

For what it's worth, my prejudice against the expression/added attribute method is two fold :

1. Maya doesn't allow you to add the equivalent of MDistance and MAngle attributes.

2. Making copies (with duplicate input graph) requires more Maya operator knowledge than I can count on for the guy who'll be using this.

Thanks for whetting my appetite about the curve solution. I'll be anxious to here more.

Again thanks,

Paul

[joojaa]

Yes i asumed youd get into trouble with this, jsut because it IS outside of how its supposded to wrok.

Could you describe exactly what you need this for!

In reply to:
Are you essentially building an animCurve internal to the
node that is storing all the position versus time data ?

Yes thats how maya internaly works. when showing you anim curves in graph editor. Im not exactly sure how to implement it well tough. And ist sure not teh method i would use.

This is what id do (or did). id create a node that has one input for time or any other driver. one output for the same type. and a input for one type and a array output for a array type.

then inside the cpompute block once soemthing comes in teh time driver port it sends out a a time out to the real time of the node uyou want to usel. then reads at the node place where you want to use, and passes this data along in array 0 then it resends this to the start of the line with time +- something, requests for a update upstream and reads out to array 1 and so on untill it has looped for a sufficent amount of times and then it marksa itself nondirty and is content.

This is usfull for many reasons since it

A) handles this very well
handles things suchs as tank threads well with just one anim curve node. or sany other combo indeed.
C) works within the graph.
d) is very general so you can find a lot of other uses to it later in your projects, so its not a solution fo one poblem but severel
NOw the only do

In reply to:
1. Maya doesn't allow you to add the equivalent of MDistance and MAngle attributes.

2. Making copies (with duplicate input graph) requires more Maya operator knowledge than I can count on for the guy who'll be using this.

1. why would it matter? if yoiu have a untyped float then maya just chews it as is (no conversion is done its just like no user ever types Mdistace either into the channelbox so do you become prejudiced against operators too ).

So only a api user would ever be able to tell the difference, even then only if he was ever looking for the difference with a lookingglaas.

1. Explain? theres nothing the operator needs to do!? (he needs not edit the expression since something = something is a connection so maya will rename them orn duplicate automaticaly unlike getAttr!), why is it yuou need velocity feedback?

If your after a AElike velocity curve in wich case you cant realy succeed unless you make all anim curve nodes anew from scratch! this is one of those things you can DO but why do it if you can get half teh functionality for 1% of the time its required. Just make sure you bill the person accoriding to the amount of job

[paulmais]

Hi Joojaa,

Could you maybe post a screen shot of the node and it's connections in the hypergraph. I'm having trouble picturing whether you are talking about one node or two, and how/where the connections are made, whether it involves an existing animCurve, etc. My situation doesn't really give me animCurves as the motion is derived procedurally, and can't really be baked out without creating other headaches.

The particular reason for doing this is to use Maya to determine whether a moco camera crane can perform a given move designed in Maya, and further what is the fastest speed a move can be shot. The crane has physical/electrical/mechanical limitations on how fast it can move along each of it's 6 axes.

Admittedly I'm pushing the boundaries of what you might ordinarily think to in Maya. As for more reply about the units and expression queries. Units are important because most everything has to be modeled and simulated at real-size. Expressions are possible to break, even if it's unintentinal, whereas API code can't be.

Thanks again,

Paul

[joojaa]

one node that is both the driving force of input and the target of output

well does not matter.... it can loop anything. Ok ill post a picture whan i get to a computer with maya isntalled.

But what prcedureal do you use! because some of the procedurals can shod derivate info. Most notably exprwessions for wich its usualy as trivial as the expression itself.

[queequeg]

Why can't you do this in MEL? Like calling a proc that prints out "Max speed 234mph at frame 25" or sth. I just don't understand why you can't bake out the channels.

[joojaa]

Dunno... i suppose hes one of those guys who needs it perfect or no way at all. Personbaly if i use velocity for something i allwasy bake it out. So who cares if my vidusl feedback inst up to date whan scrubbing. Why should i care its a PROXY anyway if its right in the final its right.

But there misght be soem critical interaction that might warrant twaking the bit.

Still no maya sorry (im sitting on the beatch just reading thru my mails etc.)

[paulmais]

Hi Queeg n' Joojaa,

There's a few reasons I'd prefer to do this API-side, mostly owing to being able to display velocity (current, maximum, as a percentage of a limiting velocity) for a number of different attributes. Doing such a display as locator is easy, with Mel I have to use a graphics which I want, but in addition to rather than instead of text. Also, having a scrub-proof solution is a major plus.

As for the need for perfection, it's more my boss than me. However, exploring alternate approaches does feed curiosity. Often times the first solution isn't always the best. And if a secondary approach doesn't prove best in this case, it becomes another thing in your bag o' tricks.

On an implementation note, having thought about Joojaa's node more, are you essentially extending the {currentVal, previousVal} idea into a cache for all frames via an array attribute.

That's starting to make sense to me, and it would seem that with two time inputs (one to drive updating of the array), and a second to specify the time at which a velocity is sought, would work nicely.

Regards,

Paul