Archived

This topic is now archived and is closed to further replies.

DuncanBojangles

Pogo stick physics

Recommended Posts

Hey guys. Still at work on my pogo stick game, now that it''s actually fun for me to play, *cough*, test it. I''m a little mystified about the physics. You see, I set it up so that when the pogo stick hits the ground, a vector is produced by doing some [insert funny vector math stuff] with the normal of the ground (which is uneven). Well, it works like it is supposed to. I watch my little guy, and whenver he bounces on something, he''ll move a little in the direction the ground is facing, just like I do in real life, bouncing on an incline. I''ve noticed, though, that he can''t get over very steep stuff. Should I be considering adding momentum to the equation? Because he''s leaning pretty far forward and he should be going farther each jump. Currently, each time the pogo stick comes in contact with the ground, the resulting direction vector is a combination of his angles to the ground and the normal of the ground. I just realized that I don''t know if normal is even the right word. It''s the same thing used in lighting calculations, if that helps. It''s 3:30 in the morning. I need sleep. "Donkey, if it were me, you''d be dead." I cna ytpe 300 wrods pre mniute.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
ya, you need to factor in the guy''s weight... & based on his/her height, you can just place the weight at the character''s center of gravity. So the resulting motion of the character is effacted by its existing momentum plus the force on the character from the stick. you''ll need to develop a tricky system that gives you frame-rate independent motion. so a little integration will be necessary.

Share this post


Link to post
Share on other sites
I''ve already got the time-independent motion part done, that was last post I looked in everything I could find related to physics, and it seems there''s no *good* way to cut corners for *real enough* and speedy. I''ll have to use the formulae, but I won''t include rotational accelerations as the guy kinda rotates, then holds that position, so acceleration is instaneously 0 (unless that''s the exact moment he hits the ground, in which case I''ll make him fall ... Muahahahah!) Thanks for the help, lonely poster.

"Donkey, if it were me, you''d be dead."
I cna ytpe 300 wrods pre mniute.

Share this post


Link to post
Share on other sites
I''ve done a simulation of a spinning top which is kinda similar since you have translation and rotation at the same time.

If you want to do it physically correct, you need the equations of motion of a rotating system. It tells you how to change the current axis of rotation (direction and rotational speed). You end up with an ordinary differential equation (just like Newton''s motion, though a bit more complicated and non-linear) and you can use the same method of integration (i.e. time-stepping). Grab a good physics book and read the chapter about rigid body motion (I only know the German word, I tried to translate it).

Is it 2D or 3D motion?

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
good question about the 2d / 3d motion... are there slants so that if the guy who is jumping forward on the stick... could be bounced to the left or right or is it like a side scrolling game? in either case... the same rules apply...

I don''t think its as hard to calculate these things as you make it sound... as soon as the pogo stick touches the ground... lets assume no slippage... you can take the point & over the time period that the stick is touching the ground... you just calculate the force (along the length of the stick) & apply it to the guy''s momentum. your framerate independent movement will have to do many calculations over a frame or just a couple... because of the small piecewise integration of the force & momentum. The force of the stick has to do with spring physics of course... & one of the nice features you might include... is bigger & better sticks... & maybe even fatter/skinnier characters... that will bounce differently.

Share this post


Link to post
Share on other sites
That's an interesting question you have there. What you *may* be forgetting is that to equate force with momentum you need to multiply the force by a minute frame of time, namely the time of impact (also called impulse). Just add the impulse vector to the momentum vector to get a reasonable result (just to be clear, the force here is the Force the ground exerts in the direction of its Normal). Physics is a pain isn't it? The only problem now is picking suitable collision timeframes and/or momenta. When lutz says ordinary differential equations he means the general solution for the differential equation F = -kx", which is well-known as something along the lines of x(t) = sin(wt)*e^(-bt) + cos(wt)*e^(bt). You can probably find it online somewhere. I'm pretty sure just conserving energy will work fine, because non-linear differential equations are probably a little more complicated than you really want here.

[edited by - uber_n00b on May 27, 2004 12:33:16 AM]

Share this post


Link to post
Share on other sites
Thanks for all the tips guys! The "simulation" is in 3d so he can bounce in all directions, though I limit his ability to rotate himself on the y (turning around) axis and the x (forward or backward) axis. I left out z axis rotation ''cause I couldn''t find an equation I liked that didn''t require too much change on my whole game physics. He has full range of "bounce off of ground" motion. I cheated on the spring physics by just giving him an arbitrary force along the vector of his direction. I wanted to know what the bare minimum was to get "realistic enough" bounce and movement without bogging my game (and my time) down in physics. I''ll try out all of your tips and see what works best.

"Donkey, if it were me, you''d be dead."
I cna ytpe 300 wrods pre mniute.

Share this post


Link to post
Share on other sites
Sorry to resurrect a dead (or near dead) post, but I''m having a bit of trouble understanding pretty much any physics at the moment. From what I remember from high school, the three things affecting this guy''s movement are gravity, momentum, and the force created when he bounces off of the ground. I can find (sorta) the force that is created when the guy bounces off of the ground using an arbitrary value as "amount of bounce" and the normal of the surface he is bouncing off of. The force that is calculated, is that the momentum? The only other thing affecting his movement is gravity. The force is constant, and gravity is added to it to make the guy move. So is this momentum?

"Donkey, if it were me, you''d be dead."
I cna ytpe 300 wrods pre mniute.

Share this post


Link to post
Share on other sites
Don''t be sorry ^^, we all have that understanding physics issue. Heck I''m fresh out of AP Physics C (M) and all that basic BS catches me. Momentum has this relationship with Force:

F = dp/dt , therefore, by multiplying by a small fraction of time (dt) you can figure out what P is by multiplying the force by that small fraction (which is the appropriate value to add to the momentum of the pogo stick to push it out and away via the normal.

Share this post


Link to post
Share on other sites
Sorry to ask, but what is ''p'' in your formula? I know that force is change in velocity divided by change in time, so I''m not sure what you mean by ''p''.

"Donkey, if it were me, you''d be dead."
I cna ytpe 300 wrods pre mniute.

Share this post


Link to post
Share on other sites
Alright... lets clear some things up as simply as possible....

Momentum is just P = V*M
P is used because M is already used for mass, and V is velocity.
The momentum of your character is what will be changing as he bounces at different angles & what not. We describe that change as acceleration, he either accelerates to slow down, or speed up, or even for turning... an acceleration that isn't front-to-back, but rather to one side. acceleration of your character... which is probably the thing you'll be calculating for... is found to be the sum of the forces on your character divided by the mass of the character. A = F/M

What you are going to do with that acceleration is apply it to your characters current velocity. V2 = V1 + A*t. The velocity vector of your character (V2) will be whatever it was the frame before (V1), plus its acceleration (A) times the frame period (t).

Here is a true statement: an objects final velocity, or rather... current velocity is simply the sum of all of its accelerations over time.
You might try taking a stab at your pogo-stick stuff using just these facts.

notes on momentum: momentum is NOT force, its better thought of as... energy. F = dP/dt just means that force is the derivative of momentum.

we know these:
F = M*A, P = M*V, F = dP/dt
so with 3 simple substitutions... you can take out mass...

F = dP/dt -> M*A = dP/dt -> M*A = d(M*V)/dt -> A = dV/dt

which gives us another well known equation, acceleration is just the derivative of velocity. thats how all these things are related. NOTE: the reason we can take M out of that derivative is because it never changes with time... its just a coefficient to velocity.

clear as mud? in other words, force causes a change in momentum. which I like to think of as "energy".


[edited by - Luke Miklos on June 1, 2004 1:21:06 AM]

Share this post


Link to post
Share on other sites
Dude, thank you so much. That was an awesome explanation. Yeah, I guess I was wrong about some things from the beginning. All this physics stuff was much easier in high school. I guess putting it all together into one thing is the hard part. Thanks for your explanation, and now I can get back to having some fun (coding). Thanks again!

"Donkey, if it were me, you''d be dead."
I cna ytpe 300 wrods pre mniute.

Share this post


Link to post
Share on other sites
I seriously hope this is the last time I have to post about this topic. It''s driving me crazy! I understand that I need to know all of the forces acting upon the body (guy and pogo stick) so that he can move accordingly. So, the first force to deal with is gravity. The force due to gravity would be

force of grvaity = mass of body * acceleration due to gravity

So that''s done. Now, whenever the guy bounces off of the ground, the surface applies an equal and opposite force to the body. The remaining force is the guy''s "bounce", which is modelled using spring physics. The force exerted by a spring is

force of spring = spring constant * compressed length

And this force always occurs along the vector of the compression. To find out how much the spring compresses in a given amount of time, I need to know the force due to gravity and the force the surface exerts on the guy. Since this bounce occurs in a short amount of time, I''ll oversample to get a finer degree of accuracy. So I add up the gravity and surface vector, compress the spring along the vector the guy is travelling, and add that force to the remaining forces to get the final force. So once I have all of the forces, how do I get the acceleration, velocity, and position from this? I think I''ve answered most of my own questions, but I''m still fuzzy as to what to do with all of the forces once I calculate them all. Thanks for putting up with me and helping. Once I get this done, I think I''ll let y''all try it out. It''s kinda fun, but next I work on skeletal animation so I can put in a trick system like "Dave Mirra''s BMX" and "Thrasher: Skate and Destroy". And ragdoll.

"Donkey, if it were me, you''d be dead."
I cna ytpe 300 wrods pre mniute.

Share this post


Link to post
Share on other sites
somebody else wanna get this one? I think what you are basically asking for man... is the algorithm to position your character in the correct place in the scene based on the physics model you have set up. I just thought about another thing... a tricky part to handle is when the guy reaches the bottom of the bounce... so you wanna make sure you iterate with enough resolution to get the forces along the way to the maximum spring compression & then back up again, just be careful to test for the end of the bounce.

Share this post


Link to post
Share on other sites
Yeah, I plan on using oversampling even if it ruins the framerate ''cause I want the physics to be accurate so that the game can be more fun. I kinda answered all of my own questions, the only one that is left is: Once I have the net force acting on the body ... how does that relate to acceleration of the body? Is it something as simple as

force / mass = acceleration

? And how would I handle variable framerates? Do I just add

* elapsed_time

to all of my forces? Or just the final force? Other than that, I understand everything else. Thanks so much for all of your previous help.

"Donkey, if it were me, you''d be dead."
I cna ytpe 300 wrods pre mniute.

Share this post


Link to post
Share on other sites
oh... I thought you already took care of the framerate independent movement...

in answer to your question: yes, you need to use elapsed time, but the only elapsed time that you will know is the elapsed time from the previous frame... which will work just fine. So basically, as far as the physics are concerned... when the new frame begins... you make sure you have the frame period of the previous frame, assume the current frame will exaclty that long, and then begin your fine precision iterations, so in pseudo code it will look like this:


//frame period will be about 0.01667 seconds for a 60Hz program

//I haven't tested anything like this, but 50 or so iterations should be real good for physics resolution


float smallAmountOfTime = 0.01667f / 50.0f;
position tempPosition;
tempPosition = character->getPosition();
tempSpeed = character->getSpeed();
float i;

//being fine precision iterations:

for( i=0.0f; i<framePeriod ; i+=smallAmountOfTime ) {
forceVector = character->getForces();
accelerationVector = forceVector / character->getMass();
//its very important that you update the guy's speed & position like this

//because the next iteration... the forces will be slightly different because they are based on his position

tempSpeed += accelerationVector * smallAmountOfTime;
tempPosition += tempSpeed * smallAmountOfTime;
//set new values for character

character->setPosition(tempPosition);
}

character->setSpeed(tempSpeed);



is this what you were looking for ? if you don't know the vector math behind these function calls, then you are screwed... but I assume you do because of the nature of your project. good luck


oh also... if you wanna get real nit-picky, you can adjust his position by the average speed between iterations, rather than the new speed (which is calcuated as the speed the guy has at the end of the iteration)

[edited by - Luke Miklos on June 8, 2004 7:55:36 PM]

Share this post


Link to post
Share on other sites
Thanks! That kinda helps. After thinking things through, I answered all of my questions regarding the physics aspect. I thought 10 iterations would be enough, but I guess not. Thanks for the help!

"Donkey, if it were me, you''d be dead."
I cna ytpe 300 wrods pre mniute.

Share this post


Link to post
Share on other sites
Just one more thing ... and Luke Miklos, thank you so much for your time and patience. You have really helped me and I know I must be bugging everyone by now. I figured out everything.


force_of_gravity = mass * acceleration_due_to_gravity * elapsed_time


The force of the spring took me a while to figure out.


angle_between_surface_and_pogo_stick = (acos((surface . pogo) / (|surface| * |pogo|))) / 90 //arcCos of dot product of surface and pogo divided by product of surface and pogo's magnitudes

spring_compression = speed_of_pogo * angle_between_surface_and_pogo
spring_force = -spring_constant * spring_compression * elapsed_time


That last bit is based on the fact that a pogo stick can only compress in one direction, which happens to be the guy's orientation in the air, his vector. If the pogo stick is perpindicular to the ground, then it can compress with the full force. If the pogo stick is 45 degrees to the ground, then the pogo stick can only compress half as much as it could upright. And if it hits a wall, then there is no compression at all.

These calculations are based on the guy's old velocity, right before he hit the ground. So when I need to find the force that the surface applies to the guy (which is equal and opposite to the guy's force), should I use his new force obtained by adding the new spring_force and gravity_force, or his old force before he hit the ground? I wonder, because the spring_force calcultions use his old velocity, so should the surface_force also be based on his new velocity? This all happens in one iteration of the oversampling. I think there may be calculation errors, but I can't figure out in which method they would occur. This is it. That was the last question. Once I know which method is error-free, I can finally put it all together. So please help, if you don;t mind, so I can rid myself of this problem.

"Donkey, if it were me, you'd be dead."
I cna ytpe 300 wrods pre mniute.

So I forgot how to use the source tags.


[edited by - duncanbojangles on June 9, 2004 4:19:05 AM]

[edited by - duncanbojangles on June 9, 2004 4:44:48 AM]

Share this post


Link to post
Share on other sites
ok, first of all... force from gravity is NOT:
F = M * A * time

its simply:
F = M * A

now you wanna keep it in terms of force though... & not divide out the mass just yet... because there are other forces acting on your character & you need to compute your final force vector.

I''ll cover the rest later... I''m at work

Share this post


Link to post
Share on other sites
[bold figure = vector]

do (each frame)
{
t = 'time elapsed since last frame'

// Calculate your new position based on the current velocity
// and force

F = 'add up all forces acting on object'
a = F * m
s = v * t + 1/2 * a * t2

position += s


// Calculate new velocity based on current velocity + acceleration (~force)
v += a * t
}


This should do the trick of updating the position of your player each frame. The tricky part will be calculating the forces

This only works well for small enough t , the smaller your framerate the less precise this gets. You'll either have to guarantee a solid (high) framerate or put physics into its own thread and make it run at a high enough rate. There's ways to improve this (using other means then euler formulas) but they're beyond my power of explanation

~edit: font colors & formating...

[edited by - Wildfire on June 9, 2004 3:07:59 PM]

Share this post


Link to post
Share on other sites
Well, in response to Luke Miklos, yes, I know that F = M * A, but I have been handling framerate independent movement by multiplying by the elapsed amount of time, as someone said in an earlier post, and it has worked for me.

In response to phlaz, No, I''ve never even heard of "Pogo Joe". I''ll try to find it.

And finally, Wildfire, thanks for the tip. I''ve already got all the forces figured out, I was having problems because some of them (the forces) use the velocities before contact to find the resulting force, though some of them could use the new velocity, which might create errors in the math.

"Donkey, if it were me, you''d be dead."
I cna ytpe 300 wrods pre mniute.

Share this post


Link to post
Share on other sites
all wildfire''s algorithm is... is a more formal version of mine (which was written as pseudo code). His uses average velocity each iteration instead of final velocity... but since he has set his up to run once a frame instead of 50 times... he really needs that tweak in a bad way.

& duncan... don''t name your variables something they are not.

m * a * t = P (momentum, not force), I think... at least a twisted form of it.

you will thank yourself later when you re-use the code or call upon that variable from another part of the same program.

with "complex" concepts or algorithms... its much better to be explicit (its professional) than to hack at it so it works.

Share this post


Link to post
Share on other sites
Okay, okay, I get your point: mass * acceleration * time != force. I''m sorry, but that''s how I was handling framerate independent code. It was a mistake in my math, not my variable naming skills. I''m usually very explicit with my variable names, and I would have known perfectly what I meant by looking at the name. Thanks for all of your help, I''ll just try both ways and see what works.

"Donkey, if it were me, you''d be dead."
I cna ytpe 300 wrods pre mniute.

Share this post


Link to post
Share on other sites
quote:
by Luke Miklos
but since he has set his up to run once a frame instead of 50 times [per second]... he really needs that tweak in a bad way.


Yes, I agree. It will only work as long as framerates stay high enough.

I think you should see mine more as an explanation where time gets involved in the whole thing .

Btw. I''m guessing you mean 50 times a second, not fifty times a frame.

Share this post


Link to post
Share on other sites