Crazy(?) collision detection idea
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
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.
This would be fine for a projectile, but for something like a player object this would be pretty much impossible.
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
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
because you need to perform several requests to the memory in order to receive the desired information
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
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement