[SOLVED] Differentiating between different types of Box2D bodies in LibGDX

Newbie & Debugging Questions
#1

Hello everyone, new here.

My question is simple: I have a game where there are different types of bodies. Some are enemies, some are terrain, some are friends, etc. The structure of my code with regards to this is different classes for the enemies, the player, etc, all of which store a body they refer to. When this body is created, it takes information from these classes and uses that to change itself, and then returns itself to the class for use later. This works out fine and dandy, until things collide.

I need to figure out what types objects are when they collide, but I’m only able to get a body. The bodies are unable to tell which entity they associate with, only the other way around. How would I go about solving this? I’m aware of UserData, but I already store a texture there for use by another library. It requires that the texture be there. Is there any other way to store multiple objects in a body’s userdata?

Thanks for any help.

Edit: at work right now so I can’t test this, but the thought just occurred to me–since it’s possible to attach multiple fixtures to a body, would I be able to place a different object of userData in each of them?

#2

There are multiple ways to do this. The easiest way would be to user the user data property for the body. You could create an EntityType enum and then simply set the values as user data, if you only need the types:


//Set the user object
body.setUserData(EntityType.Enemy);

//check the user object
if(EntityType.Enemy.equals(body.getUserData())){
    foo();
}

Have a look at this tutorial: http://www.aurelienribon.com/blog/2011/07/box2d-tutorial-collision-filtering/ . It explains what filter groups are. Maybe this could be also useful for you. Definitely worth checking out.

#3

He just explained that some gfx lib is claiming this userdata field :persecutioncomplex:

#4

I just have been informed that I should read a bit better next time…

You could create a hashset for each entity type and register the bodies on creation in that set. Or use a HashMap with the body as key and your entity as the value.

Indeed. Must have have missed that whole paragraph ::slight_smile: Time to go to sleep…

#5

Heh, thanks for the suggestion anyways. :slight_smile: So the HashMap sounds like something I might need to do, though I’m a little fuzzy about where I’d store this such that every projectile or body-ob-body collision would be able to access it. Would I need to make it basically a global variable? Also, performance-wise, would this have any negative effects I should know about, or are HashMaps really O(1) lookup? And finally, was what I suggested possible at all? Namely, would it be possible to attach multiple fixtures to a body, each containing its own userData, and store the entityType in one of those, with the texture in another?

Thanks for all of the input so far.

#6

I don’t know how you handle your collisions, so I can’t say much about how you could do it (maybe explain how you setup your resolution or provide some code).

About your suggestion. You can attach multiple fixtures to a body, but as far as I know you can only attach one user data object per body, so I think that your approach won’t work.

In my game I too need to check what bodies have collided. I have an event queue where I can push events on to, if I found a collision that needs to be handled by one of the game systems. For this I created an implementation of the ContactListener class. In there I check the entity types of the bodies. If I find a combination of entity types that I need to handle, I simply put them into the queue. No need for global variables, as I supplied the event queue in the constructor of my ContactListener implementation.

I have put up the (stripped down) code of my implemenation: https://gist.github.com/tomvangreen/04b8d13941b9e5c3bd0f
My code is a bit special (let’s call it ugly :wink: ). Also my solution is by all means not optimized. There are some things I could do to improve, but currently it is out of scope for me and as long as performance is no issue I won’t bother changing it :wink: I hope this gives you an idea on how you could do this.

#7

Thanks for the code example, it definitely gave some helpful insight into how I might find a solution to my own problem here. However, it does look like you’re still using the UserData field in a way I can’t…I’ll see about implementing the HashMap idea though.

#8

Wow, solved this entire problem in the simplest of ways. Though each fixture’s userData field is being used by the rendering library, every body as a whole has its own userData field! I simply put my entity type in here like one normally would. :slight_smile:

Thanks for all of the help.