Jump to content

  • Log In with Google      Sign In   
  • Create Account


Really weird problem with rigid body simulator


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
9 replies to this topic

#1 D.V.D   Members   -  Reputation: 406

Like
0Likes
Like

Posted 15 January 2013 - 06:34 PM

EDIT 2: Hey guys I made a rigid body dynamics system but it suffers from major issues when theres more than 2 bodies colliding at once. The way it works is that it finds which objects are colliding with eachother and puts them into pairs. Each pair being 2 objects colliding with eachother but this doesn't seem to always work. When the three objects collide, they pass through eachother and the program starts to lag intensively because of calculations it does when objects are moving inside of eachother. I was wondering, since all my objects are boxes with a fixed radius, do I need to push the objects back a bit so that they aren't overlapping, and then do the momentum calculations? Whats the way of solving such a problem?

 

TestStack is a list of all the objects in my engine. TEST_COUNT is the number of objects in my engine. Ispointinbox is the function used to calculate if a point is in a box, I tested it around and it works since no rotation transformations are put on the box. If source code for this function is needed, Ill provide it.

struct colstack {

	int current;
	
	object pair1 [MAX_OBJ_COUNT*MAX_OBJ_COUNT];
	object pair2 [MAX_OBJ_COUNT*MAX_OBJ_COUNT];

	colstack () {
		current = 0;
	}

	void add (object _o1, object _o2) {
		pair1[current] = _o1;
		pair2[current] = _o2;
		current++;
	}

	void clear () {
		current = 0;
	}

};

colstack CollisionStack;

void PhysicsPipeline::update () {
	for ( int i=0; i < TEST_COUNT; i++ ) {
		// Update position of boxes
		//cout << "UPDATE" << endl;
		TestStack[i].updatepos();
	}
	// For every object object in test count
	for ( int i=0; i < TEST_COUNT; i++ ) {
		// Check collision with every other object in collision
		for ( int j=0; j < TEST_COUNT; j++ ) {
			// If objects being checked aren't the same object
			if ( j != i ) {
				// Add to pair of collisions
				CollisionStack.add(TestStack[i], TestStack[j]);
			}
		}
	}
	for ( int i=0; i < CollisionStack.current-1; i++ ) {
		// Check for Collision of every vertice of the coliding boxe
		bool hascollided = false;
		if ( CollisionStack.pair1[i].BoundingBox.ispointinbox(CollisionStack.pair2[i].BoundingBox.NW) == true ) {
			collide(0,1);
			hascollided = true;
		}
		if ( CollisionStack.pair1[i].BoundingBox.ispointinbox(CollisionStack.pair2[i].BoundingBox.NE) == true && hascollided == false ) {
			collide(0,1);
			hascollided = true;
		}
		if ( CollisionStack.pair1[i].BoundingBox.ispointinbox(CollisionStack.pair2[i].BoundingBox.SW) == true && hascollided == false ) {
			collide(0,1);
			hascollided = true;
		}
		if ( CollisionStack.pair1[i].BoundingBox.ispointinbox(CollisionStack.pair2[i].BoundingBox.SE) == true && hascollided == false ) {
			collide(0,1);
			hascollided = true;
		}
	}
	CollisionStack.clear();
}

 

This is the collision function. It works by saying that the object with the most momentum in a collision will lose momentum while the object with the least momentum gains momentum. This is described with the proportion variables. The debug function simply prints a variable.

 

inline void collide (int i, int j) {
	//FIX LATER!!
	//if ( deb == true ) {
	Vector2f m1 = Vector2f(TestStack[i].mass * TestStack[i].vel.x, TestStack[i].mass * TestStack[i].vel.y);
	Vector2f m2 = Vector2f(TestStack[j].mass * TestStack[j].vel.x, TestStack[j].mass * TestStack[j].vel.y);
	
	cout << "m1: " << m1.x << ", " << m1.y << endl;
	cout << "m2: " << m2.x << ", " << m2.y << endl;

	double mag1 = sqrt( (m1.x*m1.x) + (m1.y*m1.y) );
	double mag2 = sqrt( (m2.x*m2.x) + (m2.y*m2.y) );

	debug("mag1",mag1);
	debug("mag2",mag2);
	
	double angle1 = atan(degreetorad(m1.y/m1.x));
	double angle2 = atan(degreetorad(m2.y/m2.x));
	if ( m1.x < 0 ) {
		angle1 -= 180.0f;
	}
	if ( m2.x < 0 ) {
		angle2 -= 180.0f;
	}

	debug("angle1",angle1);
	debug("angle2",angle2);
	
	double proportion1, proportion2;
	
	if ( mag1 > mag2 ) {
		proportion1 = mag2/mag1;
		proportion2 = 1.0f - proportion2;
	}
	if ( mag1 < mag2 ) {
		proportion2 = mag1/mag2;
		proportion1 = 1.0f - proportion2;
	}
	if ( mag1 == mag2 ) {
		proportion1 = 0.50f;
		proportion2 = 0.50f;
	}

	debug("proportion1",proportion1);
	debug("proportion2",proportion2);
	
	double mag1t = mag1*proportion1;
	double mag2t = mag2*proportion2;

	debug("mag1t",mag1t);
	debug("mag2t",mag2t);
	
	mag1 -= mag1t;
	mag2 -= mag2t;
	mag1 += mag2t;
	mag2 += mag1t;
	
	debug("mag1",mag1);
	debug("mag2",mag2);

	debug("a1",degreetorad(angle1));
	debug("a2",degreetorad(angle2));

	debug("Angle1C",cos(degreetorad(angle1)));
	debug("Angle1S",sin(degreetorad(angle1)));
	debug("Angle2C",cos(degreetorad(angle2)));
	debug("Angle2S",sin(degreetorad(angle2)));

	TestStack[i].vel.x = mag1 * cos(degreetorad(angle1)) * -1.0f / TestStack[i].mass;
	TestStack[i].vel.y = mag1 * sin(degreetorad(angle1)) * -1.0f / TestStack[i].mass;
	TestStack[j].vel.x = mag2 * cos(degreetorad(angle2)) * -1.0f / TestStack[j].mass;
	TestStack[j].vel.y = mag2 * sin(degreetorad(angle2)) * -1.0f / TestStack[j].mass;

	cout << "Ivel: " << TestStack[i].vel.x << ", " << TestStack[i].vel.y << endl;
	cout << "Jvel: " << TestStack[j].vel.x << ", " << TestStack[j].vel.y << endl;
	deb = false;
	//}
}

Edited by D.V.D, 15 January 2013 - 06:48 PM.


Sponsor:

#2 EWClay   Members   -  Reputation: 655

Like
0Likes
Like

Posted 16 January 2013 - 08:50 AM

I can't really answer the question without addressing some other problems with the code.

1. You create a list containing every possible pair of objects. This seems pointless, without at least some pruning at this stage. In fact, it contains every pair twice.

2. You miss the last pair due to the -1 in the for loop.

3. A bounding box overlap test should just be comparing min and max on each axis. Checking the corners is not correct in all cases, as well as taking longer.

4. You seem to call collide() with the same parameters every time.

5. The momentum calculations don't look right. You should be applying equal and opposite impulses along the collision normal.

#3 DT....   Members   -  Reputation: 487

Like
0Likes
Like

Posted 16 January 2013 - 04:56 PM

I was wondering, since all my objects are boxes with a fixed radius, do I need to push the objects back a bit so that they aren't overlapping, and then do the momentum calculations? Whats the way of solving such a problem?

 

There's several competing strategies:

 

 

http://www.gamedev.net/topic/475753-list-of-physics-engines-and-reference-material-updated-7-march-2011/

 

(After fixing the problems noted in the previous post, you may want to take a look at "Position-Based Dynamics."  Does Eq. 10 & 11 look familiar?)



#4 D.V.D   Members   -  Reputation: 406

Like
0Likes
Like

Posted 17 January 2013 - 05:29 PM

Hmm, looking over the code, i just realized how extremely unoptimized it is :P

 

For point 1, I realized that this was happening but I changed it and will remove it for now since I only ever have 2 objects on the screen at once due to limitations of momentum calculations that only involve 2 bodies. Once you get 3 or 4, treating them as seperate 2 body collisions doesn't really work too well.

 

Point 2, fixed it.

 

Point 3, Im not sure I udnerstand this correctly. You mean to find the boxes max x, min x, max y and min y and see if the other min/maxes of the other box fall in between?

 

Point 4, thats just cause I need to pass the position in my TestStack of both objects colliding. Im not sure, is there a easier way of doing this?

 

Point 5, I ended up changing them. It works properly now.

 

What are these competing strategies btw? The link is just a list of all the libraries that do physics.



#5 EWClay   Members   -  Reputation: 655

Like
0Likes
Like

Posted 18 January 2013 - 03:42 AM

3. Yes, you should test the min and max on each axis for overlap. No overlap on any axis = no collision. (This is the Separating Axis Theorem, which you might want to look up.) As a bonus, the smallest overlap identifies the most useful axis to take for the collision normal.

4. Yes, but you might want to call it with the indices of the colliding pair, not always 0 and 1.

The only strategy I would recommend at this point would be iterative impulses. You need a list of colliding pairs, which you have, but it would be good to do the overlap test before adding them.

The problem generally is that solving a collision for one pair will affect the solution for another pair. So you have to revisit the collisions multiple times and repeat the calculations until every pair is heading apart.

Get it working perfectly for two bodies, then try for more. Good luck, this stuff isn't easy.

#6 D.V.D   Members   -  Reputation: 406

Like
0Likes
Like

Posted 19 January 2013 - 10:40 PM

Hmm okay, and I know this may seem like a begginer question, but what exactly is the collision normal? From my understanding its the centre of one object to the centre of another when they are colliding. Would that be correct?

 

Yeah I just realized I only had those two. That was cause I saw that 3+ body collisions didn't work well so I simply stuck with making the collision physics work properly for two objects. I was thinking of doing spatial hashing but like you said, first get the physics working for two objects :P



#7 EWClay   Members   -  Reputation: 655

Like
0Likes
Like

Posted 20 January 2013 - 08:29 AM

The vector between the object centres is only the direction of the collision normal if the objects are circles. From the code above it appears that you are using rectangles.

Think of it as the direction you need to move intersecting objects so that they can be separated with the minimum movement. For non-rotating rectangles this is either the x or y axis. Getting the normal correct is important for collisions looking right.

#8 D.V.D   Members   -  Reputation: 406

Like
0Likes
Like

Posted 22 January 2013 - 10:45 AM

So if I get this correctly, the normals angle is the angle between the two objects but its length is the distance between the two objects when they don't overlap? When I read up a tutorial, they simply said its the distance between the two objects centre's during collision, but I don't recall ever hearing that the objects can't overlap.



#9 EWClay   Members   -  Reputation: 655

Like
0Likes
Like

Posted 22 January 2013 - 12:48 PM

Normals always have length 1.

 

For circles, the direction of the normal is along the line between the centres.

 

For axis-aligned rectangles, the normal is the axis with the minimum overlap or separation distance.

 

Whether objects ever overlap depends on how you simulate them. It's hard to avoid completely but you should try to minimise it.



#10 D.V.D   Members   -  Reputation: 406

Like
0Likes
Like

Posted 26 January 2013 - 12:00 AM

Oh I see, I think I understand it now. Thanks for the help everyone!!






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS