TriggerVolume enhancements

[aqnuep]

Hi Julio,

My question is whether massive usage of trigger volume collisions makes a significant performance hit or not.
Of course, for just a few trigger volumes there's no problem. However when having hundreds of trigger volumes performance may be a concern.

I am thinking about using trigger volumes everywhere where game logic should happen, but I don't know if it will slow the engine down or not.
Trigger volumes does not generate contacts so I think they are already quite lightweight, however I don't know how expensive is for Newton to always calculate collisions of trigger volumes with other collision primitives, especially when some bodies are inside the trigger volume and they stay there for a while.

To emphasize that I am talking about really heavy usage of trigger volumes, let use as example a strategy game. Let say that for every entity we maintain two trigger volumes: one sphere for the view range and one sphere for the weapon range. These are attached to the body of the entity somehow. Using the callbacks it's now easy to decide when an entity should automatically move to an enemy unit (when it's in view range but out of weapon range), or when to shoot (when it's in weapon range).
Of course, I know that this is not the most optimal way how to solve strategy game AI, I just use this as an example to show a use case when one may use huge amount of trigger volumes.
Anyway, my question that would this solution work in practice with high amount of entities? Are trigger volumes lightweight enough for such thing?

P.S.: One more question! It's not related exactly to the topic but it's about trigger volume collisions: can I create a compound collision which is made of one or more normal collisions and one or more trigger volume collisions? If yes, then how? If no, then you can take this as a feature request

[Julio Jerez]

I do not know how expensive it will be if you have lots of triggers, I knwo it is faster tha having thme as collision an rejection the contacts.
triggers are much faster the collision because they do not calculate any contact at ll which is the part the make collision most expensive.

how many units are we taalking about?

[aqnuep]

I do not know how expensive it will be if you have lots of triggers, I knwo it is faster tha having thme as collision an rejection the contacts.
triggers are much faster the collision because they do not calculate any contact at ll which is the part the make collision most expensive.

I know this, but I'm worried about the overlapping calculations, because if many bodies are inside a trigger volume then (I suppose) they will be all in the same island and after bounding box check they will again and again be checked for collision against each other which I suppose can be a heavy computational tasks. Anyway, as I think such use cases will always use sphere collision probably this overhead won't be very high as sphere collision is the easiest to calculate with. Is this true? Is the collision system tuned for such possibilities? To be more exact, let's say a convex hull collision is checked against a sphere trigger volume. As contact points are not needed, then after Newton finds the first vertex of the hull inside the sphere, then it shall not check the rest of the vertices as we already know that the two primitives overlap. For normal collisions such optimization cannot be done, however, for trigger volumes it should work well. Is this currently working this way in Newton? It has such optimizations for trigger volumes? If yes, then probably the idea should work.

how many units are we talking about?

As I'm working on a generic game engine, not an actual game, I would like to be prepared for massive usage of the feature so let's say 1000 units.

[Julio Jerez]

Th ecollision have tree parts

-CheckAABB()

if this passes, then is check for is Check for closesttPoint()
if (this passes and it is the collision is a trigger) {
calculatecontacts ()

it is the last part the account for most of the time.

[aqnuep]

if this passes, then is check for is Check for closesttPoint()

So this is the last step for trigger collisions as contacts aren't calculated. However I have concerns with this one, because to find the closest point one must check all points of e.g. a convex hull. But for trigger volumes this is not needed (I think). Because if we find the first point which penetrates the trigger volume then we can skip the rest of the points. I would recommend then this optimization.

I know that such modification in Newton would require maybe a lot of time (depends on how nice is the architecture of the engine inside), but it would be nice to have such an optimization for trigger volumes so you should put it on the "wish list"

Btw what about compound collisions? I had the other question: can I make compound collision mixing normal collisions and trigger volumes?

[Julio Jerez]

Why don’t you just try? The function get closet point is fast. And it is use for collision everywhere.
When I made teh CUDA solve I did not do any of the collision and have a demo with two pyramid 100 x 100 each (10000 boxes) in a 260 gforce.

As for the second part a compound collision can have a collision as a trigger, but the engine is no really prepare to handle trigger as sub shapes. I was going to make do so then got distracted with ether destruction feature and some bugs.

To make that happens I need to add some interface to the material system so that a callback can report collision with trigger and contacts.
As stand now the only way to determine that is by checking that the contact handle does not have any contacts.
Using a compound collision would be the cheapest solution, but of you want to move individual trigger then scene collision can be an alternative.

For now the only way to do trigger is one body, one trigger one and one material call back which is very primitive.

[aqnuep]

Why don’t you just try? The function get closet point is fast. And it is use for collision everywhere.

Sorry for the theoretical questions. I will try it for sure. I'm just at design phase of the engine yet, some little actual code is ready only that's why I first ask everything what I can. Anyway, for now it seems OK to use trigger volumes, if I'll have performance difficulties, then we can restart the topic. Thanks for the answers!

When I made teh CUDA solve I did not do any of the collision and have a demo with two pyramid 100 x 100 each (10000 boxes) in a 260 gforce.

I know, a GPU implementation does not really suffer from such small unneeded calculations because of the highly parallel nature of the architecture, I'm concerned now only about CPU.

As for the second part a compound collision can have a collision as a trigger, but the engine is no really prepare to handle trigger as sub shapes. I was going to make do so then got distracted with ether destruction feature and some bugs.

To make that happens I need to add some interface to the material system so that a callback can report collision with trigger and contacts.

No problem. However, such an interface might be useful for others as well. That was only a forward looking question, just to know if there is any internal restriction that would prevent such behavior.
Anyway, thanks for your help.

[Julio Jerez]

Sorry for the theoretical questions.

you do not have to be sorry, I did no say as bad
I said that because the trigger solution came about as a feacture request.
I do not remember who requested but at the time the solution seems to sufice.
There are many, feature in the game that I have not tyried to exoctions.
I cannot rearlly spend so much time making elaborated systems to test the engine features, because it takes to much time with no guarentee it will be used at all.
It is when some decides to use a particular feature and find a weakness that the feature gets attention.

many time people comes with a sence of urgencey and I start a feature but the the person loses interets leaving me with something incomplete.
basically I end up with a solution in search of a problem.

[aqnuep]

I cannot rearlly spend so much time making elaborated systems to test the engine features, because it takes to much time with no guarentee it will be used at all.

That's totally understandable. Btw I just wanted to know if you know any weakness of the feature from point of view of performance as only you know the implementation, and what you told me it's already enough for me to be able to account with the fact how Newton works internally.

many time people comes with a sence of urgencey and I start a feature but the the person loses interets leaving me with something incomplete.
basically I end up with a solution in search of a problem.

My requests are far from urgent . I just think that trigger volumes are a very nice feature which is not yet complete, but already quite useful. Actually this feature is already far beyond the scope of a physics library, however, it makes sense to have it in Newton as there is already all the data (collisions) and algorithms (collision detection) which are needed for it.
Let then just say that in your long term plans maybe it worths to pay attention to this feature because such facilities are needed by every game.

P.S.: I rename the thread to "TriggerVolume enhancements" as our discussion is already well beyond the original question.

[aqnuep]

One more question:

Is there way to disable a trigger volume? Let say if we've found the first body which enters the trigger volume and we don't want to deal with other enters for a while and during this period it would be nice to disable the trigger volume to increase performance. After we've done with the body then we'll enable it again.

[Julio Jerez]

you can remove it.