I am at the stage of my development process where I want to implement collision. Now I can think of a simple way of doing it, if the camera's x, y or z are inside the position of a certain cube then don't let the camera move in the direction it hit the object. Seems simple enough.

The thing is I think this will be pretty intensive for collision detection. I am using a 3D array for my cubes, and I think there maybe is a way to simplify it by using this array. I just don't know how. If there isn't a way because the camera can move freely is the idea that I suggested a good way of doing collision? It will only be run on one group of cubes, the one you are above at X point in time. Cubes are static at every point in time.

  • 1
    \$\begingroup\$ Have you considered integrating a physics engine, this is kind of their specialty and they're highly optimized for collision detection. \$\endgroup\$ – Patrick Hughes May 6 '13 at 15:10
  • \$\begingroup\$ I don't want to use any extra engines or library s.. this shouldn't be too complicated.. \$\endgroup\$ – Amit Assaraf May 6 '13 at 15:39

Depends on which type of bounding box you're talking about.

Axis-aligned bounding cubes are one of the fastest ways to do a rough first-pass collision test, before sending those that pass to a more precise collision check. Edit: This is especially true when you have multiple moving objects that may collide with one another.

Oriented bounding cubes require more, and more complex, operations, and wouldn't usually be my recommendation for a first pass collision check, but could be used for the second pass if your game objects occupy the majority of that cube. Which, in this case, they actually are cubes, so that fits perfectly. This case would be an exception where if you have a manageable number of cubes, this could be the only check you need to run. However, if you find your game loop slowing down as the number of objects increases, you'll probably want to find another method to prune some number of objects from the list before running this type of test. (Assuming it's the collision that's slowing the game down, and not some other method that's also running on those objects each frame.)

Other than AABB's, and because the cubes are static, you could also use some form of collision tree. In 3D space, look at Octrees. If visualizing the octree isn't easy at first, look at 2D Quadtrees and then come back to 3D. For static objects, the greatest improvement in performance requires either building the tree offline and storing it in a file, or increasing your level load time by building it at run-time. This is just something to be aware of, and unlikely to be a deal-breaker.

My recommendation, because of the specific scenario you described, would be to try OBB's, because your objects actually are cubes and thus this will be the most accurate test possible. See if the game can handle it without slowing down. If so, no need for anything else. If not, AABB's are relatively easy to implement, try nesting your collision such that you check against the AABB first and only if you find an AABB collision would you attempt the OBB collision check. If that's still not enough, scrap the AABBs, look into Octrees and run your OBB collision only if you find a hit within the tree.

| improve this answer | |
  • \$\begingroup\$ Sorry, a little inconsistent in my naming of things. AABB = Axis aligned bounding box (cube) OBB = Oriented bounding box (cube) \$\endgroup\$ – LLL79 May 6 '13 at 16:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.