acceleration calculation

[mic]

hello!

i have some points for which their velocity is computed (using Trail SOP). and i want to calculate acceleration. the way i do it is using Slope CHOP - but: how can i compute it for every point? i have 'velocity' point attribute and i can fetch only channel, not "per-point" attribute..

[johner]

hello!

i have some points for which their velocity is computed (using Trail SOP). and i want to calculate acceleration. the way i do it is using Slope CHOP - but: how can i compute it for every point? i have 'velocity' point attribute and i can fetch only channel, not "per-point" attribute..

You need to change the "Method" parameter on the Geometry CHOP from "Static" to "Animated" and do the same for the Channel SOP that is bringing the values back in. That way you get one channel per position channel per input point and one sample per frame. So you'll get the "tx0 ty0 tz0 tx1 ty1 tz1," for example, sampled across the entire frame range. This is really cool for working with geometry in general, with a couple of caveats.

The Geometry CHOP has to evaluate the incoming SOP for the entire frame range when set to "Animated", which can be slow unless you have a simple POP net, or use a Cache SOP or something. You just need to remember to keep it up to date. Also, I found that it can behave a little strange when particles are being emitted throughout the frame range. The values for the first frame a particular are emitted are "held" for all the frames preceding. I haven't found a way to change that. Shouldn't really matter for the Slope CHOP, but it bit me when using the Area CHOP.

You could also do something like add an Attribute POP at the end of your POP network and create an attribute called "prev_v" or something with the values $VX, $VY, $VZ, i.e. cache the velocity at the end of the last timestep. Then in either VOPs or another attribute POP, calculate the acceleration (approximate the derivative of v) as:

(v - prev_v) / timeinc

I think the Slope CHOP might be a little more accurate (in theory it can use samples from the timestep before and after, but I don't really know). But if you oversample your POP net, you should get more and more accurate values as you increase oversampling.

Edited February 4, 2009 by johner

[mic]

thank you very much, Johner!!

Edited February 4, 2009 by mic

[johner]

thank you very much, Johner!!

Sure thing. One thing I forgot to mention, if you're using the Geometry CHOP and Channel SOP approach, you have to be careful if you have particles that die during the frame range. Since point numbers get reused in particle systems, and that's how those CHOPs distinguish different points.

Anyway, you can fix this by setting the "Organize by Attribute" parameter in both the Geometry CHOP and Channel SOP to "id" (without quotes), since particle id's aren't reused.

[johner]

By the way, I'm assuming you're setting the velocity directly in your POP net or something? I ask because if you're only using regular force-like POPs to affect your particles, the "accel" property may already be set correctly on the points coming out of the POP net. I also don't think it works for collisions which I think are handled as impulses, or instantaneous changes to velocity. So for the general case I think you need something like you're doing, but in some cases using the "accel" attribute might work.

[SpencerL]

By the way, I'm assuming you're setting the velocity directly in your POP net or something? I ask because if you're only using regular force-like POPs to affect your particles, the "accel" property may already be set correctly on the points coming out of the POP net. I also don't think it works for collisions which I think are handled as impulses, or instantaneous changes to velocity. So for the general case I think you need something like you're doing, but in some cases using the "accel" attribute might work.

acceleration is the change in velocity. if you want to do this in SOPs all you have to do is subtract the current velocity from the previous frame/timestep's velocity. But this way assumes that the point count does not change over time.

Edited February 4, 2009 by SpencerL

[johner]

acceleration is the change in velocity. if you want to do this in SOPs all you have to do is subtract the current velocity from the previous frame/timestep's velocity. But this way assumes that the point count does not change over time.

Yep, I imagine you could do this all in SOPs. One thing I'd add is that as I said above, you have to divide by the timestep to get the true (well, approximate) value for acceleration:

(v - old_v) / timeinc

But if you only want a direction you're right you only have to do the subtraction.

Come to think of it, what's the best way to cache the velocity value from the previous timestep in only SOPs? I imagine you could do it with a Cache SOP or TimeShift SOP or something, but wouldn't it be easier with an Attribute POP like I mentioned above?

Edited February 4, 2009 by johner

[SpencerL]

Yep, I imagine you could do this all in SOPs. One thing I'd add is that as I said above, you have to divide by the timestep to get the true (well, approximate) value for acceleration:

(v - old_v) / timeinc

But if you only want a direction you're right you only have to do the subtraction.

Come to think of it, what's the best way to cache the velocity value from the previous timestep in only SOPs? I imagine you could do it with a Cache SOP or TimeShift SOP or something, but wouldn't it be easier with an Attribute POP like I mentioned above?

as long as the point count does not change, you could use a timeshit SOP > $F - 1 to get the previous frame. Then you could wire the current v into the first input of the point SOP and the timeshift SOP into the second input. Then you could do

$VX - $VX2, $VY - $VY2, $VZ - $VZ2

[johner]

as long as the point count does not change, you could use a timeshit SOP > $F - 1 to get the previous frame. Then you could wire the current v into the first input of the point SOP and the timeshift SOP into the second input. Then you could do

$VX - $VX2, $VY - $VY2, $VZ - $VZ2

Cool. But you'd probably want a Cache SOP between the POP net and the TimeShift SOP, right? Otherwise if you're at frame 100, say, when the TimeShift SOP cooks to get frame 99, it has to re-cook all 99 frames from that POP net to get frame 99. With a Cache SOP in between it just pulls it from the cache. Of course Cache SOP doesn't seem to play nice with non-integer frames so oversampling would be tough, but in general that should work. And to get a "true" acceleration vector when you're not oversampling anything, you can just multiply your expressions above by $FPS (i.e. divide by 1/$FPS). Neato.