Having a huge gravity value

Hey Guys,
Sorry for the unclear thread title but I did not know how to put it properly:

In my game I have many problems related to the physics and I recently started tackling them. One of those was/is that if you are running over a small step, the character starts to fly straight up. I know some CharacterControls handle this by something they call “floor clamping”, but it feels like a hack and complicates anything if you can’t handle corner cases.

Now I know that new CharacterControl(0.35f, 1.8f, 50f); might be a bit light-weight (80kg might be more appropriate?) but a) in school I learned that the mid-air-speed is irrelevant of the weight and only depends on air friction. b) You fly 10 meters if you walk from the street to the pavement, so these 30kg can’t make such a big difference.

So what is happening is that the walking impulse is transformed into the fly-impulse, however since mass is constant, the velocity should be conserved, is that maybe the problem I am facing? Rocket-Jumping with like 10m/s?

On the other hand I imagined jumping also not feeling real, so currently I have

bulletAppState.getPhysicsSpace().setGravity(new Vector3f(0f, -45f, 0f));

What is going on and/or should I just keep the gravity like that?
Is this a side effect of how physics engines work as opposed to how the real world would function?

Edit: Also worth noting that I have quite a rough walking, as the edges of the collisionshape seem to make the character stuck as well it seems.

We have that problem too :confused:

How we think it is, is that the object the agent is walking on that makes him rocket-jump acts like a slide. Because the way we usually handle a player movement is to check for his input (key press), we set his velocity directly according to that input instead of applying a force. Setting the velocity each frame ignores the friction and other environmental physical phenomenons.

2 Likes

Walking is being defined by an egg shaped collision shape. Aside from the effects you experience as a result that, walking itself is rarely perfect in any game. I haven’t delved into walking gates but I know it’s something you can’t just throw together. I guess the question is how much time you’re willing to throw at it to get it how you want.

Jumping is a result of a mass moving at a velocity in a given direction. Gravity is linear. You apply a force in a given direction which results in a velocity.

Are you setting impulses or forces when moving ? At least in Dyn4j they are wildly different ways of imposing change in velocity.

I am using BetterCharacterControl which I think applies impulses each tick.
And sure, good walking is hard to do, especially slopes and stairs however I can’t even get a basic smooth movement together currently and especially this fly bug made it hard to walk at all as you had to nearly stop before any slight elevation change or you’d fly a few seconds

That’s not entirely true. It only applies an impulse for the jump.

Here’s the documentation :

This is intended to be a replacement for the internal bullet character class.
A RigidBody with cylinder collision shape is used and its velocity is set
continuously, a ray follow_enemy is used to check if the character is on the ground.

Edit : I just thought about it, there’s the same bug in Skyrim but way less often.

Yeah, the usual issue with:

“My character feels like it’s flying over bumps…”
=the movement is being treated like a jetpack that is always on even when the feet aren’t touching the ground.

edit: also = movement speed is very high. Humans do not walk around at 3 meters per second… even though that already feels slow in a game.

“My character feels very floaty when I jump…”
=the jump is ‘game jumping’ and not real life jumping, ie: the character is able to jump a meter high or more.

If real humans could jump a meter high without crouching down first to gain momentum, we’d feel pretty floaty, too.

Also, most games set gravity to 20 and I think that’s the default in JME Bullet… even though real life is 20. In “I’m seeing the world through the monitor” scale, apparently 20 feels more realistic. At least according to game physics books.

…45 is a little extreme if all other things are being handled correctly.

I haven’t looked at the charactercontrol class but the normal of the collision point gives you the angle, doesn’t seem highly mathematical to work from there. Sin for the velocity with angleThreshold (Angle limit for walking) over angle maybe.

Have you tried throttling the angular velocity?

Well, air friction applies a force which acts on mass (F=ma), the actual resistance force is independent of mass and only dependent on shape and speed.

Okay, that’s right: (jmonkeyengine/BetterCharacterControl.java at master · jMonkeyEngine/jmonkeyengine · GitHub) However I guess that applying an impulse would also set the linear velocity after dividing by the mass and taking friction into account?

So you mean that the walkDirection shall be Vector3f.ZERO as long as there is no ground contact?
I’ve just checked the BCC Code and it does not do that, which is also why I’ve seen a Y-Component making the character fly, however I don’t have much control mid air, so I am not sure about that. I’ll see.

JME Bullet sets it to -9.81, so it’s physically accurate, but that might be part of the explanation I was seeking for.

So you would (when ground contact is existing) modify the velocity so that it is clamped to an maximum angle in y-direction?

I think this is the linear velocity here since angular velocity would be spinning around the own axis?

Yeah that’s true, because air friction does not depend on the mass where however gravity does (m * g * t = m * v). That actually tells us that higher weights fall slower! But Air Friction is not applied in bullet I guess? So I’m just curious what leads to the free-fall speed being non-inifinte

So I’ve created a video showing the problem (and the other one I don’t have a solution for yet: that characters can push each other instead of fully blocking). Unfortunately it’s been hit hard by compression, but in case any exact numbers are required I can redo any specific part.

Paul might probably say that speeds of 8m/s and 23m/s while sprinting are way off, but it gives everything a more fast paced feeling (which I should probably achieve by other things or by scaling the world actually?)

I also wonder if this also applies to cars? they’d certainly be that fast.
Oh and I don’t know why but you can see that the cross roads collision shape actually simply took all the faces used. And then it still overlaps for some unknown reason

If I remember correctly when I was testing this(I’m sure I will be corrected if wrong), I noticed the angular increases to overcome an angle, the steeper the angle, the greater the angular velocity increases so it can keep moving the object (unless you throttle it to a maximum) regardless of collision shape type.

When you get to a place where the linear velocity decreases quickly on an angle, the angular can lead to things like moving the object upwards or moving in a floating arch(depending on the situation, stopping on an angle, reaching the top of a hill, etc.) until angular drops below linear. I assume its because when angular is greater than linear, the angular difference gets applied to the y axis. I didn’t dig into it to find out exactly why it does it and the documentation is nearly zero for things like this.

After seeing your video, I think your terrains collision shape may be contributing to the problem. If you can get it to mirror the geometry, it may solve the issue. It looks like to me that the capsule shape is being ejected due to overlap.

Its hard to tell but it looks like you have two terrain collision shapes? One for intersections and one for the rest? Maybe scaling the intersections to match the corners will help.

Sure… but then you recognize that you are already waaaay unrealistic and to compensate will have to employ other unrealistic things like ground clamping or adding a large -y component to your “walk direction” (such a horrible named property since it is neither walk nor direction).

That simplifies to g * t = v which has no mass at all. This is because its well known that gravity affects all objects equally (ignoring air resistance) it terms of speed at t. (Do Heavier Objects Really Fall Faster? | WIRED) Technically the higher mass object has more inertia meaning its harder to slow down by air resistance.

You are correct that Bullet has no air friction because you do have to add it yourself.
Air resistance (in the real world) is the only force that opposes gravity in free fall, your terminal velocity is where the air resistance force and gravity are equal. (Terminal velocity - Simple English Wikipedia, the free encyclopedia)

I have a question. Are the chars moving into the air because you make them jump?

My answer was based on that they were randomly flying into the air when walking.

Edit: if it is you making them jump then try throttling the angular as I mentioned. If its to low you will hit the curb as if it was a wall.

From my thinking, the air resistance of something is advanced to the point of faking it. Think parachutes or a concave light object. They would flutter and rotate. Ouch.

I simulate air resistance the same as I do water. Generally; implement one thing at a time and see what you can get away with before recreating the matrix :stuck_out_tongue:

Okay, so I just tried to implement a fix designated to stop the glueing at a wall when you jump against it. And also I wanted to reduce the flying:

float designatedVelocity = walkDirection.mult(isOnGround() ? 1f : 0f).length();

The Problem here is: You immediately stop flying, so it feels like you have no inertia on the x/z plane.
Also when you get stuck you can’t just jump and then fly away.

Does anyone have an idea why one has no inertia? is that related to the physicsDamping value? I could imagine when walking on ground having inertia feels like walking on ice. How do others handle this problem with inertia? (I’m thinking of Source Engine Surf Maps)

Edit: Adding

existingLeftVelocity = existingLeftVelocity * (isOnGround() ? 1f : 0f) * physicsDamping;
existingForwardVelocity = existingForwardVelocity * (isOnGround() ? 1f : 0f) * physicsDamping;

indeed solves that, now I just need to find sensible values instead of 0f everywhere to let a bit air control happen.
How have you guys implemented that? (I am thinking of a separate if for the state when someone is pressing s to make him stop mid air)