Integrating JMEPhysics2 with existing Node

Not sure if I'm missing something incredibly obvious, but I'm stumped.

I'm trying to add JMEPhysics2 to a simple game. Currently I have a GameObject class which is a descendant of Node, and combines a number of child nodes into one with attached game logic. For instance, I have attached geometries, SoundNodes, etc.

I'm experiencing a problem when I add physics into the equation, however. I attach a DynamicPhysicsNode to the parent node, and not only does the parent node not move, but my geometries vanish. I can only assume that the geometries are being moved by gravity, but because the physics node is a child of the GameObject node, that GameObject isn't going along for the ride as its coordinates don't change.

Is this correct? Does moving a child node not update the properties of its parent? If not, is there some way to indicate that a specific child node's movements are to take the parent along? Or should I write a controller that syncs the parent node's properties with those of its child physics node?

Or is there some better way to achieve this–creating a single Node class with accompanying game logic that works with JMEPhysics2?

If you want to have something moved by physics it should be a child of the physics node. The scenegraph propagates transform from the root to the leafs of the scenegraph not the other way round. In general I would not recommend that your GameObjects subclass any Spatial. But if you don't want to change that any more you have these options:

  1. Make the DynamicPhysicsNode the parent and attach your GameObject, then position the physics node (not the game object) if you want to change location of your game object


    2.write a controller that updates the physics node from the game object and vice versa (like you already suggested) - you would have to figure out a clever way how to decide wether the GameObject or the PhysicsNode should be updated

What would you recommend, then? I was using the flagrush tutorial as a guide. Is there some other, more preferred way of encapsulating all the nodes and logic related to a game object? Should I just have a standard Java object that stores a handle to a node, then perform all my actions on the node itself?

thewordnerd said:

Should I just have a standard Java object that stores a handle to a node, then perform all my actions on the node itself?

Yes I would prefer that. It would be possible to have proper Model/View/Controller separation then. What Mojomonk proposes in the tutorials gives you a quicker start, I'd say.

Ok, I suppose I can see that perspective. Further investigation of the controller approach seems to be hinting at other complications which I'm not sure how to resolve, so I'll look into redoing things that way and see what that entails.

This isn't physics-related, but perhaps I'll ask anyway. If I separate my game objects into a plain Object that holds the node and associated data, how do I map back from the node to the object? So, for instance, I'm writing an Asteroids-like game and one of the geometries representing an asteroid collides with a geometry representing a weapon shot. How do I map back from the geometry/node to the object instance that stores the game logic and properties associated with that particular geometry's object? Before I could have accessed those properties on the parent node object, but I'm not sure how to go about that with this other model.

the common way to do this is maintaining a Map from Spatial (key) to your game object class (value). For example in your GameObject class do

private static Map<Spatial,GameObject> spatialMap = new HashMap<Spatial,GameObject>();

private Spatial spatial;

public void setSpatial( Spatial theSpatialAssociatedWithThisGameObject ) {

I think it's a good idea to add this to the documentation of jME/jME Physics or maybe add a tutorial to jME Physics. I'm struggeling with the samen problem. Maybe that's the reason why the Chase Camera isn't working for me.