Sign in to follow this  
mindrot

no doubt this collision detection issue has been asked before but...

Recommended Posts

dont flame plz, i browsed the last 100 threads and only found issues insanely more complicated than mine...i just need some simple advice. all i do is draw a rectangle then try to detect if my current location (xPos,yPos,zPos) is within that rectangle here is the pseudo set current position to temp x,y,z variables recalculate x,y,z position detect if new x,y,z is within rectangle if so, set x,y,z to temp variables its primitive but.....so is my program the rectClass consists of 6 floats x,y,z to act as an origin then l,w,h to create the rectangle so the first corner is coordinate (x,y,z) and the far opposite corner is (x+l,y+w,z+h) the other points can be calculated as combinations of these two sets anywhoo here is the function of the rectWall class
    bool withinMe(float xVal, float yVal, float zVal)
    {
        if(((xPos >= x)&&(xPos<=x+l)) || ((xPos <= x)&&(xPos >=x+l)))
            if(((yPos >= y)&&(yPos<=y+w)) || ((yPos <= y)&&(yPos >=y+w)))
                if(((zPos >= z)&&(zPos<=z+h)) || ((zPos <= z)&&(zPos >=z+h)))
                    return true;
        return false;
    }



here is how i call the function
    if(keyW)
    {
        int x = 0;
        float tempX = xPos;
        float tempY = yPos;
        float tempZ = zPos;
        vertRotRad = (vertRot / 180 * 3.141592654f);
        horiRotRad = (horiRot / 180 * 3.141592654f); 
        xPos -= float(sin(horiRotRad));
        zPos += float(cos(horiRotRad));
        yPos += float(sin(vertRotRad));
        for(x;x<walls.size();x++)
        {
            if(walls[x]->withinMe(xPos, yPos, zPos))
            {
                xPos = tempX;
                yPos = tempY;
                zPos = tempZ;
                break;
            }
        }
    }



my issue is that it withinMe doesnt return true...ever! lol! so if anyone could shoot me some advice i'd be thankful. ps- oh yeah i forgot walls[x] etc etc walls is a vector of rectWall*

Share this post


Link to post
Share on other sites
Couple of questions:

1. Are l, w, and h signed values, or can they only be non-negative?

2. You're using the term 'rectangle', but it's really a box, yes?

3. In your containment function, are the *Pos variables actually supposed to be the *Val arguments?

4. Are you sure that the l, w, and h for your boxes are valid and/or non-zero?

Share this post


Link to post
Share on other sites
thanks for the reply

1. Are l, w, and h signed values, or can they only be non-negative?
they are just floats and thus can be negative...*tests* yeah they can be negative

2. You're using the term 'rectangle', but it's really a box, yes?
yeah sorry its late>_< box is correct 3D is good!

3. In your containment function, are the *Pos variables actually supposed to be the *Val arguments?
yes...*runs away* didnt make a difference since the *pos variables are global and are the same as teh values being passed anyways

4. Are you sure that the l, w, and h for your boxes are valid and/or non-zero?
i know they are valid because i actually draw them and they appear (all six faces) as they should

im going to fix that *pos thing though good catch >_<

--edit
hrm it seems as if there is a second set of 'invisible walls' that actually enforces collision restrictions... and these invisible walls seem to be attached to the first wall of my real wall...
maybe somewhere i reference the values with negatives w/out realizing it...

Share this post


Link to post
Share on other sites
It's not immediately clear to me why the test always returns false, but I think if you add some debug output it should be fairly easy to track down the problem. In the containment function, print out x, y, z, l, w, h, xVal, yVal, and zVal. Also, add output to track the logical flow, e.g. 'First conditional passed' (you'll need to add braces to your conditional blocks for this).

With this information available, it should be fairly easy to see what's going wrong.

Share this post


Link to post
Share on other sites
sample of my log file
the top three are my coordinates - the dist is the amnt travelled from my last poll and the bottom 6 are the x,y,z,l,w,h of my box

******************
-10.642788,-134.657974,-10.766045 - dist travelled: 1.056874
50.000000,0.000000,50.000000,100.000000,100.000000,100.000000

******************
-11.285576,-134.315948,-11.532089 - dist travelled: 1.056874
50.000000,0.000000,50.000000,100.000000,100.000000,100.000000


so obviously although it looks as if im approaching the 'box'
im actually getting farther away from it.
so...instead of finding out why..i cheated....and passed
-xPos, -yPos, and -zPos into the "withinMe()" method
...
now it works like a charm

im such a noob /shame

thanks for the help

Share this post


Link to post
Share on other sites
Your arguments are called xPos but you're using xVal within the function.

The 'is inside' for an AABB is a one-statement function:

struct Cuboid { float x,y,z,dx,dy,dz; }

bool isInside(Cuboid c, float x, float y, float z){
return ((x>=c.x) && (x<=c.x+c.dx)) &&
((y>=c.y) && (y<=c.y+c.dy)) &&
((z>=c.z) && (z<=c.z+c.dz));
}

Share this post


Link to post
Share on other sites
Quote:
Original post by Bob Janova
Your arguments are called xPos but you're using xVal within the function.
I pointed that out in my first reply (and the OP already mentioned that he was going to fix it).
Quote:
The 'is inside' for an AABB is a one-statement function:

struct Cuboid { float x,y,z,dx,dy,dz; }

bool isInside(Cuboid c, float x, float y, float z){
return ((x>=c.x) && (x<=c.x+c.dx)) &&
((y>=c.y) && (y<=c.y+c.dy)) &&
((z>=c.z) && (z<=c.z+c.dz));
}
For whatever reason the OP set up the test so that the delta values (your dx, dy, and dz) can have negative values, so the above solution does not apply in this case. Needless to say though, it would probably be to the OP's advantage to ditch the 'signed extents' and use a more typical representation for his axis-aligned boxes :)

Share this post


Link to post
Share on other sites
Your if statement seems horribly confused. For instance:

(xPos <= x)&&(xPos >=x+l)

is equivalent to

xPos == x

I really don't understand what that collision detection routine is supposed to do. The leading parts of your compound checks seem to only check if the position is within one unit of the boundary of the box. The latter parts, as I pointed out above, just check to see if it exactly equals the wall position.

Generally you just check to see if it's inside the box.

Are you pre-transforming the test points to box local space or something? It's very unclear why you're not just using standard OOBB collision detection that someone posted above. I think you're complicating this problem by at least an order of magnitude. =)

-me

Share this post


Link to post
Share on other sites
Quote:
Original post by Palidine
Your if statement seems horribly confused. For instance:

(xPos <= x)&&(xPos >=x+l)

is equivalent to

xPos == x



He's using floats, so those two aren't necessarily equivalent.

Share this post


Link to post
Share on other sites
Quote:
Original post by Palidine
Your if statement seems horribly confused. For instance:

(xPos <= x)&&(xPos >=x+l)

is equivalent to

xPos == x
Keep in mind that l in the above example is a variable (lower-case L) whose value may be negative. So the conditional does make sense, but as his been noted it's more complicated than it needs to be (in particular, things could be simplified considerably be restricting the box extents to positive values).

Share this post


Link to post
Share on other sites
Quote:
Keep in mind that l in the above example is a variable (lower-case L) whose value may be negative.


Yeah, I got that it was an L. =)

I totally misunderstood what was meant in the above post about what "may be negative" meant. Never occured to me that you'd have the l/w/h parameters be negative in an OOBB. o.O

[EDIT: heh. seem to have also missed the part where he said the problem was solved. damn.... *runs for more coffee]

-me

Share this post


Link to post
Share on other sites
Quote:
Original post by Palidine
Quote:
Keep in mind that l in the above example is a variable (lower-case L) whose value may be negative.


Yeah, I got that it was an L. =)
I figured you did, but in my browser at least the 'l' does look quite a bit like a '1', so I just thought I'd mention it :)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this