Hi,
Ville, Kjell(?) could you please shortly explain the built-in ZGE algorithm for collision detection? I would like to have an optimal solution for many objects and not sure whether to implement my own solution in ZGE or to use built-in mechanism. Thanks.
Rado1.
Algorithm for collision detection
Moderator: Moderators
The built-in collision algorithm is extremely simple. Basically it works like in old 8-bit games 
Take two lists of models:
list1=all models of category 1
list2=all models of category 2
(category 1 and 2 is defined in a DefinedCollision)
for each model in list1, test against collision against every model in list 2
the actual collision test is just testing overlap of the models position expanded by the collision bounds properties
It does not attempt to predict collision based on the current velocities etc. So the most obvious problem with this is that if one model moves at a higher velocity than the other models collisionbounds, then they can run through each other without colliding.
Take two lists of models:
list1=all models of category 1
list2=all models of category 2
(category 1 and 2 is defined in a DefinedCollision)
for each model in list1, test against collision against every model in list 2
the actual collision test is just testing overlap of the models position expanded by the collision bounds properties
It does not attempt to predict collision based on the current velocities etc. So the most obvious problem with this is that if one model moves at a higher velocity than the other models collisionbounds, then they can run through each other without colliding.
Thanks Ville for the explanation which answered me some questions regarding to design of collisions. So there's no clustering of models by positions/sizes and 2-level detection (1st for bounding box, 2nd for exact shape) a la AABB, right?
Simple optimization by dynamic changing the Model.Category for objects that are temporarily excluded from (included to) collision detection will work, right?
Simple optimization by dynamic changing the Model.Category for objects that are temporarily excluded from (included to) collision detection will work, right?
Hej,
My recently posted FPS-example actually uses static collision ( circle VS grid ) as well, but i had to resort to a custom solution exactly because of those two issues. Anyway, it's not the first time i've complained about this
+ Just to be clear & complicate things at the same time .. when i say intersection i mean the "Collision" action of DefineCollision, and when i say collision i mean the "Stop" action.
K
Well, it works kind of like ( generic ) sprite VS sprite intersection / collision in 8-bit games. The solution most 8-bit games use for sprite VS environment collision isn't available in ZGE.VilleK wrote:The built-in collision algorithm is extremely simple. Basically it works like in old 8-bit games
That's not even the biggest problem. Even when considering the collision behavior is static ( opposed to dynamic / swept ), it doesn't produce the desired result ( in my opinion ).VilleK wrote:It does not attempt to predict collision based on the current velocities etc. So the most obvious problem with this is that if one model moves at a higher velocity than the other models collisionbounds, then they can run through each other without colliding.
My recently posted FPS-example actually uses static collision ( circle VS grid ) as well, but i had to resort to a custom solution exactly because of those two issues. Anyway, it's not the first time i've complained about this
+ Just to be clear & complicate things at the same time .. when i say intersection i mean the "Collision" action of DefineCollision, and when i say collision i mean the "Stop" action.
K