stepSimulation() is a private method. You shouldn’t invoke it directly.
To simulate a single timestep of 0.01 second:
float timeStep = 0.01f;
physicsSpace.update(timeStep, 0);
2 Likes
Oh right it’s private. Thanks for the clarification! 
1 Like
Here’s a snippet that prints out the duration of each time step for debugging purposes:
physicsSpace.addTickListener(new PhysicsTickListener() {
@Override
public void prePhysicsTick(PhysicsSpace space, float timeStep) {
}
@Override
public void physicsTick(PhysicsSpace space, float t) {
System.out.println("timeStep = " + t);
}
});
Provided maxSubSteps > 0, the printed values should always be exactly equal to physicsSpace.getAccuracy(). And so far, that’s what I’m seeing, even with BulletAppState.
1 Like
I’m convinced that the sluggish movement of sio2-bullet-char-demo with Bullet is caused by a difference in how friction forces are calculated between Bullet and JBullet.
Currently sio2-bullet-char-demo uses the default value for the friction parameter, which is 0.5 for both JBullet and Bullet. When I reduce the character’s friction to 0.05, movement with Bullet becomes far more responsive.
Also… with native bullet… the native one… not jbullet… but the NATIVE one…it works fine with fixed timesteps.
As in native bullet (not jbullet) works perfectly with fixed time steps… just not with variable time steps.
So I’m not sure how that’s related to friction.
In your repo, BulletSystem is currently configured for fixed timesteps with pSpace.update(t);. To test variable timesteps, I changed that line to pSpace.update(t, 0);.
Building with jme3-bullet-3.3.2-stable (native Bullet), I see little difference in behavior between fixed timesteps and variable ones. Either way, character movement with the W key is very sluggish: about one square every 3-to-5 seconds. That’s with default friction.
When I reduce the character friction to 0.05, the character is easily able to cross multiple squares per second.
Now that I’ve actually run sio2-bullet-char-demo with jme3-jbullet, I understand better how demo is supposed to behave.
The jme3-bullet version never detects that the character is standing on anything. As a result:
- the character can never jump,
- the “Jumping” animation plays continuously (even when the character walking or at rest), and
- the character cannot easily ride on conveyors and moving platforms.
I’d like to study this further, but I’m having difficulty finding the relevant code amid the ECS abstractions. Where is the mechanism to determine what (if anything) the character is standing on?
Without looking, probably in the control driver. It receives contacts or collision events or something… which may be affected by the recent collision stuff, I guess.
…but note that the problem exists regardless of this collision issue.
I think the driver is also what decides what to do with the forces based on ground contact or not… for example, even when constantly falling (as you say is happening) there is a mode where movements will still work. I thought it was the default.
So the “constant falling” may be a red herring for the variable time step issue.
1 Like
That pointer helped. I found the CharInputDriver.addCollision() method. It’s being invoked by the collision dispatcher class in “BulletSystem.java”.
I enabled the “Standing on:” debug print statement. With jme3-jbullet, the if( us == body ) test succeeds repeatedly, but with jme3-bullet the if( us == body ) test only succeeds once. This looks a lot like the issue @zissis reported last week.
So far I’ve identified 2 incompatibilities between jme3-bullet and jme3-jbullet that affect the demo. Neither causes NaNs or a crash, and neither seems connected to the timestep size.
When you finish your sprint, I hope you’ll make an effort to reproduce the problems with jme3-bullet you’ve seen in the past.
Thanks for looking into it on my behalf.
I’m actually taking a five day weekend here as a mini-break between “hell that was” and “hell that will be” at work. Customer is jerking us around just slightly.
…but I’m trying to use this time to finish some other projects (coding, house, yard related) that are going to get neglected again soon. I’m interested in the bullet problem but it ranks four or five items down in my priorities at the moment… especially since for me there was an easy work around. (Also, I already spent 6-7 hours debugging into C++ code the last time I looked so there’s still a little PTSD from that. ;))
2 Likes
Understood. I won’t ask you to debug any C++ code. If that proves necessary, I’ll do it.
However, I can’t pursue the issues you saw until I can reproduce them.
In the interim, perhaps I should take a closer look at @cristianvillalba 's example.
1 Like