martes 16 de diciembre de 2008

Time Critical Collision Detection

One of the bottlenecks to obtain real-time physical based simulations is the collision detection process and much research has been done on this. In the past, I proposed a method to fit the collision process to any given budget of time. See the paper here. This method works for rigid and deformable bodies.

The idea is to interrupt the collision process when our budget of time has expired and use the available information to compute the collision response (it this happened). The computed response is an approximation of the real one: Yes, we trade time for accuracy, but in general the results are quite satisfactory.


The method is based on sphere representations of the object. Each of these representations goes from a coarse representation (a) to a high quality representation (d). If we have little time, we compute the collision detection process using (a) or (b) representations as in the figure above. If we have lots of time, we use more detailed representations (c) or (d). The coarser the representation the less accurate is the response (or even the detection).

The complexity of the problem comes to compute good responses even with little information.

The question is: do you prefer high accurate responses even if your application goes slow or do you prefer to keep your simulation rates and obtaining some non-accurate responses ??

Well, here at Atari we have decided to go for high accurate responses... so, that means that I will have to find other ways to keep good simulation rates... good challenge !

So, if anybody have some good ideas, please let me know.

3 comentarios:

  1. Well, the most popular sentence these days is: "go parallel!". Take the most advantage of multiple processing units... instead of using the processing power to increase the performance, use it to improve the accuracy!
    good luck :)
    cris

    ResponderSuprimir
  2. Hi Cris,

    Thanks for the advise. We have started in some little things like parallelizing the broadphase but for the rest, it is still under work.

    Anyway, it is dark enough for me how to distribute the collision detection for the narrow phase of pairs... I need to re-think more on that.

    Thanks anyway.
    cesar

    ResponderSuprimir
  3. I see! But I can also tell you that nowadays is a pretty standard solution distributing the narrow phase on several threads/cores. It's what the major engines do (physx, havok, bullet). Once you collected the overlapping pairs (in the broadphase, through sweep and prune or some other way), the computation of every single "accurate" intersection is completely independent. You can setup a "task queue". Each task computes the narrow phase for a set of pairs (from 1 to N pairs, to be tuned), and at when all tasks complete, the contact solver can start. I did the same for my little 2d engine and it works very well... actually it gets better when the number of contacts grows!
    ciao!
    cris

    ResponderSuprimir

Put a message :)