Inconsistency in physic world

Ok, i just found another “bug” and i can’t find any topic related to it.
This time, i also found the source of the problem.

The “bug” is : when you have a charactercontrol that fall without jumping (like someone who walk and fall) the falling speed has no link with the gravity.

I can provide a test case. But it’s simple enough to imagine : just add a box in your world, set the stepHeight (this is the problem ^^) at 0.5f or greater and the gravity at whatever you want and you’ll see that when you reach the border you fall very quickly (even if the gravity is very low). If you jump, you don’t have the problem.

I think that the problem come from the class KinematicCharacterController (like often) in the method stepDown where you have (in the first lines of the method):

[java]
float additionalDownStep = (wasOnGround /&& !onGround()/) ? stepHeight : 0.0f;
Vector3f step_drop = Stack.alloc(Vector3f.class);
step_drop.scale(currentStepOffset + additionalDownStep, getUpAxisDirections()[upAxis]);
float downVelocity = (additionalDownStep == 0.0f && verticalVelocity<0.0f?-verticalVelocity:0.0f) * dt;
Vector3f gravity_drop = Stack.alloc(Vector3f.class);
gravity_drop.scale(downVelocity, getUpAxisDirections()[upAxis]);
targetPosition.sub(step_drop);
targetPosition.sub(gravity_drop);

[/java]
This is the problem. It took me some time to find it.
The problem is jusr really here:

step_drop.scale(currentStepOffset + additionalDownStep, getUpAxisDirections()[upAxis]);

I used some reflective tools and i found that currentStepOffset is always at the value of stepHeight (at least during the fall).
This is a problem : each frame, we perform this, so each frame we use a constant value to move the object.
In my mind, this should be replace by something like

step_drop.scale( (currentStepOffset * tpf) + additionalDownStep, getUpAxisDirections()[upAxis]);

I may be wrong.

We won’t make any changes to the character class as its coming from bullet like this and the class you posted will be native bullet code from the next versions on. You can check if this behavior is different in native bullet.

I can also confirm that i get the same issues with the chractercontrol free falling in jbullet.

i duplicated the code of the three class (charactercontrol, physicscharacter & kinematiccharactercontrol) and made the changement i said. Actually, if i remove the part "currentStepOffset + " the bug is not here any longer and i the falling is smooth (as normal).

Don’t be so agressive normen : i try to bring as much feedback as possible, and i try to find solutions. Yeah, i am really disappointed by jbullet, but almost all my problems are related to the charactercontrol class. I know that for the devs this class is harder to do as they don’t have any “physic” support (they don’t have the work of millions of physicians) but for me it’s really a big problem every time i have to deal with it.
This class is suppose to be the “main” class when you do a game with a character in it. For this reason, it’s very important to have a nice and extremly reliable class here.
The bug i am talking here has the effect that you won’t fall at the same speed if your framerate is lower. Yeah, every frame you just add a value that doesn’t care of the dt
But now it’s ok for me, with this duplication of the code. Sad i had to do it. Now, i meet an other problem : it seems that it’s not possible to put 2 physic controller on the same object as each controller keep internally the last position and use it to perform the new position. They should use the current position, so 2 different controller would be able to move the object at the same time.
No, they don’t do that. Maybe i am not suppose to do move an object with 2 different controllers.
Actually, i think i can achieve what i want by adding an element that will just report any move made by a controller to all the remaining controllers and this each frame and between each controller.
so, if i have A B C D E i do :
A do its stuff. I call a setPhysicLocation (or equivalent) to B C D E
B do its stuff. I call a setPhysicLocation to C D E
C do its stuff. I call a setPhysicLocation to D E
etc.
I can do that, but it’s really boring and i shouldn’t have to do it. There should be an item with the data like rotation, rotationSpeed, position etc that all controllers would change. Clean.

To come back to the topic, i think i’ll try to make an as clean as possible kinematiccharactercontroller (including non-y-oriented gravity and no warp bug with negative gravity) and release it.

:? I am not aggressive, I only inform you about these facts. Theres not much point in doing this debugging here and now as we won’t change the jbullet library anymore and only changes to native bullet would be relevant to jME. You should probably tell the bullet developers if thats so in bullet too. As for the bullet character, its definitely got some flaws and whatnot but I’d personally not use it for a complete game anyway but instead create my own. Its nice to test stuff though.