Redesigned jmePhysics and OdeSpace.update() / PhysicsUpdateCallback()

Hi

We are testing some Physicimplementations, and the redesigned jmePhyics too.



We are using the PhysicsUpdateCallback and its methods for a trigger system in our game.

If there is a collision in the callback's afterUpdate-method with the observed PhysicsNode we do the gameLogic.

(eg. The trigger observes a "rocket", if it hits the trigger will apply the damage to the object that was hit)



For getting the last collisions we call space.getLastContactInfos(). But this seems to always return null.



Then we've found a interesting point at OdePhysicsSpace.java in update():

you do the follwing:

lastCollisions = null;

updateCalbacksBeforeUpdate / step

collide() <- The Collisions are stored in a temporary variable called results

…

updateallBackAfterUpdate / step

lastCollisions = results;

return lastCollisions;



This way the updateallBacksBefore(After)Update / step methods can never get the lastCollisions - they will be null at every time, because the getter returns lastContactInfos.



Is this wanted, and when yes, why?

Or do i miss something?



Snare

Great you are already experimenting with it - I hope you like it :smiley: - it's not yet finished…



The PhysicsUpdateCallback still has to be reworked. It's not very nice with the distinction between step and whole update, but the current ode implementation needs it. Same goes for the collision results. I'm not even sure what the update callback should be really used for and what should not be done in the callback but in the game loop.



I think it would be best to remove the beforeUpdate and afterUpdate methods from the physics callback and put that stuff into the game loop instead (e.g. SimplePhysicsGame).



In your case - as you use afterUpdate only - simply put your trigger code into the simpleUpdate method and everything should be fine.



Thanks for testing the new jME Physics :slight_smile:

Yes i like it. Your programming style is very good.  :slight_smile:



Removing these after / before methods result in removing the Callbackclass?



We think there is still a reason for callback possibilities for callbacks in physics.

Now our gameobject part is designed as follows:

The Gamobject, which has gamespecific data like health etc., is a node in the jme tree.

It has a physicsnode attached, and this physics node the graphical node. (As in your class diagrams)



The gameobject also holds a TriggerObject, which has a ( beanshell )script with gamelogic for collisions.



In the gameloop, we wanted to get the collisions, and through the physicsNode the GameObjects with its triggers.

Getting the physicsObject with collisioninfo.getNode1() then, the gameObject with node1().getParent() - but this is an inflexible approach,

eg if we want the physicsNode to refere to a nother GameObject then it is attached, or the parent

of the physicsNode is not a GameObject.



Our first thought was to subclass the PhysicsNode - this isn't possible because of the physics design.

The second thought was, if there were a kind of a callback possibility, it would be much better.

like "Object physicsNode.getUserObject()". In this way, u can attach a selfdefined object to the physics node, and if there is a collision,

you can get this and execute gamelogic and so on. In our design, the userObject is the gameObject.







Is this a good way to solve these problems, or are there better ways to implement gamelogics?








snareoj said:

Yes i like it. Your programming style is very good.  :)

Cool 8)

Removing these after / before methods result in removing the Callbackclass?

no, before/afterStep would remain (if I can't eliminate the need for it, that is)


Our first thought was to subclass the PhysicsNode - this isn't possible because of the physics design.

true

The second thought was, if there were a kind of a callback possibility, it would be much better.

also true, I'm thinking about collision events for which you can subscribe like input event or similar - havn't started that part yet...


like "Object physicsNode.getUserObject()". In this way, u can attach a selfdefined object to the physics node,

I'm hesitating to add such a field as there will be situations where more than one piece of code will try to set that user object - which stop them from working properly if both are used... a set of user objects is expensive and not easy to handle for the app...
Don't hesitate to use a HashMap instead - as long as you don't change the links to user objects (game objects) often it is really efficient.

So to start right off use your own HashMap for mapping PhysicsNode to GameObject and expect much better API support of collisions in the long run :)

Thanks irrisor!



Didnt think of that solution with a Hashmap.  :slight_smile: