Hello, I've been watching the code of jME3 alpha (quick question, should I update it frequently?) and so far I haven't found where should I put my code of the physics tick callback.
I'll explain.
I'm going to implement some steering behaviours, and for them I need to change the "Continuous Force" each tick. Ideally, I whould do that inside a "InternalTickCallback", wich is setted directly on the DynamicsWorld object, but I don't want to use directly any of those because I want to depend "only" in jME.
The other way whould be to inherit from PhysicsNode and implement "updatePhysicsState()", but I'm not sure if that is called each "tick" and, also, it's not the best way since I want to "paralelize" some of the work someday, and writting from here I have no power on that.
Very nice 
it looks just like what I wanted.
I'll download everything tomorrow, I just got back from loveparade (Duisburg) today (and I'm alive!).
Anyway, I plan to publish my game as soon as I finish it, and to make a tutorial from it, so you'll see if it worked well or it didn't 8)
Yes, updaing often is probably a good idea, theres lots of changes since alpha-1 already.
You can access all physics parameters and use all getters&setters in the "normal" update() call of the application as long as you do no or parallel mutithreading. If you do detached multithreading theres a simplePhysicsUpdate() callback in SimpleBulletApplication that you would have to use for changing physics parameters directly.
If you want to extend spatial and want to override a function to have some callback to change its location or something, thats probably not a good idea. You should implement a spatial controller to modify the spatial properties as anything else will mess up the update logic.
Hope this helps,
Normen
As my biggest problem with jME is "where the hell can I do things?", I just thought to use the build-in bulled physics.
By the way, "simplePhysicsUpdate" is not exactly what I want… well it is "most probably", but not everytime.
BulletPhysics uses a fixed timestep (of 60Hz as default). So, if you update with a tpf==0.05, he will update 3 times (each with the fixed timestep). This is made in order to prevent physics "divergence" due to inaccuracies. So, a good update should be called each "little timestamp" in order to be frame-rate independant (wich is my objective, for network sincronization, etc…), but "simplePhysicsUpdate" is called each frame, so it doesn't exactly work…
So, I really only need to change physical properties, as I don't really care avout the "graphical" representation (wich does not need to be transfered in a network, btw ^^)
Thank you very much.
Theres currently no way to get called when the "real" physicssptep is happening, only when the world is stepped. So you dont have any way to tell if you're getting interpolated values or if your applyForce methods are applied. However, it will still work like I said. If you check and apply forces every call you will definitely also check in the "right" one.
Bullet actually only calculates the interpolated values when its called before the accuracy timeframe. So calling it with tpf<accuracy is no problem. Its however important to let it step multiple times when tpf>accuracy (which is done in jme3).
Anyway, I will build a Listener interface for the PhysicsSpace internal tick so you can listen to the callback directly as well…
Hope this helps,
Normen
Edit: Added a PhysicsTickListener interface and addTickListener/removeTickListener methods to the PhysicsSpace, it would be nice if you can check out if this works for you (svn). I also made the SimpleBulletApplication.simplePhysicsUpdate() use that callback instead of being called each time the world is stepped.
atridas said:
Anyway, I plan to publish my game as soon as I finish it, and to make a tutorial from it, so you'll see if it worked well or it didn't 8)
Gotta love tutorials :D Glad you're alive :|
by the way, I navigated throught all the code and I found that this:
//sync physicsNodes
for (PhysicsNode physicsNode : physicsNodes.values()) {
physicsNode.updatePhysicsState();
}
is on com.jme3.bullet.PhysicsSpace.update(...) when I whould put it inside:
private void setTickCallback() {
final PhysicsSpace space = this;
InternalTickCallback callback = new InternalTickCallback() {
@Override
public void internalTick(DynamicsWorld dw, float f) {
//
here
for (Iterator<PhysicsTickListener> it = tickListeners.iterator(); it.hasNext();) {
PhysicsTickListener physicsTickCallback = it.next();
physicsTickCallback.physicsTick(space, f);
}
}
};
dynamicsWorld.setInternalTickCallback(callback, this);
}
Physics is a bitch (my humile opinion) :x
No, actually the physics uses MotionStates, which allow interpolated values being used when the framerate is higher than bullets accuracy. The call to updatePhysicsState() is there to sync these values, its not a physics tick callback per se.