Elysian Shadows

Posted: **Fri Apr 01, 2011 6:58 am**

dandymcgee wrote:
N64vSNES wrote: I have no idea how I should calculate that axis (blue line) and when projecting the polygons I'm confused to why that line makes a difference?
The blue line is correct, but the green ones are not. You're not projecting along the y-axis, you're projecting onto the blue line.
obb.png
This would be the projection on one of the axes. There are four axis total you need to project them onto. As Falco already pointed out, you don't understand what a projection onto an axis is. Go check out the resources he gave you.

When you say the blue line is incorrect, is it because I drew another blue line to the polygons face? Because I just did that so you knew which face I was thinking was perpendicular

Posted: **Fri Apr 01, 2011 9:30 am**

dandymcgee wrote:
N64vSNES wrote: I have no idea how I should calculate that axis (blue line) and when projecting the polygons I'm confused to why that line makes a difference?
The blue line is correct, but the green ones are not. You're not projecting along the y-axis, you're projecting onto the blue line.
obb.png
This would be the projection on one of the axes. There are four axis total you need to project them onto. As Falco already pointed out, you don't understand what a projection onto an axis is. Go check out the resources he gave you.

THANK YOU.

I told you, dude. You don't just take one component of a vector and call that shit a projection. Imagine that the lines forming the edges of your polygon continue or "project" (loll0rskates!) onto the axis. That's what a projection is.

What's that, you say? The projection isn't aligned with the X or Y axis, so you don't know the value of the projection? No shit! The polygon isn't axis-aligned! As I said before, you are trying to approach this without linear algebra. Shit isn't going to work. Welcome to the wonderful world of vectors and matrices, young'n.

N64vSNES wrote:When you say the blue line is incorrect, is it because I drew another blue line to the polygons face? Because I just did that so you knew which face I was thinking was perpendicular

He said your blue one WAS correct. You found an axis properly (on paper). I doubt you did it correctly on code, since your projections are still incorrect (and that would require you to have utilized that linear algebra knowledge).

Your green lines are wrong as fuck, because as we said, those are PROJECTIONS, not just you dropping the y component of your vectors.

Think about it. Look back at your picture. The blue face of the polygon that you used to create that axis is parallel to the axis, correct? Now a "separating axis" is PERPENDICULAR to that axis. Find me a perpendicular line to that axis in your picture that does not intersect your green projections. You can't, because your projections are incorrect. That would be a false collision.

Here's what you do:

1) Find two axes for each polygon by subtracting the two vertices (in WORLD COORDINATES) that create each edge to create the vector between them. The algorithm (and projections) require each axis to be NORMALIZED, so find the magnitude of the axes (distance formula, pythagorean theorem, whatever you want to call it), and divide each of their components by this magnitude. Bam! You have normalized vectors. Winning!

2) Now the easy part. The "vector projections" of your vertices onto these axes are simple dot products between each vertex and your axis (this is because your axes are already normalized). NOW KEEP IN MIND: You need to project a total of 6 vertices onto each axis for two oriented bounding boxes. Since one of your OBBs was used to create an axis in the first place, it has two edges that are perpendicular to its own axes. The vector projections of the vertices forming the edge perpendicular to your axis of projection are going to be equal, so you only need to project two vertices (like the box on the right of dandymcgee's drawing).

The box on the left actually needs to have FOUR projections (not the two in the drawing), because none of its edges are aligned with the axis you're projecting onto (meaning each vertex will have a unique projection value).

SO BIG PICTURE:
PROJECT 6 WORLD-SPACE VERTICES ONTO 4 NORMALIZED AXES.

Now, the next step: For each axis, you will be given 6 "one-dimensional scalars" by performing these projections. If there is any overlap between polygon A's scalars and polygon B's scalars, there cannot possibly be an axis perpendicular to the axis of projection that separates the two. You have a collision whose depth is the difference between the two minimally overlapping scalars and whose direction is in the direction of the axis. Don't bother testing on any other axes!

So multiply that scalar overlap by your normalized axis, and tada! You now have a vector that will separate the two polygons: the collision normal. Use this collision normal to bang 7g rocks like a super fricken rockstar from Mars!

BACK TO WORK.

Posted: **Fri Apr 01, 2011 10:43 am**

GyroVorbis wrote:
dandymcgee wrote:
N64vSNES wrote: I have no idea how I should calculate that axis (blue line) and when projecting the polygons I'm confused to why that line makes a difference?
The blue line is correct, but the green ones are not. You're not projecting along the y-axis, you're projecting onto the blue line.
obb.png
This would be the projection on one of the axes. There are four axis total you need to project them onto. As Falco already pointed out, you don't understand what a projection onto an axis is. Go check out the resources he gave you.
THANK YOU.

I sense frustration

GyroVorbis wrote: I told you, dude. You don't just take one component of a vector and call that shit a projection. Imagine that the lines forming the edges of your polygon continue or "project" (loll0rskates!) onto the axis. That's what a projection is.

Brain feel little less like jello.....

GyroVorbis wrote: What's that, you say? The projection isn't aligned with the X or Y axis, so you don't know the value of the projection? No shit! The polygon isn't axis-aligned! As I said before, you are trying to approach this without linear algebra. Shit isn't going to work.

Calm down, I've only just got past the trauma of trig.

GyroVorbis wrote: Welcome to the wonderful world of vectors and matrices, young'n.

Tis a bitch isn't it?

GyroVorbis wrote: He said your blue one WAS correct. You found an axis properly (on paper). I doubt you did it correctly on code, since your projections are still incorrect (and that would require you to have utilized that linear algebra knowledge).

Oh my bad..
Yes it was easy on paper, very different story in code

GyroVorbis wrote: Your green lines are wrong as fuck, because as we said, those are PROJECTIONS, not just you dropping the y component of your vectors.

I think this is one of the most confusing parts.

I did see this as the y component just being dropped at first glance but I see what you mean know.

GyroVorbis wrote: Here's what you do:

1) Find two axes for each polygon by subtracting the two vertices (in WORLD COORDINATES) that create each edge to create the vector between them. The algorithm (and projections) require each axis to be NORMALIZED, so find the magnitude of the axes (distance formula, pythagorean theorem, whatever you want to call it), and divide each of their components by this magnitude. Bam! You have normalized vectors. Winning!

2) Now the easy part. The "vector projections" of your vertices onto these axes are simple dot products between each vertex and your axis (this is because your axes are already normalized). NOW KEEP IN MIND: You need to project a total of 6 vertices onto each axis for two oriented bounding boxes. Since one of your OBBs was used to create an axis in the first place, it has two edges that are perpendicular to its own axes. The vector projections of the vertices forming the edge perpendicular to your axis of projection are going to be equal, so you only need to project two vertices (like the box on the right of dandymcgee's drawing).

The box on the left actually needs to have FOUR projections (not the two in the drawing), because none of its edges are aligned with the axis you're projecting onto (meaning each vertex will have a unique projection value).

SO BIG PICTURE:
PROJECT 6 WORLD-SPACE VERTICES ONTO 4 NORMALIZED AXES.

Now, the next step: For each axis, you will be given 6 "one-dimensional scalars" by performing these projections. If there is any overlap between polygon A's scalars and polygon B's scalars, there cannot possibly be an axis perpendicular to the axis of projection that separates the two. You have a collision whose depth is the difference between the two minimally overlapping scalars and whose direction is in the direction of the axis. Don't bother testing on any other axes!

So multiply that scalar overlap by your normalized axis, and tada! You now have a vector that will separate the two polygons: the collision normal. Use this collision normal to bang 7g rocks like a super fricken rockstar from Mars!

Most of that went through one ear and out the other....But I'll get through it step by step

GyroVorbis wrote: BACK TO WORK!

TO MARS!

Posted: **Fri Apr 01, 2011 10:51 am**

N64vSNES wrote:
GyroVorbis wrote: Welcome to the wonderful world of vectors and matrices, young'n.
Tis a bitch isn't it?

I feel your pain bro

Posted: **Fri Apr 01, 2011 11:30 am**

welcome to the matrix neo

Posted: **Fri Apr 01, 2011 1:32 pm**

N64vSNES wrote:Most of that went through one ear and out the other....But I'll get through it step by step

The truth is that despite how mathematically invalid your first approach was, you weren't too far off as far as the overall algorithm and geometric interpretations are concerned. Not bad.

That's why I'm staying on your ass. You made it that far, now it's just performing the math CORRECTLY and making a few slight alterations. You got the big picture to some extent. Now you just have to understand how to realize what you are trying to do with vectors.

What you did is absolutely correct with axis-aligned bounding boxes. And as I said before, the only reason that you were able to do that without using vectors or linear algebra all boiled down to the fact that dot producting any vector with a vector representing the X or Y axis in 2D results in a scalar value equal to that component of the vector. Your logic in the axis-aligned case performed this operation implicitly. You won't understand this for awhile, but one day you'll have an epiphany where you are forced to realize that all of the axis-aligned 2D mathematics that you have taken for granted your entire development career magically utilize these principles implicitly... delicately hidden behind the fact that your axes are all aligned either in parallel or perpendicularly... then you shall see the light and the true nature of the mathematical singularity that we call our universe, young warlock. Use your powers well.

Posted: **Fri Apr 01, 2011 2:00 pm**

GyroVorbis wrote:
N64vSNES wrote:Most of that went through one ear and out the other....But I'll get through it step by step
The truth is that despite how mathematically invalid your first approach was, you weren't too far off as far as the overall algorithm and geometric interpretations are concerned. Not bad.

Motivating..

GyroVorbis wrote: That's why I'm staying on your ass. You made it that far, now it's just performing the math CORRECTLY and making a few slight alterations. You got the big picture to some extent. Now you just have to understand how to realize what you are trying to do with vectors.

You do seem determined

I appreciate that

GyroVorbis wrote: What you did is absolutely correct with axis-aligned bounding boxes. And as I said before, the only reason that you were able to do that without using vectors or linear algebra all boiled down to the fact that dot producting any vector with a vector representing the X or Y axis in 2D results in a scalar value equal to that component of the vector. Your logic in the axis-aligned case performed this operation implicitly. You won't understand this for awhile, but one day you'll have an epiphany where you are forced to realize that all of the axis-aligned 2D mathematics that you have taken for granted your entire development career magically utilize these principles implicitly... delicately hidden behind the fact that your axes are all aligned either in parallel or perpendicularly

I think I got most of that...

GyroVorbis wrote: ... then you shall see the light and the true nature of the mathematical singularity that we call our universe, young warlock. Use your powers well.

Yes lord Vader.

I think I'm getting close to something so I'll post again later

Posted: **Sun Apr 03, 2011 5:46 pm**

Okay I've learned a lot on vectors and avansc's thread was very useful, although I've gotten a stuck again.

Here is the code:

Code: Select all

bool Eternal::IsCollision(BoundingBox *a, BoundingBox *b) {
	if ( a->r != 0 || b->r != 0 ) {
		return IsOrientedCollision(a,b);
	}
	if ( a->x + b->w > b->x
		&& a->x - b->w < b->x
		&& a->y + b->h > b->y
		&& a->y - b->h < b->y ) {
		return true;
	}
	return false;
}

bool Eternal::IsCollision(BoundingBox *a, BoundingBox *b, Vector2 &normal) {
         // Stuff for axis aligned collision
}

bool Eternal::IsOrientedCollision(BoundingBox *a, BoundingBox *b) {
   
	printf("Check\n");

   BoundingBox *list[3];
   list[0] = a; list[1] = b; list[2] = a;
   Vector2 *p;
   
   float t1 = 0, t2 = 0;
   float f_min = 0, f_max = 0;
   
   for(int i = 0;i < 2;i++)
   {
      for(int a = 0;a < 2;a++)
      {
         p = new Vector2(list[i]->GetVert(a+1).x - list[i]->GetVert(a).x, list[i]->GetVert(a+1).y - list[i]->GetVert(a).y);
         p->Normalize();
      
         t1 = list[i]->GetVert(a).Project(p).Magnitute();
		 t2 = list[i]->GetVert(a+1).Project(p).Magnitute();
		 f_min = min(t1, t2);
         f_max = max(t1, t2);
      
         float proj[4];
         for(int b = 0;b < 4;b++)
         {
            proj[b] = list[i+1]->GetVert(b).Project(p).Magnitute();
         }
      
        if(Umbre(f_min, f_max, proj) == false)
            return false;
      }
   }
	
   return false;
}

bool Eternal::Umbre(float min, float max, float proj[]) {
	printf("and\n");
	bool less = false, more = false;

	printf("%f\n%f\n",min,max);

	for(int i = 0;i < 4;i++) {

		if(proj[i] >= min && proj[i] <= max) {
			return true;
		}
		else if(proj[i] < min) {
			less = true;
		}
		else if(proj[i] > max) {
			more = true;
		}

	}

	if(less && more) {
		return true;
		printf("mate\n");
	}

	return false;
}

Now everything seems fine. But it's never detecting a collision, I guess I've missed something obvious?
Anyone?

Elysian Shadows

OpenGL Rotation

Re: OpenGL Rotation

Re: OpenGL Rotation

Re: OpenGL Rotation

Re: OpenGL Rotation

Re: OpenGL Rotation

Re: OpenGL Rotation

Re: OpenGL Rotation

Re: OpenGL Rotation