Knowing collision beforehand

Started by
8 comments, last by oliii 16 years, 6 months ago
Hi. I'm trying to implement a 2D rigid-body system. Searching in Google, I learned some techniques to deal with collision detection & responses, but I'm still having no idea about this: It is possible to calculate after exactly which seconds the collision occurs? Thank you in advance.
Advertisement
You can only estimate, ofcourse; you never know what the future brings.

Why do you have to calculate this kind of stuff anyway?
Because I wanted to implement an (almost)exact collision detection & response, since I am about to write a kind of physical simulation (sorry for not mentioning this before.)

And one of my teachers told me "maybe it is possible to anticipate collision stuffs beforehand since you know all the physical information given," and I wasn't able to find evidences to object his view.

Thanks for the reply.
Interestingly, I spent quite a while working on much the same thing. My idea was that if you represent every object by equations, and their motion by equations as well, you can solve for the future state at an arbitrary time.

Unfortunately incorporating rotation results in some ghastly equations, which I couldn't solve, even for the case of two rotating, moving straight-line segments. If you want, I can post the relevant equations when I get time. But to do this you will need pretty damn good maths skills.

That sounds interesting.

Would you let me know where I can refer to the equations?

The Continuous Colllision Detection article is a good start. It's still math heavy. At the moment, most of the interactive collision systems only work with linear motion.

http://citeseer.ist.psu.edu/redon02fast.html

In 2D, it's easier, but still not easy :)

Everything is better with Metal.

Thank you for introducing the article.

It looks difficult, but I'll take time to understand it.
Olli: You mean no rotation right? If it was incorportaing rotation I would be impressed.

leonid: Here are some of the equations that I had knocked up while I was working on it. Y and T are the only variables. This sort of stuff _is_ feasible though, I had something which worked somewhat, unfortunately the maths(numerical methods for solving these equations) behind it wasn't really consistent enough (although sometimes it worked _perfectly_). Maybe I'll come back to it at some point, there's still some hope for it.
Note: When I said I couldn't solve them, I couldn't even find a reliable numerical solution :(








Something no one seems to mention about continuous collision detection is how you actually use the results of your time-of-collision tests; you can't just drop sweep tests in as a replacement for static tests, you have to totally restructure your simulation so that it's more of an event-based, scheduler-driven thing.

Has anyone else had problems with this? It makes things much more complex (and slow, since you have to perform many collision tests, step things forward, and repeat) to the point where simply perfoming static tests 4x per frame seems more attractive..
yes it is. I actually have the same problems you encounters. I tried to swap a descreet sampling method (slicing the movement into small intervals), and a swept test does require more work than just that.

Everything is better with Metal.

This topic is closed to new replies.

Advertisement