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 perpendiculardandymcgee wrote: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. 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.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?
OpenGL Rotation
Moderator: Coders of Rage
Re: OpenGL Rotation
- Falco Girgis
- Elysian Shadows Team
- Posts: 10294
- Joined: Thu May 20, 2004 2:04 pm
- Current Project: Elysian Shadows
- Favorite Gaming Platforms: Dreamcast, SNES, NES
- Programming Language of Choice: C/++
- Location: Studio Vorbis, AL
- Contact:
Re: OpenGL Rotation
THANK YOU.dandymcgee wrote: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. 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.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?
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.
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).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
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.
Re: OpenGL Rotation
I sense frustrationGyroVorbis wrote:THANK YOU.dandymcgee wrote: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. 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.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?
Brain feel little less like jello.....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.
Calm down, I've only just got past the trauma of trig.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.
Tis a bitch isn't it?GyroVorbis wrote: Welcome to the wonderful world of vectors and matrices, young'n.
Oh my bad..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).
Yes it was easy on paper, very different story in code
I think this is one of the most confusing parts.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 did see this as the y component just being dropped at first glance but I see what you mean know.
Most of that went through one ear and out the other....But I'll get through it step by stepGyroVorbis 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!
TO MARS!GyroVorbis wrote: BACK TO WORK!
- GroundUpEngine
- Chaos Rift Devotee
- Posts: 835
- Joined: Sun Nov 08, 2009 2:01 pm
- Current Project: mixture
- Favorite Gaming Platforms: PC
- Programming Language of Choice: C++
- Location: UK
Re: OpenGL Rotation
I feel your pain broN64vSNES wrote:Tis a bitch isn't it?GyroVorbis wrote: Welcome to the wonderful world of vectors and matrices, young'n.
- Falco Girgis
- Elysian Shadows Team
- Posts: 10294
- Joined: Thu May 20, 2004 2:04 pm
- Current Project: Elysian Shadows
- Favorite Gaming Platforms: Dreamcast, SNES, NES
- Programming Language of Choice: C/++
- Location: Studio Vorbis, AL
- Contact:
Re: OpenGL Rotation
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.N64vSNES wrote:Most of that went through one ear and out the other....But I'll get through it step by step
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.
Re: OpenGL Rotation
Motivating..GyroVorbis wrote: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.N64vSNES wrote:Most of that went through one ear and out the other....But I'll get through it step by step
You do seem determined I appreciate thatGyroVorbis 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.
I think I got most of 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
Yes lord Vader.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.
I think I'm getting close to something so I'll post again later
Re: OpenGL Rotation
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:
Now everything seems fine. But it's never detecting a collision, I guess I've missed something obvious?
Anyone?
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;
}
Anyone?