PDA

View Full Version : Nodal motion & nodal displacement: reversing order of evaluation?



jeric_synergy
08-23-2015, 01:38 PM
I added some pointer geometry to my spring and can see what's going pear-shaped: the spring LWO is correctly pointing at the target, but the displacement only occurs on the X axis. Since the POINTING occurs first, the displacement is only skewing the spring to an incorrect location.

IF the displacement were to occur first, I think this would work. Playing with the nodal displacement order doesn't seem to help though.

How DOES one reverse the evaluation order of motion and displacement?
129431

jeric_synergy
08-23-2015, 02:14 PM
Version 005:
I eliminated the need for nodal Motion by using DPKit's Rotation node. The rig still has the same problem as before, but now it's all in one node editor (Displacement) instead of two.

The same basic difficulty is on the table: how to order evaluations. In this case, I want to set the length first, then rotate (via displacement) the object. The 'rotation' appears fine -- the line segment indicates the actual targeting line-- but again the displacement is on the X axis AFTER rotation, which is not working....

(It's not like I'm married to this order, it's just the way it makes sense to me.)
129433

129434

jeric_synergy
08-23-2015, 02:42 PM
Version 006: Working!
129435
Here's the working version. One of the problems was stupidity, mine, combined with 'history'-- I originally modeled the spring on the X-axis. Later I altered that to the Z-axis for simplicity in nodal work so that I could use the Forward outputs (which I don't really understand still, and didn't wind up using anyway, but things aligned along the Z-axis are usually easier to deal with anyway). Because of that history, I kept plugging into the X input on one node (see JPG) instead of the now correct Z input. :foreheads

Anyway, it was all very instructive, learned some more about nodes-- RH is right, you should just dive in and start slapping connections together, soon enough you have a clue even if you're not quite sure what's going on.

Thanks to Denis for the two nodes used here (no native Rotate? For shame, LW3dG!), to RebelHill for his tutorials, and to JoePoe for input on weight mapping.

129436

Slartibartfast
08-23-2015, 02:45 PM
It's late and I'm dead tired, so I haven't really looked into it, BUT
I think you are calculating stretch and rotation in parallel here. I think you need to feed the stretch-result into the rotation nodes to get it right.

/Slartibartfast

- - - Updated - - -

oh, you solved it while I was typing... zzzz good night

jeric_synergy
08-23-2015, 02:56 PM
Sleep, lil' Slartibartfast, ssssllleeeeppppp....

Yeah, we cross posted. STILL, I'd be happy to know how to control the order of evaluation. I'm sure it'll come up again in the future.

And, you were right. The dox for the Rotate node, at least the web page, are lagging behind the actual node a bit: there are now 2 more inputs/outputs than shown on the webpage. I'm not quite certain what the difference is between Delta and Vector as inputs, but, not too confusing even for a hopelessly confused nodester like me. I have no idea what I woulda done without those additional inputs on the Rotate node, and I'm extremely happy I don't have to find out. :D

Spring animations are fun to watch.

Slartibartfast
08-24-2015, 03:16 PM
STILL, I'd be happy to know how to control the order of evaluation. I'm sure it'll come up again in the future.
It is not a secret order of evaluation "behind the scenes", rather how you connect the nodes. Order is following the arrows, and any parallel arrows (two or more going into the same node) must both be evaluated before that node is calculated.
Example:
[some nodes A]-----> |ADD|
[some other nodes B]->|A&B|
Both A and B must be evaluated before the addition can take place. It doesn't really matter if A or B is calculated first. If you want to rotate a vector then add another vector, then you have to feed the rotated vector into the addition. Not the other way around.


I'm not quite certain what the difference is between Delta and Vector as inputs, but, not too confusing even for a hopelessly confused nodester like me. I have no idea what I woulda done without those additional inputs on the Rotate node, and I'm extremely happy I don't have to find out. :D
Well, you might not wanna read this then ;-)...
Displacement node expects the difference in position (relative position, often called "delta"), not absolute position. It can make things go kaboom if you forget (which I do most of the time)


Spring animations are fun to watch.
Sure is :D and I had to try making the scene without DPkit's excellent rotate etc. Just to see if I could. There is ofc easier ways to do it (like making the "reach" object a target) but what's the fun in that?!
129463

jeric_synergy
08-24-2015, 03:57 PM
So,
1) are there cases where users would input the nodal equivalent of "NOP" (in assembly language) in a network to FORCE the evaluation of a value?
2) what are good "NOP" type nodes? (I'm guessing "Add" with zeros would work, and use few cycles.)

Even in one node, such as DPKit's Rotation, there are intrinsic orders of evaluation that are not exposed to the user. I guess you could just chain them together if you wanted to alter the order. Like, I imagine that POSITION is evaluated interior to the node before ROTATION (this is just an example, I have no idea), and if you wanted to reverse the order you'd just use two separate Rotation nodes to accomplish the task.

Yeah, Delta: bites me on the *** pretty much every time. Pencils are looking better and better.

Slartibartfast
08-25-2015, 04:50 AM
So,
1) are there cases where users would input the nodal equivalent of "NOP" (in assembly language) in a network to FORCE the evaluation of a value?
2) what are good "NOP" type nodes? (I'm guessing "Add" with zeros would work, and use few cycles.)

Even in one node, such as DPKit's Rotation, there are intrinsic orders of evaluation that are not exposed to the user. I guess you could just chain them together if you wanted to alter the order. Like, I imagine that POSITION is evaluated interior to the node before ROTATION (this is just an example, I have no idea), and if you wanted to reverse the order you'd just use two separate Rotation nodes to accomplish the task.


Yes, within one single node, there is an execution order, but it won't help delaying the inputs. If you put a "sleep one hour before outputting anything"-node into say the rotation node, that rotation node will wait one hour to get the data and then execute its instructions in the same (wrong) order. So I guess the answer to 1) is NOPe :)
2) The logic node could be thought of as passing a NOP. Like a zero/one to disable/enable some effect.
The solution as you already figured out would be to chain the nodes, making them only do one thing at a time, so YOU can control the order.

:beerchug:

jeric_synergy
08-25-2015, 07:40 AM
I didn't mean NOP as a time waster, but as a way to step 'backwards' along the evaluation chain sequence.

RebelHill
08-25-2015, 09:00 AM
You set the evaluation order via the dropdown for nodal displacement.

What you're misunderstanding is that the directions differ based upon it (because you're evaualting the value of those directions either before or after they've been altered in some other way).

First you want to point the spring object... no need for nodal motion or rotate nodes, you can do it with plain ol targeting. The other methods would allow you for some circumstances to jump around orders a bit, as you can move rotations to the displacement step with some other rotation being evaluated after the motions step, etc... but this is far too simple to need that.

When it comes to the whole Z/X thing, it makes no real difference other than the letter used. With regular targeting ofc, the objects local Z gets aligned toward the target item (that's forward), so easiest is to model along that axis. If not, you can just do the target with a null. parent you spring item to that and rotate it, it makes no difference other than that the actual target local (face direction) for the spring is now along its X or Y (right or up).

So having targeted it, you need to displace the points by their weighted value along that direction. So you get the distance, factor in the weight to create the "ramp" the points get displaced over... You just now need to give it the direction along which to push those points by this amount.

Thus, you can either push the points by the amount in a fixed direction (Z or X or whatever) in the items local space before other local transforms take place... thus it stretches, then targets, in which case you have the first image. Or you can allow other transformations to take place locally, and displace this result (which means you're effectively in parent space and so the vector delivered must be relative to that space... a displacement occurring fixed on Z will not push along the items local Z, but the Z axis of its parent space.) So we use the setup in image 2, where we use item info to get the direction of the local Zaxis (the forward) and displace straight down that vector.