• ### Popular Now

• 13
• 15
• 19
• 27
• 9

#### Archived

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

# Intersection and then what (edited)

This topic is 5029 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hello. I am using spheres for intersection check and have done well so far. Currently my two spheres intersect at ONE point only. But what then? What I want todo is: A and B collide and the "bounce" off each others. Possibly spinning a bit. How do I go about achiving an effect like this. [edited by - middy on June 10, 2004 1:28:12 PM]

##### Share on other sites
Bouncing two spheres off each other is very easy, simply use conservation of momentum along the collision normal. Loss of energy is simulated by setting a coefficient of restitution for the pair between 0 and 1 (0 = looses all energy, 1 = looses no energy). These really are very basic concepts and any core physics text book should cover them.
Spin is a bit more difficult and involves taking friction and angular momentum of the spheres into consideration. Again however, any core physics book worth its salt should cover these topics very well.
Text books shouldn''t be just something you have to endure at school and then forget about. They are wells of knowledge and inspiration and should be treasured.

##### Share on other sites
Thanks Motorherp. I have already implemented a function like that and while. I may seem realistic. I was hoping for something fast and easy, since its an arcade like game. So speed is of the essense.

##### Share on other sites
These sorts of collision routines tend to be the most core level functions at the heart of many physics/collision engines. I really dont see a way to do it easier than that unless you''re looking for a complete hack that has nothing to do with physics. Maybe you could just flip velocity coords depending on the relative positions of the two spheres. This would be more like bouncing ABB''s off each other though and I imagine it would look pretty bad. Besides, I cant see basic momentum conservation giving you speed issues, its only a few calculations. All the conditional checks of a hack like I suggest above probably wouldn''t make it much faster than the physics route anyway.

##### Share on other sites
you are prolly right Motorherp. My issue is also that I have implemented my movement with a simple "non-physic" strategi.

I have a:

DOF (Vector)
Speed (konstant)
timeslice(small var)

and every timeslice I calc my movementvector (or velocity if you like)

velocity = dof *speed * timeslice

I have to use the velocity to detect intersection. Since I have to detect BEFORE I move.

This is my bouncing code (completely ripped off gamasutra.).

How would retrive the DOF from the velocity. Could it be as simple as normalising the newly calculated Velocity vectors?.

DebugSphere circle1 = A.get_boundingSphere();		DebugSphere circle2 = B.get_boundingSphere();		// First, find the normalized vector n from the center of	    // circle1 to the center of circle2	    Vector3 n = Vector3.subtract(circle1.get_center(),circle2.get_center(),null); 	    n.normalize();	    // Find the length of the component of each of the movement	    // vectors along n.	    // a1 = v1 . n	    // a2 = v2 . n	    float a1 = Vector3.dot(A.get_movementVector(),n);	    float a2 = Vector3.dot(B.get_movementVector(),n);	    // Using the optimized version,	    // optimizedP =  2(a1 - a2)	    //              -----------	    //                m1 + m2	    float optimizedP = (float)(2.0 * (a1 - a2)) / (circle1.get_mass()+ circle2.get_mass());	    // Calculate v1'', the new movement vector of circle1	    // v1'' = v1 - optimizedP * m2 * n	    Vector3 temp = Vector3.multiply(circle2.get_mass()*optimizedP,n);	    Vector3 v11 = Vector3.subtract(A.get_movementVector(),temp,null) ;	    // Calculate v1'', the new movement vector of circle1	    // v2'' = v2 + optimizedP * m1 * n	    Vector3 v22 = Vector3.subtract(B.get_movementVector(),Vector3.multiply(circle1.get_mass()*optimizedP,n),null) ;	    //v11.normalize();

// v22.normalize();

thanks

##### Share on other sites
I take it DOF is a direction vector. In that case yes, taking a normalised velocity vector will give you the direction vector. However Im a bit confused why you would do it this way. Why not simply keep track of the velocity vector and ditch the direction vector since every update you are converting between the two. This way the speed needn''t be kept as a seperate variable either since this is simply the length of the velocity vector. And if you ever need a unit direction vector anywhere else simply take the normal of the velocity. In fact if the length doesn''t effect any calculations you need the direction vector for and then you can simply use the velocity vector straight off.

##### Share on other sites
Again you are completely correct.

Only reason I needed the DOF is due to object transformation, Where I use a matrix.(you need and up,side and forward vector + position)

So nomatter what. I would need todo the transformation from velocity to DOF (or visa versa).

BUT it simplifies things using the velocity only