Which would be better when determining collisions and response updates? 1. Save new desired positions for all entities. Perform collision detection and response. 2. Compute new position for an entity. Perform collision detection and response immediately. The problem with 2 is that entity to entity collision aren't correct yet because some entities won't be in their new positions. On the same page would be, let's say you have a fast moving object. It intersects 2 different objects if it were to continue. This means I'm going to have to check all the objects in my 'sector' and determine the shortest collision I guess. Not a big deal but just curious on how other people have handled such things. This also applies to volume entities too. Say a sphere hitting a corner. In it's new position it might hit both 'walls.' Perhaps a movement threshold for my sector? If an object is moving less than this threshold it most likely will only collide with a single object? Basically, I'm just trying to find some optimizations. I will be implementing option 1 at this time.

Disclaimer: I'm not an expert on this.

Now that that is out of the way, the method I'm currently using is #2

and I check collisions in the following manner:

1) Find all objects that intersect sphere with radius equal to your bounding radius plus the length of the movement vector, and put references to these objects in a container.

2) Remove all objects from this container which cannot have been collided with (if they are behind the moving object).

3) Then perform intersection test on all objects left on the container starting with the closest.

4) If there are no collisions you can move the entity, otherwise respond however it is appropriate.

Hope that helps :)

Option 1 is better I think. I get to do accurate sweep test collisions with moving entities and all that.

On a side note, if you haven't done any physics dev, DO IT! There is a lot of satisfaction that comes from watching what happens when you drop in new collision objects, gravity sources, entities, etc into your physics graph. I've spent a bit too much time away from coding watching gravitic sources and springs. hehe

Happy coding.

I'm no expert either but just a thought:

Updating positions first lets you determine the effect of the collision based on the overlap and I think would be easier to implement. But what if an object is traveling fast and misses other objects' bounding box between ticks.

I can only think of two ways to avoid this and produce accurate collisions, both of which use LordShades' first method:

- Compare every object with every other object (extremely slow).

- Draw a line between the objects' current position and its future position, if this line crosses another, perform the collision.

My second option there is a very simplistic implementation, more thought is required.

Please respond with your own ideas and/or pseudo code, I'm very interested in a practical solution to the problem.

I've only used option 1, but I'm a bit of a noob at Collision Detection. *However* I thought I'd offer this link to a great book I've looked over at Barnes and Noble, but haven't had the cash to buy:

Real Time Collision Detection

I'm sure it would answer your question and a whole lot more. Hope it helps!

Here's what I'm doing so far. Again this is option 1.

First we have some classes(2D atm):

Sector - AABSquare , has it's own gravity vector
Entity - A physical, mobile object
Collidee - A physical, non-mobile object
Portal - Warps entities when collided with, this is used for sector walls(moving from sector to sector) and warps. All I have is a translation vector and a facing(rotation) setting if an entity hits.
* bunch of other classes

How I do my physics update:

In one sector:



This is just my first wack at it. Couple of issues I've identified so far:

1. No entity to entity collisions. Really, I could just make an entity that's a collidee also BUT I would get double intersection tests with this code. Gonna have to do something else.

2. Collision Response.

I need to make a recursive function for when an object does reflection off a collidee. This allows me to check it's new vector against all the collidees again. Will have to have some sort of recursion depth to stop it from going too deep.

Again, just a work in progress. Bunch of work still needed to be done. Collision and Response can get very complicated.

Happy coding.

I bought "Real Time Collision Detection" book, The Steve, but I could not use it. After I read the first five pages or so, everything got insanely technical. I did my best to understand it, but after several weeks of cracking my head I gave up, and now this book is sitting on my shelf and gathering dust.

This book was obviously written for people who have a Ph. D in math and physics and would like to learn more about game-specific physics implementations. I have no problem understanding trig, and I love trig, and I also never had any problem writing code. So I wouldn't say I am a complete idiot, but this book is waaaaaaay above my math abilities. It's like trying to read greek.

I am just mentioning this here, so you don't waste your money on this book if you are not confident about your math knowledge.

I have Physics Modeling for Game Programmers. Not a bad book but I find it complicated also since trig is definitely not my strong suit.

Happy coding.