Hallo,
I have changed the way to handle contacts once more. Sorry, please dont kill me, but i do have a reason! Can you please lower your knife? :?
The previous’s previous version (contactAction) was wrong, because it called two methods when it only needed to call it once. So that was taken care of by ContactPair. However, as most of you probably have become accustomed to and very annoyed with, it doesn’t allow for two contact pairs on the same object. Which frankly again kinda stinks like kangaroo faeces!
So now, what we have is a good and clean interface to things. Its a single interface called “PhysicsCallBack”. This basically has two methods:
onContact(PhysicsObject, PhysicsObject, Contact)
This will be called upon every contact generated by ode. Meaning more than 1 contact per object collided. Just do alot of if statements there to determine what the contacts should be. This is now demonstrated in the GDC test.
defaultContact(Contact)
This will be called when no contact information has been set from your previous if/else statements. This is a good place to put general information. I.e. have low friction everywhere if the simulation is like the moon.
If both of the above fail, i.e. you cant be bothered to even create a PhysicsCallBack interface, it will fall back to the inbuild default.
This pleases all sides (the ones that kept on harrasing me to do something. Yes, im going to be calling the police on you!), so it should be fairly flexible.
Whatever changes now will build ontop of this, because i firmly believe this is a good change!
Oh yer, one last thing, on your update method, you know have another paramter which is the call back. If your game doesn’t use any of the fancy contact stuff, just put null there and it will work fine. 
DP
Mmmk… if I get this right those two methods will define all contact logic for all PhysicsObjects…
Wouldn’t PhysicsContactManager or something be a more intuitive name?
the same really, its just a name. I called it callback because its going to be called whenever a contact occurs. Calling it a manager assumes it can’t be extendable, is static/ or singelton.
P.S. Im having trouble committing, i’l commit it when it lets me
Edit:Commited!
DP
Another thing I don’t understand is why it’s provided through the update method, and not via a getter/setter in PhysicsWorld?
that can be changed…it doesn’t really matter.
this way, the physics system doesn’t hold a reference to the object…
dp
I dont get it …
The old method was to create a ContactAction and "register" it with a certain PhysicsObject (donw via super Constructor).
Now i cant use that anymore, cause ContactAction is gone, and there is that new interface, but how do i "register" a PhysicsCallBack implementation with a PhysicsObject ? Who has to implement it ?
jmextest.physics.contact.PhysicsCollisionResultTest is not very helpful, cause it only polls all Contacts worldwide, every round.
It would be helpful to have the inreasing/decreasing of points beeing realised by a PhysicsCallBack-Implementation (or do i get it all wrong ?).
Mr.Maxx
You implement your own PhysicsCallBack by implementing the interface and defining the methods. See the GDCDemo for an example.
To set the call back, simply do:
PhysicsWorld.getInstance().setPhysicsCallBack(callBack);
And your done..
DP
DarkProphet said:
You implement your own PhysicsCallBack by implementing the interface and defining the methods. See the GDCDemo for an example.
Where is GDCDemo? in CVS i don't find it!
That's probably because this topic is almost 3 years old! :-o
ehm…i'm sorry.
I have finded by search function PhysicsCallBack
Gentleman Hal said:
That's probably because this topic is almost 3 years old! :-o
exactly - and it was in jmephysics 0.4 (current is jME Physics 2.1)