Multiple collisiongroup per entity

Post and discuss features you'd like to see in the BEPUphysics library.
Post Reply
imtrobin
Posts: 101
Joined: Thu Jun 11, 2009 3:03 am

Multiple collisiongroup per entity

Post by imtrobin »

Hi,

While I'm designin the collisiongroups, I found that it would be useful if I can get an entity to have multiple collisiongroups.
It's a bit like the 0.9.0 system, combined with the new 0.10.0.

My situation is I have a tank, I set them to groundUnit collision group. But additionally, I have triggers in the game which only is fired specfically by the tanks. I could set the trigger to target to all groundUnit, which is quite wasteful to fire against all the other groundUnits. The ideal is I can set the tank to be in groundUnit collisionGroup and also a special triggerGroup.

That would be the ultimate collisionGroup system
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: Multiple collisiongroup per entity

Post by Norbo »

While I may do something like this, you can accomplish what you want to do by creating a collision group that represents the combination of the two other CollisionGroups. Basically, if you give an entity multiple CollisionGroups, the final rule will be equivalent to using a single collision group with an assortment of relationships to other groups.

With a multiple-group-per-entity system, there are a few more special cases to worry about for the user, like priority special cases, and some extra cost to determining a CollisionRule from having to go back to the Dictionary more often. Depending on the simulation, its possible that the multiple-group-per-entity system would be slower than simply firing events and testing their validity in the handler. Using the 'combined' collision group approach would be the most efficient of all. Of course, in any case, the performance difference is likely very small relative to everything else going on.
imtrobin
Posts: 101
Joined: Thu Jun 11, 2009 3:03 am

Re: Multiple collisiongroup per entity

Post by imtrobin »

Yes I could create a specific combination group but that would mean an explosion of groups as they represent each entity. I have large predefined categories

UnitAir
UnitGroud
Prop (Terrain)
Buildings
Weapons

And specific triggers for specific units. Weapons for example, hit everything, so imagine if I have give specific collisiongroup to each entity, it quickys becomes unmanageable. I like the old 0.9.0 system where I could define an Entity into multiple groups, combined with this new one, would be awesome.
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: Multiple collisiongroup per entity

Post by Norbo »

I can see how it could become problematic if you did have a group for every entity, but I don't think I understand why you need a group for every entity.

It sounds like the specificEntities list might help out a bit. You could add a bunch of entities to an entity's collisionRules' specificEntities list and then re-use that collisionRules instance (or specificEntities dictionary instance) across a set of entities if you'd like.

This isn't to say that multiple groups an entity won't be added in some form; I just want to understand the specific situation better.
imtrobin
Posts: 101
Joined: Thu Jun 11, 2009 3:03 am

Re: Multiple collisiongroup per entity

Post by imtrobin »

I'm using the physics as triggers to detect when a unit comes into/out of range. So I have air, ground turrets which target the air and ground units specifically only. Other than that, I have specific triggers for specific unit types. So for an air plane unit, I like it to be in collisiongroup AirUnit and a CanTriggerXX group.

Since I'm building units and turrets in game, it might be a performance problem to keep changing the specific entities list.
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: Multiple collisiongroup per entity

Post by Norbo »

If you re-use the same dictionary/collisionRules instance across a variety of entities, you will have to do very few operations (amounting to nanoseconds) when things are created or destroyed. However, it may end up being more complicated overall for your specific situation than doing it another way.

However, one of the main problems I foresee with a multiple-groups-per-entity is complexity caused by competing priorities.

Let's say you have the following situation:
Entity A is in group Trigger.
Entity B is in groups AirUnits and CanTrigger.
AirUnits and Trigger have a CollisionRule between each other of noPair.
CanTrigger and Trigger have a CollisionRule between each other of noResponse.

When the system starts to combine the collision rules of A and B, it has two conflicting rules as expected: noPair and noResponse. However, going by the default combination method of collision rules, noPair will be used instead of noResponse since it is a more 'severe' restriction. So, despite having the special secondary group, the pair will still not be created.

To solve this problem, you would need to reverse the priorities. This could either be done globally or somehow only dealing with a specific pair. Specific-pair based solutions would add a significant layer of complexity, while a global solution can trigger the same problem in reverse somewhere else in the simulation.

All of the functional power of the old system is still present in 0.10.0 using a single collision group per entity, it just requires managing the instances and their rules. Some simple helper functions could be created to ease the process; I plan to add a set internally in the next version. There will be nothing in them that couldn't be done externally.

In the single-group system as you mentioned, there generally comes a point where the most direct solution is to have conditions in the event handler itself. For any sufficiently complex situation, these conditions will need to exist because no general purpose collision rule system can handle every sort of interaction rule desired by gameplay logic. The extra time spent calling an event and examining special collision conditions is insignificant (on the order of nanoseconds). Working on the assumption that they won't cause noticeable performance loss should work out fine. If measurements later indicate they are taking a disproportionate amount of time, they can be revisited.

The main problem is the extra code complexity, either during the creation of collision groups and their rules or in the event handler. I would like to minimize this as much as I can from a general perspective. This means creating the simplest method that has the most power. The current system could definitely be improved and I will continue trying to do so, but I don't think this particular version of the multiple-group-per-entity approach would provide enough power to warrant its additional complexity and gotchas. It could turn out that it would be as much work, or more, than the current system to accomplish your goals.
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: Multiple collisiongroup per entity

Post by Norbo »

By the way, if you're using noResponse as a CollisionRule between trigger entities and other entities, the cost associated with doing the collision check to generate contacts is generally orders of magnitude greater than the event processing.

For range checking in particular, your best bet would be to use noContacts as a CollisionRule and then perform your own range checking. This could be done between center positions or using some other means. Obviously this will be a bit of an approximation compared to actually running contact generation between a complex compound body and sphere, but you can tweak it to be plenty close.

Additionally, you could avoid using events entirely in such a system. It may be easier overall to use the trigger entity to collect candidate entities in its collisionPairs list, and then iterate over the list while testing for collision later, perhaps every half second or whatever interval you'd like.
imtrobin
Posts: 101
Joined: Thu Jun 11, 2009 3:03 am

Re: Multiple collisiongroup per entity

Post by imtrobin »

I see the problem with the conflicting priorities. How does the new system still be able to work like old system with single collisiongroup?

Just for an idea, please see this. I gonna have a lot of units and I hoping to minimize unnecessary callbacks.

http://envisagereality.com/downloads/te ... feroll.avi
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: Multiple collisiongroup per entity

Post by Norbo »

The new system has the same functional capabilities as the old system in that you can make a collision group for an entity that does what the old system could do for a specific entity. It could take a bit more work to set up in some cases, but it can do the same amount (and more) when set up.

For example:
Entity A has collisionFilter 01.
Entity B has collisionFilter 10.
Entity C has collisionFilter 11.

is equivalent to

Entity A has collision group A.
Entity B has collision group B.
Entity C has collision group C.
Group A has noPair with Group B.
Group C has no special relationships, defaulting to normal CollisionRule for C-A and C-B.

This is obviously a contrived example, but the idea applies generally. So, while in some specific instances there may be more set-up (sometimes more complexity), you can do the same relationships and others too (more power).


If you want to reduce the overhead as much as possible, I'd suggest using the periodic approach I mentioned in the last post. The trigger would have a CollisionRule of noContacts with its candidate entities. You could iterate over a trigger's collisionPairs every once in a while, maybe every tenth of a second, testing them for (squared) distance and whatever other conditions you want. This would eliminate all callbacks and reduce the overall cost quite a bit. You could stagger the updates so that some of the triggers are tested every frame, spreading out the workload. From a gameplay perspective, a tenth of a second maximum delay in detection and 'locking on' would likely be completely unnoticeable.

Looking good by the way!
imtrobin
Posts: 101
Joined: Thu Jun 11, 2009 3:03 am

Re: Multiple collisiongroup per entity

Post by imtrobin »

Norbo wrote:For range checking in particular, your best bet would be to use noContacts as a CollisionRule and then perform your own range checking.
This is a little concerning. I'm using spheres for triggers, so I assume there's only a simple distance squared check but this seems not the case. So the broadphase is using AABB only?

BTW, for the example, Collision Group C is creating another collisiongroup. If I have one that is

0100
1010
1100
1110

means I need to create 4 collisiongroups.
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: Multiple collisiongroup per entity

Post by Norbo »

Collision pairs generate contacts with the goal of supporting a collision. This means they need a good bit of information- position, normal, penetration depth, and some other auxiliary things. All of these things are necessary because the goal is more general than a boolean 'is colliding' test. Even the simplest case of sphere-sphere cannot be resolved completely by a single squared distance test (though it is used as an early out). Other entity combinations are significantly more expensive than sphere-sphere also.

If you don't need any of this information, making a specialized test will be faster and much more direct.

The broad phase uses AABB's as a generally well-fitting bounding volume that has a quick intersection test. There are many options when it comes to algorithms with AABB's.

If you set the collision rules to noContacts, you will essentially only have the collision pair registered with the engine. It won't try to do anything with it and there's basically no overhead. You can look at an entity's collisionPairs and perform your specialized test between each pair's colliders. This completely avoids using event callbacks and allows you to do it whenever it is convenient.

Regarding the collision groups, yes, in that example there are more groups. Collision groups can do the same operations as the old system and then some, and it can require additional work in some situations.
Post Reply