Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Virex]

I'm pretty sure he means "Maths is to programmers as masturbation is to physicists." It's something you're not proud of, but what other option do you have?

[Valid_Dark]

I'm pretty sure he means "Maths is to programmers as masturbation is to physicists." It's something you're not proud of, but what other option do you have?

^^^ this,

-I wrote a bunch of other stuff here, but then decided not to share it with you xD-

[Gatleos]

Hello Gatleos, I was meaning to answer your question much earlier as I kinda said would be posting some different intersection code snippets, but I sadly had a case of a female friend demanding my attention for the night.

Anyway. I finally think I understand what you are trying to do:
You are trying to, move the box towards the slope, and it should "slide" up the slope based on projecting the vector upon the "slope vector"?
If I understood correctly then you are going about collision response a bit wrong, especially with what you want to do.


Anyway, I will write in c++ psuedo code what you should probably do to resolve the collision. Please note, I am assuming that the vector * vector type translates to dot product.

Code: [Select]

//The will calculate a movement vector based on if it collides with a slope.
vect MoveResolveAABBSlopeSolveCollision(rect & A, rect & tri, vect & move){
      if(move.x == 0) return move;
      //Returns intersection point between the AABB A and slope tri, based on vector move.

      //Here we are essentially just setting up some variables, if you wan't to know what is going on I could explain, but it's a lengthily explanation so I think I'll just skip it for now.
      vect h_inverted(- tri.h, tri.w);
     
      float hm  = 1 / (h_inverted * move);
      float hp = h_inverted * tri.point;
      float t; //Here we are going to store the factor the movement vector needs to be to intersect.

     

      //Calculate intesection distance between the movement and slope.
      if(dir.x < 0){ //We come from right
            t = (hp - (A.p) * h_inverted) * hm;
      }
      if(dir.x > 0){ //We come form left
            t = (hp - (A.p + vect(A.w, 0)) * h_inverted) * hm;
      }
     
      if(t >= 1 && t < 0){ //The movement vector and slope do not intersect
           return move;
      }

      //Alright, now that we know they intersect. Let's project the movement vector onto the slope.
      vect h(tri.w, tri.h);
     
      vect intersection_p = ((h * move) / (h*h)) * h + tri.p;

      //We return a new movement vector projected onto the slope for a "sliding" effect.
      return intersection_p;
}

//How to use the code.
//This is basic physics, movement should be calculated after all forces have been summed. This means force should be reset before each update!
player.movementVector = vect(0,0);

//....//

//Handle input!
if(keydown(left))
    player.movementVector += vect( player.speed, 0);

if(keydown(right))
    player.movementVector += vect(- player.speed, 0);
//....//

tile & tile_we_moved_to = FindTileOnGrid(player.position + player.speed);


//....//

//I assume this is the collision resolving code
if(tile_we_moved_to == slope){
     //Alright, we collided with a slope. Let's move our object towards the slope:
     player.position += MoveResolveAABBSlopeSolveCollision(player.boundingbox, tile_we_moved_to.boundingbox, player.movementVector);
}
Please note, the code is not really "checked" as such, but rather I wrote the code from thinking about the problem and solving it. It should work as I've done something similar in the past. Also, this can be done much more effectively, but it's simplified so it's easier to follow.

If you can't get it to work, you are free to ask if you have any questions.

My understanding:

First, you get the inverse slope of the hypotenuse (h_inverted). Then you project that vector onto the movement vector (is it supposed to be the other way around?) and grab the inverse of that. Then you project a point (I assume it's the triangle rect's upper left bound?) onto the axis.

You now have the projection of the hypotenuse onto the axis. You subtract the projection of the AABB's lower right corner onto the axis (is that what A.p is?) from it and multiply that by hm for reasons I can't fathom. The result is the distance of the intersection along the hypotenuse axis. After that you project the AABB's movement vector onto the hypotenuse's slope, do... something (you're going to have to explain that line where you define intersection_p) and the result is a new vector that skirts the edge of the hypotenuse and gets a sliding effect.

So the basic idea is that the collision is detected before the AABB intersects the triangle, and the movement vector is redirected to prevent the collision? If so, then...

Wouldn't the green AABB with the red line as a movement vector be detected as a collision? And wouldn't that function project the red vector onto the hypotenuse, resulting in the blue vector? And wouldn't that cause the AABB to mysteriously change directions in midair when it wasn't even close to the triangle? I have a feeling I don't understand what you're trying to do.

[malloc]

Actually it's much much simpler than that.

The I first calculate whether or not the movement vector intersects with the hypotenuse.

This is done by using the relation that, if two vectors A*B = 0, then the angle between them is 90. For this to work, I need a vector orthogonal to the hypotenuse. I call it h_inverted.

For any two points on the hypotenuse, h_inverted(P1 - p0) = 0
Then I use the parametric form of a line for the movement vector, position1 + move*t, and insert into P1. Then I simply solve for t, and get a value that says how much I need to multiply the movement vector by to intersect the hypotenuse.
If this value is between 0 and 1, then a intersection between the hypotenuse and the movement vector has occurred.

If a intersection has occurred, I simply project the movement vector onto the hypotenuse. The resulting "movement" vector will be the vector which I will use to move the AABB.

Edit:
You seem to be misunderstanding what dot products are, they are not equal to the projected vector. Rather, they give you a spatial relation between the two vectors.

Vector dot products are basically defined like this:
A * B = |A| * |B| * cos(u) Where |A| is the lenght of A and u is the angle between the vectors.

If the angle is 90 degree, cos(90) = 0. So the dot product between two orthogonal vectors is 0.

Vector projection looks like this:
A projected onto B
((A * B)/(B*B)) * B
B projected onto A
((B * A)/(A*A)) * A

For unit vectors this can be reduced to:
B projected onto A
B * A * A

A projected onto B
B * A * B

Last edit:
I actually tested out the codesnippet i posted. The code does in fact work just fine. However, this does not really handle collision detection as such, but rather a collision response. The line hypotenuse intersection test is simply if you want different kinds of slopes. I dunno why I thought this was a good idea, but well.. it's in there.

[Gatleos]

Okay, I think I understand what you're doing. The parametric stuff near the top (I didn't recognize before that that's what it was) is just a fast way to determine collision. The part after collision is assured just "corrects" the movement vector so that it still moves the same distance horizontally, but stops at the edge of the hypotenuse.

I implemented the function, and there's still one part that I don't get. Keep in mind that I'm using a coordinate system where the origin is the top left of the window, so the y component of the slope of the upper-left facing triangle is negative its height.

Code: [Select]

void colltlm(SDL_Rect &d,SDL_Rect &s,vect &move)
{
if(!move.x)return;//If object is not moving horizontally, no movement on slope necessary
vect dpos(d.x,d.y);
//
vect h_inverted(s.h,s.w);//Inverse of triangle hypotenuse
float hm = 1/(h_inverted*move);
float hp = h_inverted*vect(s.x+s.w,s.y);
float t;
//
t = (hp-(dpos+vect(d.w,d.h))*h_inverted)*hm;
if(t >= 1 && t < 0)//The movement vector and slope do not intersect
return;
//
vect h(s.w,-s.h);//Hypotenuse vector
move = ((move*h)/(h*h))*h + vect(s.x+s.w,s.y);
}It all works, up until the last line. You said that you're assuming the * operator means a dot product between a vector and a point, right? Well, that last h which is multiplied by ((move*h)/(h*h)) produces an error, because that expression produces a float value. And it can't multiply the h vector by a float.

I removed the last two lines that project the vector, and it appears to work fine up until that point. But the expression on that last line just looks a little weird to both me and my compiler.

[malloc]

Yeah, you pretty much got it right!

You should be able to multiply a vector by a value, it's valid mathematically (It's also known as scaling the vector, what you are technically doing is multiplying it's length by a value.). You will probably have to overload the vector class multiply operator to make it work.

Code: [Select]

struct vect{
     vect & operator * ( float & c){
           return(vect(x * c, y * c));
     }
};

//Edit: so it works both vector * float and float * vector
vect & operator * ( float & c, vect & v){
       return(vect(v.x * c, v.y * c));
}


[Gatleos]

Oh, I just assumed it was more complicated than just scaling the vector. Well, I added a float multiplication operator to the vect class, and it works! Moving right along the slope pushes the bounding box along the hypotenuse. Thanks for all the help!

I have to ask about this, though:

Code: [Select]

if(!move.x)return;If I have a gravity vector constantly pulling downward on all dynamic objects, this line would make an object fall down through the slope if it stops moving horizontally. But without it, a downward force causes the object to move down along the slope, regardless of the steepness.

This system also doesn't account for collision from the other two sides of the triangle, but I suppose I can get around that by always placing a square tile adjacent to those sides.

[malloc]

I am very glad you got it to work!

You could solve your gravity problem by only pulling down on objects that do not have ground under them. A more complicated way of doing it could be to add friction, but then are are actually moving into a more general physics system solver of sorts. You will probably have to make some changes to the slope sliding solver too, if you want to make if of it.

Essentially you need to account for all forces at the same time, when gravity is pulling down a object, a equally, strong force is reflected back.
When on a slope, gravity would naturally pull the object down the slope. But the ground friction, and the ground normal "opposite" force, should cancel out the gravity. I am could go on, anyway, it's already getting to complicated, and I think I am getting to tired to actually think straight.

I recommend to just stick to something simple, only add gravity force to objects with no ground under their feet.

[Seriyu]

I'm actually just recently getting into C++ with help of a friend of mine (still working on pointers), and I have to say some of this stuff scares me terribly, because I have a hard time with pretty much anything worse then division, and math in general just doesn't mesh with my brain.

[Levi]

I'm actually just recently getting into C++ with help of a friend of mine (still working on pointers), and I have to say some of this stuff scares me terribly, because I have a hard time with pretty much anything worse then division, and math in general just doesn't mesh with my brain.

Don't sweat it to much.  General programming requires surprisingly little math.

[MaximumZero]

I used this phrase in my midterm:

Code: [Select]

//I'm seriously considering sacrificing a goat or something to get this part to work.

[Mego]

I used this phrase in my midterm:

Code: [Select]

//I'm seriously considering sacrificing a goat or something to get this part to work.

Good man. cookies++;

I'm using C++ and the Windows XInput API to make a program that will hack together support in Unreal Tournament ('99) for Xbox 360 controller input. Stroustrup rest my soul.

[Levi]

I made myself a stock tracker for my stocks.

Its not finished yet, but it does update itself and display the correct data(although only at 10min intervals to keep me from spamming finance.yahoo.com).  Its using the python Django web app framework thingy, which so far has been a pain in the arse.

My stocks.

Also WHY WON'T MY STOCKS GO UP!   

 

[Valid_Dark]

Those numbers don't look right?
I investigated the RPG stock, because I based on your numbers I maybe had an interest in buying some, mainly because It's called RPG, and because it's cheap.
but when I did some search into it, it didn't show the same values as your stock tracker.

http://www.google.com/finance?q=NYSEARCA:RPG

explain?

[Levi]

Those numbers don't look right?
I investigated the RPG stock, because I based on your numbers I maybe had an interest in buying some, mainly because It's called RPG, and because it's cheap.
but when I did some search into it, it didn't show the same values as your stock tracker.

http://www.google.com/finance?q=NYSEARCA:RPG

explain?

Sorry, that is RPG on the Canadian stock market.   I should probably list the exchange, but they are all Canadian stocks. 

http://www.google.ca/finance?q=TSE:RPG

Edit:  Now it has links.