What happens when the maximum number of collisions or the trigger overlap capacity is reached?

Questions
#1

I have a situation like this:

imagen

Where each object is kinematic and has a trigger collisionobject to basically ‘see’ around it. There are 100 of these objects, would love to have way more. But just with these I get the “maximum number of collisions reached (64)” and “Trigger overlap capacity reached” messages.

I understand that, for a given frame, as the error says, messages will simply be lost (but with trigger contacts that enter an exit, do we lose BOTH of them or can enter be triggered but not exit?)

In any case, what is an acceptable number of maximum number of collisions and trigger overlap capacity? Even with 1024 I still get that message. Not until I raise it to 2048 I get rid of it.

But is 2048 way too large? (I guess it’s not, it’s just a big pool of collisions and triggers overlaps). If not, why is the default number apparently so low? What is a reasonable number?

These limits (and other, like sprite max count) puzzle me a bit, they seem very low by default! (just 128 sprites?). Would love to understand them, apart from Defold’s philosophy of allocating everything upfront.

1 Like
#2

The limits are relatively arbitrarily chosen. We have to choose a value and we don’t want to set too high default values but also not too low. I do agree that the default of 128 sprites is a bit on there low side, at least for some games.

Regarding collisions between large numbers of objects: i think there are some interesting learning shared from Void Scrappers here Void Scrappers post mortem

3 Likes
#3

Ah, I see. If Void Scrappers use 32k sprite limit I guess yes, the default value is quite low - and scary when you get the warning message. Same for collisions, I guess (but I am not using AABB yet, this is just me testing bonds for the nth time on a new engine) :wink: OK, given that these limits define pools, I understand I can make them much larger. RAM is the limit! :smiley:

1 Like
#4

Knowing what the current collision count is would be useful?, I guess. I don’t want to invent code development work :grin: and it is not something I would any time soon, in any case.

#5

That’s a good one! Doesn’t Defold say?

With

msg.post("@system:", "toggle_physics_debug")

we see collissions and normals. Woulb be nice to get some numeric information too :smiley:

#6

Not so much for debug, more like being able to add a callback for if limits are reached, so the game can handle them. Better to write the game so it does not happen in the first place I guess.

1 Like
#7

Makes sense.

What happens when that limit is reached with trigger enter/exit events? What if the enter message was sent, then the limit is reached, and that same gameobject exits the trigger? Will the exit message be sent?

I was trying to keep a list of nearby gameobjects with those two messages, but… unless I set a really high number, if the enter/exit messages are not sent, it won’t be reliable.

#8

The profiler will show component counts and so on, but actually not collision/contact point counts. Might be something to add? What do you think @AGulev and @JCash ?

2 Likes