Filters - Am I doing something horribly wrong?

Physics
#1

For my game, I need an invisible “ceiling” that only collides with one type of object.   I figure collision filters were the way to go, and I think that’s right - just make that ceiling have a mask indicating the one object that it can collide with.

So far, so good.

When I opened up the Physics Editor, however, I realized that every one of my objects has the first category bit selected and all mask bits selected.   I guess that’s the PE default.   I don’t think it’s a problem since to date, all objects *can* collide with one another in my game.

Or is it a problem?   Should all physics objects have a category bit of 1?   That doesn’t seem right.   If they should be unique, what if I have more than 16 objects with physics bodies defined (hint:  I do)?

#2

Hi @davemikesell,

I haven’t seen your game logic, but your physics objects should not all have category bit 1. This is probably a default of PE, but it’s not meant to remain that way.

I assume you followed the tutorial that I wrote some time ago on this?

http://forums.coronalabs.com/topic/2128-collision-filters-helper-chart/

The idea is not that you apply a separate collision filter to every physics object. Instead, you need to create “groups” of objects that collide or don’t collide with each other. A collision filter should be applied to all objects of that type. The “category bit” value should actually be unique for each group, never duplicated.

I suppose it’s possible that a very complex game could have more than 16 unique collision filters, but it’s rather unlikely since you can do alot with just a few collision groups. In a game I designed, there was a considerable amount of collisions occurring, and I ended up using just 6 collision groups by the end.

Anyway, if you didn’t follow through the entire tutorial, please do so. It should help you figure this out pretty quickly.

Hope this helps,

Brent

#3

Thanks, Brent - I read that yesterday.   I have one main display group where all the objects reside, and they can all collide with one another.    The object of the game is to flick ice cubes into glasses of different sizes and shapes (each with its own physics body), which are placed on stacked rocks of different sizes/shapes/materials (each with its own physics body), which are stacked on the terrain (another physics body).   

Right now, I have 18 distinct rock shapes that require different physics bodies (6 stone, 6 ice, 6 snow).   May add more, 6 at a time (there are 6 different shapes of each, and each surface has a different bounce/density/friction setting).   I only have four distinct glasses now, but I want at least ten before I release it.    Probably five or so different cube types.   

I’ll try grouping all rocks in one category, all glasses, all cubes…

#4

OK, sounds like a plan. Also remember that if your game scenario ends up exceeding 16 distinct collision filter groups, you can then use pre-collision “physicsContact” handling that would give you essentially unlimited control. This tells the collision system to consider a collision before it actually happens, and you can then choose to either ignore the collision entirely (based on your game logic, labels you apply to the objects, etc.), and also change the friction and bounce parameters of the collision on a per-collision basis, overriding the values that are set on the object as a whole. You probably won’t need to go to that length, but I just wanted to mention that it’s available if you need it. :slight_smile:

Brent

#5

Hi @davemikesell,

I haven’t seen your game logic, but your physics objects should not all have category bit 1. This is probably a default of PE, but it’s not meant to remain that way.

I assume you followed the tutorial that I wrote some time ago on this?

http://forums.coronalabs.com/topic/2128-collision-filters-helper-chart/

The idea is not that you apply a separate collision filter to every physics object. Instead, you need to create “groups” of objects that collide or don’t collide with each other. A collision filter should be applied to all objects of that type. The “category bit” value should actually be unique for each group, never duplicated.

I suppose it’s possible that a very complex game could have more than 16 unique collision filters, but it’s rather unlikely since you can do alot with just a few collision groups. In a game I designed, there was a considerable amount of collisions occurring, and I ended up using just 6 collision groups by the end.

Anyway, if you didn’t follow through the entire tutorial, please do so. It should help you figure this out pretty quickly.

Hope this helps,

Brent

#6

Thanks, Brent - I read that yesterday.   I have one main display group where all the objects reside, and they can all collide with one another.    The object of the game is to flick ice cubes into glasses of different sizes and shapes (each with its own physics body), which are placed on stacked rocks of different sizes/shapes/materials (each with its own physics body), which are stacked on the terrain (another physics body).   

Right now, I have 18 distinct rock shapes that require different physics bodies (6 stone, 6 ice, 6 snow).   May add more, 6 at a time (there are 6 different shapes of each, and each surface has a different bounce/density/friction setting).   I only have four distinct glasses now, but I want at least ten before I release it.    Probably five or so different cube types.   

I’ll try grouping all rocks in one category, all glasses, all cubes…

#7

OK, sounds like a plan. Also remember that if your game scenario ends up exceeding 16 distinct collision filter groups, you can then use pre-collision “physicsContact” handling that would give you essentially unlimited control. This tells the collision system to consider a collision before it actually happens, and you can then choose to either ignore the collision entirely (based on your game logic, labels you apply to the objects, etc.), and also change the friction and bounce parameters of the collision on a per-collision basis, overriding the values that are set on the object as a whole. You probably won’t need to go to that length, but I just wanted to mention that it’s available if you need it. :slight_smile:

Brent