Hi, I think I may have over complicated my physics collision groups and wanted to hear what you guys do and how many you typically have?
In case it’s relevant I’m using Dyn4j in this case.
These are the ones I have currently:
private static final long COLLISION_CATEGORY_STATIC_BODIES = 1;
private static final long COLLISION_CATEGORY_STATIC_GRAVITY = 2;
private static final long COLLISION_CATEGORY_DYNAMICS_PLAYERS = 4;
private static final long COLLISION_CATEGORY_DYNAMICS_PROJECTILES = 8;
private static final long COLLISION_CATEGORY_DYNAMICS_MAPOBJECTS = 16;
private static final long COLLISION_CATEGORY_SENSOR_FLAGS = 32;
private static final long COLLISION_CATEGORY_STATIC_TOWERS = 64;
private static final long COLLISION_CATEGORY_DYNAMICS_MOBS = 128;
private static final long COLLISION_CATEGORY_STATIC_BASE = 256;
private static final long COLLISION_CATEGORY_SENSOR_TOWERS = 512;
private static final long COLLISION_CATEGORY_SENSOR_REPEL = 1024;
private static final long COLLISION_CATEGORY_DYNAMICS_SHIP_PROJECTILES = 2048;
private static final long COLLISION_CATEGORY_ALL = Long.MAX_VALUE;
the total bit masks are calculated afterwards. But I have a feeling I may be overcomplicating things. Would love some input.
Well, I guess we would need to understand what all of these are for. Like, why is dynamic mobs different from dynamic players or dynamic projectiles, from a physics perspective.
Why does the physics system even need to know about map objects at all?
I don’t think it really makes sense to have any if you’re not going to have separate parts of a scene that only have some specific objects interacting with them. And in that case it may be simpler and more efficient to just make a separate physics space.
Not sure about Dyn4j, but in Bullet collision groups are (i think) supposed to be used to restrict collision between objects which doesn’t really make much sense to me. They’re physics objects and their main thing is to all interact with each other. That’s why they’re there.
Perhaps optimization and per-area groups? I really really doubt that would be faster than the quadtree that already runs in the background.
tl; dr; Have tried them out briefly, ended up not using any at all.
Yeah, usually it’s enough to have “solid things” and “not solid things”… the latter of which is used for sensors and things.
the use case I mostly use collision groups for are my player characters. I want them to collide with the scene and with all the physical objects, but I don’t want them to collide with each other.
I’d like to echo what the others said, it sounds like maybe you are using collision groups to model some type of game behavior rather than what the physics engine should consider in collision calculations.
For example, players don’t collide with each other, player projectiles should not collide with each other and not with players. But then they can belong to the same collision group.
But if your use case requires more complex filters you can always implement your own Filter in Dyn4J: Filter
Having my feet wet with Dyn4j, I can tell that OP is talking about collision filters. They are 100% optional and used only to restrict the collision calculation, like: I won’t do anything with the information that object A collides with object B, so just skip it to save CPU cycles.
From what I read, it is implied that these will affect the game logic, but they really shouldn’t stomp the feet of the appropriate ES processor, otherwise expect it to bite your ass.
1 Like
Entirely correct. Thanks for the input.