I'm having trouble understanding filtering collisions in bump.lua

[MaxGamz]

I was interested in bump.lua because it seemed like it had the best physics that the games I want to create needed; however, what has put me off about it was it's complexity. Box2D and Winfield are very simple to implement but getting bump to work on a simple platformer was almost impossible for me. I still wouldn't mind using Box2D or Winfield if I can implement them in a gameistic instead of a realistic way. I especially had trouble understanding how filtering collisions work on bump. I've read the documentation as well as followed a platformer tutorial but I'm still unable to understand how it works.

[MrFariator]

All the filters boil down to is that for each collider that you want to update, you provide a function. This function takes the currently updating collider, and the object it is colliding with as arguments. You can then resolve the collision based on the different objects' attributes or behavior (is it solid? is it an enemy? is it a pickup? is it damaging? is it an invisible cutscene trigger?), and you can make your filter behave accordingly based whatever criteria you plan for it. This is where the collision responses (slide, touch, cross, bounce) come into play. You can create your custom collision responses, but those four will generally handle most everything you'd ever need.

As such, what you wind up doing is that for each type of collider you might need to consider (player, a bullet, enemy, etc), you create different filter functions, so to finetune the collision handling to suit the given object's needs. You might want the player to cross over any pickups and collide with surfaces, while you want bullets to only collide with player or surfaces, for example.

After the relevant bump function has run its course, you'll receive a list of collisions (and the collision count). You can use this information to loop through the collisions, and do any additional handling, if desired (eg. player touching a pickup collects it and removes it from the world, a bullet colliding with a wall makes it disappear).

Do note that for the world query functions, the function you provide uses a different signature, and simply needs to return a truthy or falsey value. This is mostly used for things like doing a rectangle check, like if player is within a certain area or so.

If you don't provide a filter function, I believe bump just returns true for every detected collision (with the slide collision response if necessary). How you define any given objects' attributes for these filter functions is entirely up to you, but I tend to prefer boolean values with names like isSolid, isEnemy, isPlayer, etc., and put these boolean values in the collider objects that are stored in the bump world.

[MaxGamz]

All the filters boil down to is that for each collider that you want to update, you provide a function. This function takes the currently updating collider, and the object it is colliding with as arguments. You can then resolve the collision based on the different objects' attributes or behavior (is it solid? is it an enemy? is it a pickup? is it damaging? is it an invisible cutscene trigger?), and you can make your filter behave accordingly based whatever criteria you plan for it. This is where the collision responses (slide, touch, cross, bounce) come into play. You can create your custom collision responses, but those four will generally handle most everything you'd ever need.

As such, what you wind up doing is that for each type of collider you might need to consider (player, a bullet, enemy, etc), you create different filter functions, so to finetune the collision handling to suit the given object's needs. You might want the player to cross over any pickups and collide with surfaces, while you want bullets to only collide with player or surfaces, for example.

After the relevant bump function has run its course, you'll receive a list of collisions (and the collision count). You can use this information to loop through the collisions, and do any additional handling, if desired (eg. player touching a pickup collects it and removes it from the world, a bullet colliding with a wall makes it disappear).

Do note that for the world query functions, the function you provide uses a different signature, and simply needs to return a truthy or falsey value. This is mostly used for things like doing a rectangle check, like if player is within a certain area or so.

If you don't provide a filter function, I believe bump just returns true for every detected collision (with the slide collision response if necessary). How you define any given objects' attributes for these filter functions is entirely up to you, but I tend to prefer boolean values with names like isSolid, isEnemy, isPlayer, etc., and put these boolean values in the collider objects that are stored in the bump world.

Oh thanks! Sorry for the late response. I remember following a tutorial relating to creating a platformer using bump and when it got to filtering collisions it was the only thing I didn't understand at the time since the author never explained it. I obviously need to practice more but thank you for clearing it up for me!