Skip to main content
gamedev.net
🔒 Locked

Need help

Started by ArchMiffo 0 replies 550+ views
Original Post
ArchMiffo
ArchMiffo
Me and some friends of mine are gooing to make a 3D-game. We have the basics done and now it''s time to start working on the maps. Since this is the first thing any of us do in 3D we are going to start really simple. Right now the map consists of some cubes. What I would like to know is how to detect collisions on thoose cubes. Sure it''s extremly simple to check if a point is inside the cube, but I need to know how far the camera can travel along it''s direction before it hits something. The way I''m doing it now he camera sort of stix to the surface of the cube it hits. In order to mover around properly you should sort of glide along the wall. What I have to work with is the cameras position, it''s direction and all the cubes posistion and their corners positions. If anyone would like to help me with this or point me to a good site where it''s explained in a very simple manner I would be grateful. Thanks
grhodes_at_work
grhodes_at_work
There are two problems that you have to deal with after you know that a collision occurred. First, you need to know the exact position of the camera when the collision occurred. Then you have to know which direction is parallel to the collided wall. Here''s a simple approach.

To find the exact time of the collision, you would first construct a line segment that points from the camera''s position at time t0 (position A) to the position at time t1 (position B). The times t0 and t1 correspond to the previous frame and the current frame, or some other period of time that you may be using for simulation calcs between frames. If your camera always moves in the direction it is looking, then the direction of the line segment is the same as the camera''s direction.

The line segment from point A to point B represents all of the camera''s locations during the time that passed from the previous frame to the current frame. If a collision occurred then you can use that line segment to find the exact time of the collision, even if the collision occurred between frames. You do this by finding the intersection of the line segment with the faces of the cube. Suppose the intersection point is point C, which lies somewhere between point A and B. Then the exact time of the collision is:

time_of_collision = t0 + (t1 - t0) * length(C - A)/length(B - A)

Now, assuming the camera is perfectly elastic, even after the collision it would have travelled for an additional:

time_travelled_after_collision = (t1-t0)*length(B-C)/length(B-A)

There are many tricks you can use to quickly find those cubes with which the camera might collide. You''ll need to look into this further. Using an octree (for arbitrary 3D world) or quadtree (for world arranged primarily in 2D) spatial subdivision structure is one way to find a small set of cubes that the camera might collide with. The idea is to find point C and the collided wall as quickly as possible without testing every single cube or every single face of a cube.

Point C is the collision point. Now, suppose N is the normal vector of the wall at that point, and N points towards the outside of the wall. In this case, after the collision, the camera cannot move in the direction opposite of N (into the wall). Without the collision, the camera would have moved from C to B after arriving at point C. With the collision, assuming
the camera sticks and slides frictionlessly along the wall with which it collided, the camera would only be able to move the following additional distance from C:

distance_travelled_after_collision = (B-C) - N*Dot(N, (B-C))

where Dot is a dot product

So, the final position of the camera at the current frame, time = t1, is:

final_position_time_t1 = C + (B-C) - N*Dot(N, (B-C))

As long as the camera remains in contact with the wall, and is trying to move into the wall, you have to remove the component of velocity or direction that is parallel to N. That is, you have to remove the N*Dot(N, direction/vector distance travelled or velocity) before moving the camera.

I know that''s awkwardly written, but hopefully it helps, .

Graham Rhodes
Senior Scientist
Applied Research Associates, Inc.
Graham Rhodes Moderator, Math & Physics forum @ gamedev.net

Topic Locked

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

Sign in to reply to this topic.