We Keep Coding

physics engine with multiple object groups

My java application requires a 2d physics engine for a horizontal world, however, looking at jbox2d and dyn4j, it seems that they don't offer what I need out-of-the-box. Specifically, they don't support defining which object groups can collide with others. Consider this simplified model: Bullets can collide with boxes. Planes pass through boxes, but they can collide with bullets.
How do I exclude certain groups of objects from colliding in a physics engine?

Dyn4j has the CategoryFilter. You create CategoryFilters with two longs and set those in your Fixtures. It's a little funny how the filters work because the category and mask are used in their binary forms to determine who can collide with who. To see this in practice check out this #Test from the Dyn4j repo.
Dyn4j also mentions this in the docs:
There are three Filter implementations provided, the Filter.DEFAULT_FILTER, the CategoryFilter (just like Box2D’s collision filter, int category + mask), and the TypeFilter.
So I'm assuming Box2D has this too (and jBox2d by extension). I'd say just about any physics engine at Box2D's or Dyn4j's level will have this ability in some form.

There is a solution in box2d (and jbox2d respectively).
The "PreSolve" method allows to disable a contact before colliding. See this question on gamedev which has pretty much the same problem as described here.
From documentation:
Pre-Solve Event
This is called after collision detection, but before collision resolution. This gives you a chance to disable the contact based on the current configuration. For example, you can implement a one-sided platform using this callback and calling b2Contact::SetEnabled(false). The contact will be re-enabled each time through collision processing, so you will need to disable the contact every time-step. The pre-solve event may be fired multiple times per time step per contact due to continuous collision detection.

Bx2D body Sprite synch

seeing as how box2D bodies cannot be resized, I have a problem with bodies and my animated sprites.
here's the situation which I have no doubt is not unique:
my sprite's dimensions slightly change during different motions like attacking, walking, jumping. seeing as how I was about to use box2D body for collision detection this can cause quite a problem.
so far I thought of 3 ways to solve this issue.
1- not use box2d bodies for collision detection , just use them for object's physical behavior
2- delete and recreate body before each render. or on animation change.
3- trying to recheck the collision on bodies to see if it actually collides with the sprite itself. then act.
and here's the problem I have with each of these solutions.
1- this way makes using box2d as a whole seem rather absurd, also I'll be using not one, but two world logic and trying to keep them in sync. seems like a big headache.
2- this doesn't look very optimized, also I doubt I can just make objects pop in and out of existence in a physics world without side effects.
3- I'm not sure how or even if this can be done, actually this option is the one I require more advice on. will this cause any difficulties in the long run, or cause conflicts in physics.
please let me know if there is a efficient way to solve this , or if any of the above solutions is worth working on.
my thanks
Edit:
It was more of a general question since I still don't have proper graphics for the game I'm writing, but here's my practice material:
walking waiting (standing)
attacking

A body can have multiple fixtures, so you can add all fixtures for each state to the body. If you make them zero density it should not affect the physics behavior of the body. Keep in mind though, that at least one fixture on the body should be non-zero density - you could make one fixture to act as the main fixture, which has density to give the body some mass.
If you just need to detect when these fixtures are touching something, you could make them sensor fixtures, and use your contact listener to keep track of what other things they are currently touching. The contact listener would give you callbacks about all of the fixtures regardless of which state your character is in, and for each state you would keep a list of which things the fixtures for that state are touching.
If you need the fixtures to have physical interaction but only when their state is active, you could do the above but also in BeginContact you would do contact->setEnabled(false) if the contact is for a fixture that is not currently in active state.

How handle graphical representation of objects in MVC 2D game?

I'm making a 2D game in java using the MVC pattern and after reading and searching my ass off I still haven't found a satisfying answear to how I'm supposed to handle the graphical representation of objects.
Should I divide every object, for example Player into PlayerModel (stored in Model) and PlayerView (stored in View)?
That seems kinda messy becuase then I would have to keep track of which grapical-representation-object, i.e. "ScaryMonsterEnemyView" is connected to which logical-representation-object, "ScaryMonsterEnemyModel". Is this really how I'm supposed to do it according to MVC? If so, where should this connection be stored? In the view?
I know this might be a silly problem to get stuck on, but I want to get as much as possible right from the start. Thanks for helping out :)

If I am not mistaken, you are basically asking how to split up a game into the Model-View-Controller paradigm.
Simply put, the Model is the state of your game. In O-O terms, you can think of the Model as all of the objects in your game.
The Controller is the set of rules that are applied to your game's state (in this case, all of your game objects) in every update cycle. This can be implemented as a method called update() in all of your objects, or it can be a function called in your game loop that systematically goes through all the objects that need updated and, well, updates them. You can also think of the Controller as the game loop itself. It calls everything to update, and then draws it on the screen and repeats, unless some conditions are met, then it tells the program to do something else. In this way, you almost have two nested MVC structures. One controlling the flow of the program through menus and such, and one dedicated to the game itself.
The View is just the graphical representation of your game. This can be as simple as text on a screen, but in your case it is 2D graphics. To implement this, you could have each object also contain their graphical state, either directly, or by encapsulation. The View would do little more than query all of the objects for their graphical state, and then shunt it to the screen. Again, this can be implemented on a per-object basis, such as a method called draw(), or another systematic function to be called directly from the game loop. A common practice is to create an object called 'Sptite' or something similar to hold the graphical information, and have every game object that is drawn have a personal instance. Also note that the View need not be an object unto itself. A mere function called in a game loop will suffice, although it is sometimes necessary to store information that directly effects the View's operation (like window size), in which case the View can be an object. The same goes for the Controller.
Also keep in mind that these divisions can be sectioned up even further to make life simpler. For example: The Controller can be divided up into AI processing, movements updating, and collision checking. The View could be separated into the game object display and the HUD, and the Model can be all the objects + all the state independent of the game objects (like the games settings for resolution, window size, key config and such).
I know this might be a little overkill, and it probably has extra information, but hopefully it answers your question and gives you ideas on where to start.

The Model and View are two collections/categories/domains of objects.
The controller provides a set of interfaces to perform some functions on the model objects. And if required, the view can talk directly to model objects regarding their state information.
Traditionally, The View domain corresponds to GUIs, with concepts such as Buttons, Forms, Windows etc. In a desktop environment.
Your View domain (Or one of them) will correspond to a 3D environment that you will build. (Trees, Houses, Person etc). This includes collision details, and your physics. Both of which require the geometry relating to your 3D environment.
It may be very rare in a game for any of these objects to have to collaborate with an object in another domain. But an example, consider a telephone. The object will exist in your 3D environment, but will also collaborate with another domain which describes "half-calls", "channels", "switches" etc. These objects do not belong in your View domain but in a separate Model domain.
A more relevant example maybe some sort of scoring system, such as RPG stats, which would belong in a Model domain.

Clean way to detect collision of object with box2d

I have been looking into box2d (in java with libgdx) lately and have been trying to create my own custom bounce effect (I increase the Restitution after the first bounce)
To do this as a test I simply checked the location of the object and waited for the first bounce.
But now I wanted to actually implement this and came across a problem: How to detect the collision of 2 specific object in box2d?
I found this tutorial:
box2d collision detection - but I am very reluctant to use that code. There must be a simpler and cleaner way to detect a collision between 2 objects (without having to set user data and checking all collisions with giant if() conditions...)
Can anyone help me out? (assuming I am not just hopeful and there actually is a better way)

Subclass b2ContactListener class to handle the collision and reimplement collision callbacks. Then just:
MyContactListener *listener = new MyContactListener();
myB2World->SetContactListener(listener);

And take note, some solutions don't have shortcuts as always but you can find the right solution and there is possibly a hundred ways to detect a collision and you know it, don't you? This is like in the solution of box2d collision detection program for example.
http://blog.allanbishop.com/box2d-2-1a-tutorial-%E2%80%93-part-4-collision-detection/

What's an efficient way to test if a player has clicked on one of many objects in a Java game?

This is a basic question, but since I haven't been coding Java for long I'd like to get an opinion from someone with more experience. Let's say I have a game in Java in which there are many objects (on the order of 30) on the screen. The player can click on an object and each object handles a mouse click differently.
My question is: if the player clicks on the game window, what's a good way to test if he clicked one of the objects, and if so, trigger that object's mouse click event handler?
Here's what I've come up with so far: my applet has a mouse listener and it could also have a list of all game objects currently in existence. The applet's event handler could traverse the list of objects and see if the coordinates of the click are inside that object's bounding box through something like gameObject.isInsideBBox(int mouseX, int mouseY).
This would be simple to set up, but I feel like it would be inefficient. If the number of objects is large then the program would have to traverse the list every time a user clicks. Couldn't this become a performance issue?
One alternative would be to have each object have its own MouseListener and add all the objects to some sort of global container. Would this method be more efficient in terms of performance than the above? One other concern is that these Component and Container objects seem to be defined in Java's Swing library, but I'm not using Swing for any other purposes. I have the feeling that would be a misuse of the library.
Any feedback/comments?
(I'd be interested to know if these methods would port over to Android. I realize that's a different topic, but if you have any insight on that, I'd appreciate if you could let me know.)

30 objects on screen is few enough that it shouldn't really matter much. A simple linear search should still be easily fast enough. The only real reason to consider optimizing this would be if the '30' might be way off, and you're really dealing with (say) 1000+ objects.
In that case, one simple possibility would be to sort objects by one dimension so you can do a binary search on that dimension. That should leave only a few objects to search among to find the correct value in the other direction.

As #Jerry Coffin says for a small number of objects, a linear search should be fine.
For large numbers of objects linear search scales badly.
If the objects are stationary, you can divide the screen up into a hierarchy of regions; e.g. a quadtree, and place each object into a leaf region. This allows you to reduce the number of objects you need to check.
If the objects are moving rapidly, I don't think that quadtrees would work. Every time you moved an object you'd need to recalculate its position in the quad tree, and that is expensive.
For slowly moving objects, quadtrees might work, provided that each object knows what quadtree region it is currently inside. (Check that an object is still in a region is O(1).)

each object handles a mouse click differently.
each object have its own MouseListener
Given the requirement it sounds like a good solution.

If your game objects derive from a class that implements the Shape interface, one of the conatains() methods may be sufficient. This example can handle thousands of objects using a linear search.