JME 3.0 and 3.1(latest build)
I’m having an issue where my character control bounces on slopes after I stop applying force. If I’m moving on a flat surface and stop then everything is fine but if I move along a sloped terrain then stop the character bounces. The steeper the slope the higher the bounce. Its almost as if the physics is applying some sort of after tick to the physics space that is slamming the object into the slope.
I was told simply to adjust the capsule shape , weight and gravity but I’ve been through almost a thousand different iterations of adjustments and still the exact thing happens.
Here is a video of what happens. Notice no bouncing on the even surface , a slight bounce on the light slope then a huge bounce off the steep slopes.
If you want to see the code used refer to this thread it is literally a copy past test project - https://hub.jmonkeyengine.org/t/bettercharactercontrol-example/33767
Update 1 = Same thing happens when going down a slope instead the bounce happens when force is first applied.
Update 2 - It seems slowing the speed stops this behavior but of course then my character moves to slowly.
Could you check the TestPhysicsCharacter example, it is about 3rd person view and I uses it combined with BetterCharacterControl to do a third person chase Camera.
And why I refer to PhysicsCharacter, there is more options there regarding max slop and step height.
EDIT: for sure if you find it useful you could tweak it to act as first person camera.
Thanks , but the slope and step height have been removed in betterCharacterControl. I’m not sure why but they aren’t available. I’m trying to avoid characterControl as it should eventually be replaced with betterCharacterControl.
It looks as if the x and z impluse is cancelled but the y impulse is not. It stops horizontally but vertically it continues…
When I change the controls direction I have the Y axis restricted so no force should be applied to it.
camDir.set(cam.getDirection()).multLocal(speed, 0.0f, speed);
Unless I am missing something else.
@jojoofu the best way to have a character control that fit your needs is to override the prePhysicsTick method from BetterCharcherControl.
adding this elseif statement fixed the bouncing effect for me :
if (designatedVelocity > 0) {
// . . .
} else if (isOnGround()) {
velocity.setY(0);
}
i also added few lines to prevent from controlling the character when in air :
adding the if isOnGround statement
if (isOnGround()) {
rigidBody.setLinearVelocity(velocity);
if (jump) {
// . . .
}
}
I think i will end with a text that i will copy and past everytime a problem related to this occurs (i.e.: often).
BetterCharacterControl is a way to control your character that is physic-based, i.e. your character is a physical object with a mass, which can receive force and push objects.
CharacterControl is a kinematic controller, i.e. you are not movable by forces, you can’t move objects etc.
From this point of view, BetterCharacterControl could appears to be, well, better.
However, if you look at this https://www.digitalrune.com/Blog/Post/1675/Kinematic-vs-Dynamic-Character-Controllers you’ll get why it’s not that obvious.
Especially the section “Which solution is better?” and the sub-item of this section: “Undesired Jumps”
Also, the code of the charactercontrol is available. Even if someday this controller is removed from the code you’ll be able to copy and past it somewhere in your application and, minus some “import” that you’ll need to change, you’ll be ok. Note that you can even solve these import by NOT using charactercontrol directly but by just extending it and use your class everywhere instead of using CharacterControl directly. You can even, if you do that, easily swap from bettercharactercontrol to charactercontrol (and swap back) and make this swap totally transparent for the rest of your code.
@bubuche I agree the control needs improvement. However , they are working on it. I’ve seen several request at the gitHub depository for fixes. I think it is slowly improving. If you see any bugs please report them at the gitHub.
Unfortunately my issues I don’t think is an actual bug. It looks like the physics is applying the upward force as I traverse the slope as it should. What I need is a solid way to completely stop the force along the Y axis with out interrupting jumps.
@Dokthar Thanks for the help. This is very similar to what I was doing before. However if you do use this method the isOnGround function is slightly off and will cause you stop before you touch the ground.
I’m going to experiment with some raycast is see if I can’t get closer to the ground doing the test myself.
I have seen bugs and i reported them, with little to no effect. Attempt to fix bettercharactercontrol is like attempt to fix your wall made of cookies. You can paint it to protect it against water, make the roof lighter, put nails into cookies to prevent them from sliding … but the paint will not stay, your roof will always be too heavy and the nails will break cookies instead of fix them.
Translated back in our problem: you’ll just spend your time fighting against the physic engine to remove everything it does, and it will end with something buggy and slow that will break as soon as you’ll try to use it in a real application.
Hell, bettercharactercontrol is even not able to climb a stairs.
Last time i checked i was able to jump in a ghostcontrol (and jump very high as the onground returned true every tick, applying the jump force every tick).
A physic controller make perfectly sense for a car, where we want drift and jump when we arrive at full speed on the top of a hill. We want these “artifacts” and it would be akward without them.
But for a character we don’t want them, at all. We want to be able to walk at a pretty high speed and then stop instantly etc. (everything is listed on the link i posted).
A solution to the problem would be to look at how professional game engines does this and stop think that the control of a character is a more or less trivial problem that can be solved with two join and a ball. Maybe that the code of openarena will be usefull, for example.