Crazy(?) collision detection idea

Started by
5 comments, last by Hungry Joe 20 years, 1 month ago
Here is an interesting idea for game representation i think (i may be wrong about facts tho...) in a fairly standard collision engine, the bounding box of an object is calculated each frame and compared with the bounding boxes of all the other frames. Next frame you need to recalculate the bounding box and compare it again. Instead of calculating the bounding box, how about calculating the formula of the bounding box with respect to time, so we can get the bounding box at any time t. I think you could then doa simultaneous equation against the bounding box formulas of the other objects once, and you would get a time t, that the object will hit something else. You only need to do this calculation once, until the object you have calculated the bounding box for has a new force applied. This would allow you to calculate the collisions before they happen, and each frame you just have to look at a list of the collisions you have already detected. I think there would have to be some very clever maths to work out the formula of the object with respect to time, but the thing is, you should have enough information to predict everything that will happen in a model until there is an external input (from the player or AI or something), at which point you recalculate the affected objects. any thoughts? this may be unworkable, or maybe what already happens but I''d love to hear what you have to think. Or if you need some more explanation i''ll try
0110011001110101011000110110101100100000011011110110011001100110
Advertisement
I think the problem with this technique is that it assumes that all objects will continue to move at the same speed and in the same direction.

This would be fine for a projectile, but for something like a player object this would be pretty much impossible.
Parallel RealitiesProject: Starfighter
with a clever enough formula you should be able to take into account constant acceleration and rotation, only needing to recalculate when something not expected happens
0110011001110101011000110110101100100000011011110110011001100110
collecting all the information to precalculate a boundingbox formula for the next frame wastes more time than recalculating the boundingbox each frame

because you need to perform several requests to the memory in order to receive the desired information

http://www.8ung.at/basiror/theironcross.html
This is along the lines of what I did on a pool game I wrote recently. Rather than divide each update into small time steps and test for intersections at each sub-interval, I calculated the time for all intersection points and updated the balls for the shortest interval (or the frame time if that was the shortest), then did collision response if needed and repeated. The problem with this approach is that you get bad rounding errors, i.e. once a collision is found and the balls are moved in time to the collision, the balls may move slighty further than you expected. I managed to convert all the collision tests into either a line-line intersection or a line-stationary sphere test.

Which was nice.

Skizz
I dont understand why the bounding box is being recreated everyframe. Why not just build it once and offset it when testing?
yeah, its the offsetting you need to do each frame which this would avoid, and also all the comparisions against the other world objects each frame.

Each of these only needs to be done once, rather than 60 times a second, when the formula that represents the bounding box/object changes after an unpredicted force is applied.
0110011001110101011000110110101100100000011011110110011001100110

This topic is closed to new replies.

Advertisement