Q's on Projectile Motion and Blender

Support Particles and Physics Simulations
1

Hello,

I’m working on animating a ball being thrown up in the air, coming to a stop, and descending - simple projectile physics.

2.66 has some nice stuff to simulate what happens after the ball gets to the top of its trajectory (the fall accelerated by gravity), but I haven’t been able to find any information on how to “throw” the ball in the first place.

Is there any way for me to give the object an initial upward velocity, which can then be affected by gravity’s downward acceleration?

Thanks for any help.

2

You can use animated objects in Blenders rigid body simulation.
Select an object and make it an active rigid body. Then, e.g. on frame 1 give it a location keyframe. Got to frame 3 and move the object up slightly, and insert another location keyframe.
Now go to the rigid body settings. Under the “Type: Active”, there is a little checkbox: “Animated”.

You can animate this checkbox. Go to frame one, check “Animated” and with your mouse over the checkbox, press “I” to insert a keyframe. Go to frame 3, remove the checkmark, and press “I”.

This tells the simulation that it should leave the object alone for the first two frames, and only take over at frame 3. The object will then inherit the velocity from the animation.

Be careful with how much you move the object in your manual animation though, a little movement over only 2 or 3 frames is a huge acceleration, so it will fly up quite long if you move it too far up.

3

Thank you, Lommbard. I just tried it, and it works!

Is there any way to try and refine the process a bit - to actually be able to use m/s of initial velocity?

4

You can change your blender units to be meters. And you have a relationship between number of frames and time given by your frames per second. So I’d imagine that you can move yor object a certain number of units in say 24 frames. I’d imagine this would give you dUnits/seconds initial velocity, but then again, I’m pretty bad at physics.

5

D’OH - yeah, I thought of this after I posted! I monkeyed with this for a bit, and found that a 1-frame difference mucks the whole animation up. It’s as if Blender can’t compute that small a difference, and ignores any upward velocity. However, when using a 3-frame difference, everything seems to work very well.