Skip to main content
GameDev.net gamedev.net
🔒 Locked

collision detection question...

Started by indigox3 Jul 2, 2004 at 11:29 PM 9 replies 1.4k views
Original Post
indigox3
indigox3
Hi, I'm doing some simple stuff in ogl to draw some cubes and spheres, where I first setup the camera, push the current modelview matrix onto the stack, translate to wherever I want to draw the current object, draw, then pop, returning to the original coordinate system. My question is, if the objects are draw with coordinates relative to their own local coordinate systems, how is it possible to do things like collision detection? (b/c you would need the global coords of everything to decide whether or not they collide right?)
SpaceDude
SpaceDude
collision detection is done independantly from displaying the objects on screen. So the method used for drawing on the screen makes no difference to the collision detection.

>>(b/c you would need the global coords of everything to decide whether or not they collide right?)

yes, and you will have this information since you needed it to translate your object to the location it was drawn.
indigox3
indigox3
Thanks for the replies,

Ok, so, in general, how do I go from local to world coords?
The only way I can think of doing it is to contruct a 4x4 matrix for each local coordinate system, representing its scaling, rotation and translation, then multiplying the original modelview matrix by this one, then multiplying this new matrix by all the coords in the object, to get the world coords.

But:
1) is this even correct?
2) if it is, is there a faster way to do collision detection?
I think this method would be really slow as the number and complexity (in terms of # of vertices) of the objects grow.
SpaceDude
SpaceDude
Quote:
Original post by indigox3
Thanks for the replies,

Ok, so, in general, how do I go from local to world coords?
The only way I can think of doing it is to contruct a 4x4 matrix for each local coordinate system, representing its scaling, rotation and translation, then multiplying the original modelview matrix by this one, then multiplying this new matrix by all the coords in the object, to get the world coords.

But:
1) is this even correct?
2) if it is, is there a faster way to do collision detection?
I think this method would be really slow as the number and complexity (in terms of # of vertices) of the objects grow.


>>then multiplying the original modelview matrix by this one

What do you mean by modelview matrix? the camera position matrix? if so, you can cut out this stage.

But anyway, first of all.. if you are dealing with spheres alone, collision detection is simple:

if distance between the centre of the two spheres is less than the sum of their radii you have collision, if not then you don't.

cube collision detection is slightly more complicated, i couldn't tell you how to do it off the top of my head.
kburkhart84
kburkhart84
First of all, you already know what the global positions of your objects are anyway. You have to pass them into the glTranslate function, use the same global positions to track collisions. You don't have to have matrices etc.. for you to check, especially for a simple sphereical collision.


Zakwayda
Zakwayda
"How about for any 3d objects, in general. Say I had a 3d mesh of a car, and I use glTranslate to position it. If I wanted to check whether or not it hits another car placed in a different coord system, I would have to get the world coords of both cars right? Its just that converting all the coords to world coords first, before doing the collision detection seems like alot of work to do (for the CPU I mean, I dont mind coding it)"

Yes, somehow you need to get the objects into the same space to perform collision detection on them. If you're positioning them with OpenGL, it can be slow because you have to read back the modelview matrix - and then probably get the camera transform out of there - I'm not ever sure how you'd do it. It'd be better if you maintained the orientation and position of each object yourself, via a matrix or quaternion/vector.

Once you've done that, you can transform each model into world space via its transformation matrix, and compare them there. However, it might be less work to concatenate a transformation from model A's space into world space, and then from world space into model B's space, and perform the collision detection there.

Anyway, you began to see why people are inclined to use simpler primitives, such as spheres and boxes, to perform collision detection. It's not as accurate, but it's suitable for most games and is much easier to code.
SpaceDude
SpaceDude
Quote:
Original post by jyk
Anyway, you began to see why people are inclined to use simpler primitives, such as spheres and boxes, to perform collision detection. It's not as accurate, but it's suitable for most games and is much easier to code.


The main reason isn't that its easier to code... its that its much faster for the computer to process.

to indigox3:

I might be wrong here, but it seems to me that you don't really know how to perform the collision detection even if you did have the global coordinates for both objects. I suggest you look into collision detection a bit more, i think you will be somewhat suprised how difficult collision detection between two 3d polygonal meshes really is (you will find that the computational costs of calculating the global coordinates are insignificant compared to those of the collision detection).
Zakwayda
Zakwayda
"The main reason isn't that its easier to code... its that its much faster for the computer to process."

I didn't say that it was the 'main' reason - I was just offering it as 'a' reason. Of course simple primitives are faster.
indigox3
indigox3
Yeah, you guys are right. I haven't really looked into it much, thats why I'm starting with simple primatives. But thinking ahead to more complex objects starts to boggle the mind...

Oh well, right now, its not nessecary for my 3d pong game anyways =)

Thanks for the ideas

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.