Archived

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

doogle

Force or velocity reflection?

Recommended Posts

I''m making a physics engine for my 2D, side on bike game (like elastomania). I have some free bodies, which I eventually want to be able to attach together, such as the rider to the bike, or the wheel to the bike. These joins may be spring constraints. When I detect a collision, should I apply a force to get the object to bounce, or reflect the velocity vector? At the moment I do the latter, but I only have one object. When it comes to joining more objects together, I''m thinking that directly changing the velocity may lead to problems. I couldn''t get applying a force to work though... because theoritically the object only bounces if it has some sort of elasticity, right? Any comments on this, or my general outlook on my physics would be much appriciated before I head too much down either path. Thanks.

Share this post


Link to post
Share on other sites
>> because theoritically the object only bounces if it has some sort of elasticity, right?

Right. If your object is not elastic the force will be applied over a distance of zero in zero time so either a) change in momentum and energy will be zero (dE = Fdx, dp = Fdt) or b) your force will be infinite which is not computable.

In the (physical) theory of collision have a set of initial conditions (momentum, ernergy, position and mass of the objects) and some boundary conditions (conservation of energy and momentum, objects cannot penetrate each other at any time). With these you can calculate the outcome of the collision without knowing the forces acting on the objects. Note that conservation of energy does not say conservation of kinetical energy. The change of kinetic energy comes in as a free parameter (I think there are methods that compute that out of objects properties but these properties are also a free parameter in the end).

Reflecting the velocities is only true for certain special conditions (I think it´s when your system of reference is the center-of-mass system but I´m not 100% sure of this right now).

Share this post


Link to post
Share on other sites
Springs: F = -kx
k is a constaint representing the elasticity or thickness of the spring. x is displacement. f is force from the spring

Force: F = ma
m is mass (not weight) and a is acceleration

Weight: W = ma
m is mass and a is acceleration, guess what? weight is a force. note that weight as we know it is mass * gravity because gravity is an acceleration. Usually 9.8 at the surface of the earth.

Velocity: V = AT
Acceleration * time

Hopefully those will help you out. You''ll have to figure a k for your objects and apply the force figured from the object''s velocity and the velocity caused by gravity in some cases. Then you will have an opposing force causing them to accelerate in another direction.
Good Luck,
Brekahan

Share this post


Link to post
Share on other sites
Ok, so say I make my object elastic... does this mean the actual model needs to be compressed? For example, when a tennis ball bounces, it remains on the ground for a certain time (a few milliseconds I imagine), and experiences a force depending on its compression for this time.

With my simulation though, it would be hard to compress the whole model. If it doesn''t compress though, it either moves slightly into the ground, or if I move it back to the surface ever frame, doesn''t rebound properly.

My main collision will be the wheel with the ground. The only reason the wheel bounces is the air in the tire acting like a spring... so I considered placing lots of short springs from the edge of the wheel outwards to the edge of the tire. This seems unecessarily complicated (and possibly cpu cycle expensive) for what I need.

Maybe I just need to simplify my whole conecpt of collisions? But ever time I do this, collisions with mulitple connected objects seems impossible.

Share this post


Link to post
Share on other sites
the compression will not be noticeable. Either it moves too fast, or the actual compression is too small. You should not worry about compressing the model, unless you want to do some ''wacky racers'' rendering style or wobbly materials (jello or something).

Having forces also helps with modeling a proper rotational velocities and torques, which would be quite important in an elastomania type of game.

you can try with velocities, if you got that working already. You may want to look into the verlet integration scheme for simplifying constrains solving (see The Hitman 2 character physics article on gamasutra).

Moving to a full on rigid body dynamics is not that straight forward.

Share this post


Link to post
Share on other sites
Hey.... great article oliii... I read that ages ago, but it makes much more sense now.

Well, I''m off to write my physics engine from scratch Thanks for the advice all.

Share this post


Link to post
Share on other sites
guess what?
I''m supposed to be doing physics homework on...collisions!

Ok.
Basically, you will need the Force, er, forces.

F = ma

(mass * acceleration)

Relating to distance is work

W = F dot d.
(dot operator, see vectors)

Relating mass to velocity is momentum

p = m dot v

A completely inelastic collision is where 2 objects stick together.
This is where the gum hits the pop can.

Thats a single velocity vector describing the behavior of both objects.

Then there is completly elastic collisions.

p1i + p2i = p1f + p2f

momenta of each object before/after collision.
Note that you will need lots of predetermined constants to determine the final velocity of a variable.

I''m not sure how to code up the kinetic/potential energy equations in a game-meaningful form.

Impulse(force of collision)
I = delta-p = avg(force)*delta-time
(changes in p and t)

You would use this to determine deformation in regards to a constant of deformation associated with the material, I believe.
(yes no here people plz) I don''t think this would be important

Also, remember to include friction in you model.

force-of-friction = (normal-vector perp. to surface) * coeff. of friction, is friction opposite force of motion. Use this to burn off some speed to get down to 0. :-)

Can''t think of anything else at the moment.

~V''lion

Bugle4d

Share this post


Link to post
Share on other sites
here is another article that got me started on the whole rigid body dynamics.

http://www.cs.unc.edu/~ehmann/RigidTutorial/

I''ve got an old small demo of a cube bouncing on a plane, and another one with lots of cubes bouncing around, so if you want them, mail me.

Share this post


Link to post
Share on other sites