Jump to content

  • Log In with Google      Sign In   
  • Create Account


Collision Detection of Multi-Part Object


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
3 replies to this topic

#1 Littorio   Members   -  Reputation: 254

Like
0Likes
Like

Posted 02 May 2009 - 10:19 PM

In my space game i have ships that are composed of a hull and many turrets that can rotate indipendently. When two ship are close and have to check for collision i rebuild the collision data with the current position of the turrets to use the hull and the turrets as a single object. This method is too slow. There is a collision library that manage this situation? If not what else can be done?

Sponsor:

#2 scgames   Members   -  Reputation: 1969

Like
0Likes
Like

Posted 02 May 2009 - 11:37 PM

Quote:
Original post by Littorio
In my space game i have ships that are composed of a hull and many turrets that can rotate indipendently.
When two ship are close and have to check for collision i rebuild the collision data with the current position of the turrets to use the hull and the turrets as a single object.
This method is too slow.
There is a collision library that manage this situation? If not what else can be done?
A few questions:

1. 2-d or 3-d?

2. What method (e.g. SAT, etc.) are you using for your narrow-phase collision tests?

3. Are you doing any sort of broad-phase culling?

4. How do you know it's too slow?

Instead of rebuilding the collision data to account for the movement of the turrets, I would instead represent the ships as composite entities, each element of which has its own collision proxy. That is, as far as the collision detection system is concerned, the hull and each of the turrets is a separate object.

Depending on how your system is set up this may require some restructuring of your code, but you will gain flexibility (and perhaps improve performance as well, depending).

As far as libraries go, Box2D would probably be a good one to look into (assuming of course that a 2-d physic library would work for your project).

#3 Littorio   Members   -  Reputation: 254

Like
0Likes
Like

Posted 03 May 2009 - 12:40 AM

Quote:
Original post by jyk
1. 2-d or 3-d?

3-D

Quote:
Original post by jyk
2. What method (e.g. SAT, etc.) are you using for your narrow-phase collision tests?

3. Are you doing any sort of broad-phase culling?

I don't know this details. I'm using OPCODE collision library

Quote:
Original post by jyk
4. How do you know it's too slow?

It's already implemented and the rebuild take about half second for a 7000 triangle ship

Quote:
Original post by jyk
Instead of rebuilding the collision data to account for the movement of the turrets, I would instead represent the ships as composite entities, each element of which has its own collision proxy. That is, as far as the collision detection system is concerned, the hull and each of the turrets is a separate object.

If each ship has 10 turrets you must check 100 collision , one for every pair.




#4 scgames   Members   -  Reputation: 1969

Like
0Likes
Like

Posted 03 May 2009 - 09:19 AM

Quote:
It's already implemented and the rebuild take about half second for a 7000 triangle ship
It sounds like part of the problem is that you're using the same geometry for both rendering and collision. Typically, if you have a 7000-triangle ship model, you would use a simplified version of the geometry for the purpose of collision detection.

In any case, you definitely don't want to be rebuilding collision geometry like that while the simulation is running.
Quote:
If each ship has 10 turrets you must check 100 collision , one for every pair.
That's what broad-phase culling is for :)

First of all, it's not actually 100 collision tests, but rather a number somewhat less than that (due to the fact that each unique pair need only be considered once, and no object in the set need be tested against itself).

Still, the problem you mention has to be dealt with one way or another. Even in a simple 2-d arcade game, once the total number of objects gets into the hundreds, the brute-force approach can quickly become unworkable. The solution is to apply broad-phase culling of some sort, usually via some sort of spatial partitioning. I believe OPCODE will do this automatically, but with such complex geometry the performance may still not be suitable for a real-time simulation.

To summarize, I think that for the purpose of collision detection you'll want to use separate, simpler geometrical representations of your objects; furthermore, unless you're doing some type of morphing or deforming, you shouldn't be modifying this data while the simulation is running. I can't say for certain that that'll solve all of the problems that you're seeing, but it should at least be a step in the right direction.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS