TrueArt Item info

[pinkmouse]

TrueArt Item info and Nodal Motion

I've been playing with nodal motion and have a query about using the above plugin.

I have an item driven nodally, a missile that is stationary until frame 120, then moves towards a target. Now, I'd like to align the missile along its track better, and so wanted to find a previous position I could use to do so.

So I thought I could use the TrueArt extended item info, using a five frame time delay to output a previous position:



As you can see, at frame 120 the two position vectors match, as I would be expecting before the item starts moving. However, when I advance the frame to 125, not only has the item position changed, the delayed position has also changed:



Am I completely misunderstanding this tool? I've tried with both position and world position with no difference, different delays etc. etc and am stumped. Any hints?

 

[Sensei]

Extended Item Info is asking LW what is position or other parameter of item at given frame/time, and just returning to user what LW returned.. It should work only for key-framed (or baked) params.

Attach scene for checking.

Are you starting moving missile at 120 frame?

 

[pinkmouse]

It should work only for key-framed (or baked) params.

Ah, that might be it then. Any way of doing it "live", without baking/keyframing?

Attach scene for checking.

Will do, just need to finish making dinner, then I'll strip out all the nonsense and irrelevant stuff and package it up.

Are you starting moving missile at 120 frame?

Yup, as you'll see...

Thanks!

 

[pinkmouse]

Right, whilst the mushrooms for the risotto are frying, here's the scene. I'm sure it will all make sense once you open it up, but any questions, just ask.

 

[Sensei]

Ah, that might be it then. Any way of doing it "live", without baking/keyframing?

It doesn't exists. Exists only what is in current frame. Additionally you would be running into recursion = you want take position 5 frames earlier, modify and plug to the same as you just got. It would be f.e. frame 200 is requesting frame 195, which rely on frame 190 etc. etc. in some cases it would go to infinity..

 

[pinkmouse]

Not sure the recursion thing is relevant. Yes, if I was looking forward I can see the problem, but as all I'm doing is looking to where something was to alter rotation not position, I don't see that it would cause any mathematical issues.

I could solve the problem using a null following the missile with a five frame delay, (just altering the keyframes on the gradients), and use that as a reference, but it isn't a very elegant solution. Perhaps something like a sample and hold node would be nice.

 

[Sensei]

Such dynamic tricks don't work on renderfarm and don't work in random frame rendering, like pausing/resuming F10 render scene in chunks. If frame X needs something from frame X-Y, then it must be done already and remembered, otherwise it can't be read. That's why there is baking needed.

 

[tbagger]

How is the missiles position being driven?

 

[pinkmouse]

How is the missiles position being driven?

A gradient node shifts the position of the missile according to time, from the position of the launcher to the position of the target. It's the animation I showed in your MG tutorial thread.

Other gradients drive the rotation of the bits of the launcher, which the missile copies, then will crossfade, hopefully, to the tracking solution. Currently the missile just gets its alignment from the position of the launcher to the position of the target. This would actually be quite satisfactory if the motion of the target wasn't quite so extreme.

 

[pinkmouse]

Such dynamic tricks don't work on renderfarm and don't work in random frame rendering, like pausing/resuming F10 render scene in chunks. If frame X needs something from frame X-Y, then it must be done already and remembered, otherwise it can't be read. That's why there is baking needed.

Fair enough. That'll be Lightwave then.

It just seems strange that the calculation isn't working. The position is derived mathematically as input from an equation, so perhaps if I drove the target with nodal motion as well rather than a keyframe, then all the calculations should be accessible within the nodal system. Hmm.

 

[tbagger]

A gradient node shifts the position of the missile according to time, from the position of the launcher to the position of the target. It's the animation I showed in your MG tutorial thread.

Other gradients drive the rotation of the bits of the launcher, which the missile copies, then will crossfade, hopefully, to the tracking solution. Currently the missile just gets its alignment from the position of the launcher to the position of the target. This would actually be quite satisfactory if the motion of the target wasn't quite so extreme.

I think you can get this to work, if you shift the fade gradient that is dealing with the position it will output a different position, and then you can use the "align to" or equivalent to target from current position to the position with the shifted gradient. So basicaly... two gradients and two positions. I assume you are using a keyed null for the gradient? If so the time input on the null will work to set up both gradients so you dont have to resort to using extra nulls for the shifted gradient.

I will see if I can get it to work... and get back to you. May not be till tomorrow though...

 

[pinkmouse]

No rush Brian, off at the other day job tomorrow fixing PA equipment. Your solution is the sort of thing I was referring to in post #6 above. As I said, possible, but doesn't seem that elegant.

 

[tbagger]

No rush Brian, off at the other day job tomorrow fixing PA equipment. Your solution is the sort of thing I was referring to in post #6 above. As I said, possible, but doesn't seem that elegant.

It wont be too unelegant if you are using a keyed null/channel for the gradient. You wont have to add extra nulls or anything. Sensei is right, but usually the animation is driven by some keyed object at its base... so that is the object that needs to be referenced, not the object you are driving.

 

[pinkmouse]

Yup, in this case everything is driven by the keyed position of the target, and the more I think about it, the more I get Sensei's point.

Anyway, here's another version of the scene for you or anyone else to have a play with if you'd like. I've cleaned out the input spy stuff and swapped out a few other nodes so it's not quite so crashy with 11.6.

edit: Thinking about this delayed null has given me a really cool idea. Spiralling missiles a la Transformers 3 intro sequence anyone?

 

[tbagger]

Yup, in this case everything is driven by the keyed position of the target, and the more I think about it, the more I get Sensei's point.

Anyway, here's another version of the scene for you or anyone else to have a play with if you'd like. I've cleaned out the input spy stuff and swapped out a few other nodes so it's not quite so crashy with 11.6.

edit: Thinking about this delayed null has given me a really cool idea. Spiralling missiles a la Transformers 3 intro sequence anyone?

Yeah its possible... here is the setup. I still could not load your file cause I am on 9.6, but here is test scene I made. I have to use Dponts node motion cause 9.6 didnt have native version. So you have to instal if you want to see set up.
http://dpont.pagesperso-orange.fr/plugins/nodes/nodes/Node_Editors.html#NodeItMot

 

[pinkmouse]

Thanks Brian. Not quite the way I was thinking of doing it, but it looks like an interesting solution. Just back from a long day at work, so I'll give it a try tomorrow.

 

[tbagger]

Thanks Brian. Not quite the way I was thinking of doing it, but it looks like an interesting solution. Just back from a long day at work, so I'll give it a try tomorrow.

Doesnt have to be exactly like the one I posted. You should be able to modify your set up to do similar effect as long as the gradient is controlled by something that has key frames on it. This was just quick test I did to see if it could work. You said your gradient was controlled by the target... this will also work. The trick is shifting the gradient with the time input on item info with whatever object you are using to control it.

 

[pinkmouse]

I'm more intrigued by the different way you used to get the solution to the way I was thinking it would work.

Here's a pic of my nodal setup I did yesterday but didn't get 'round to posting. I find it interesting the way different people use different approaches to get the same result.

 

[tbagger]

I'm more intrigued by the different way you used to get the solution to the way I was thinking it would work.

Here's a pic of my nodal setup I did yesterday but didn't get 'round to posting. I find it interesting the way different people use different approaches to get the same result.

Yeah, using the time/frame is the way I would have done it in real situation. I thought you were using keyed target to drive the gradient but time/frame is better. I would have thought you had to use the frame+1 in one of those gradients to get a proper target. As you have it, it looks like its always targeting from the launcher position instead of its current location. After messing with this last night I thought of a bunch of ideas for doing multiple missiles using part move and similar method. You could get some really good effects.

One thing that would be cool is to use an in between position based on the average of the launcher and the target, but based on the targets position a few frames behind its current location using time input. It would give it a bit of lag effect.

 

[pinkmouse]

As you have it, it looks like its always targeting from the launcher position instead of its current location

Yes, that version is. I plan to crossfade from that version of rotation, (which move matches the launcher), to the tracking version after launch.

After messing with this last night I thought of a bunch of ideas for doing multiple missiles using part move and similar method. You could get some really good effects.

Just what I'm planning to do today.