Hi,Guys,
I have some question about high speed character physics problem,
I use changing velocity to make my character move,
(because addforce will stuck when walking on slope)
if it comes to end of up-slope or to down-slope in a little bit high speed,
it will fly off ground,
how can I keep my character always on ground,
I had think if I can not using rigidbody things,
but the game will have some moving platforms,
so, just use raycast behind character to make character position to hitpoint,
should not work.(because it will not move with platform)
so it must have rigidbody physics,
and if I use strongly gravity, when character sleeping, it will slowly skip down the slope,
that’s not expected result,
I had draw a explain image here
Please help, thanks
9:17 if the url doesn’t hold timestamp.
This might be related to your issue.
By the sounds of it, he uses some kind of trigger at the top to keep the character grounded.
Another approach is to go ahead and use a higher gravity setting but turn the gravity on and off as needed (rigidbody.useGravity). If the player is grounded and has a velocity near 0, that means he is standing still on the ground. In that case, you can turn gravity off. That way he won’t slide down slopes. If the player jumps or moves, turn the gravity back on.
even if he switched on higher gravity, the character will still jump off at high speeds.
what i can think of now is manage the character position in Y axis Manually when grounded!.
if you are using raycast to check if character is grounded, try re-position character height using hitpoint as ground position + character height / 2f.
let physics manages its position in XZ only… i dunno if this will result in any jittery… but disabling physics from Y axis alone should not cause so much issues.
thanks guys,
though this is not solve yet,
but I will try some logic
if there’s any solution, please keep reply,
thanks a lot
I agree with mangax. When the character starts, standing on flat groud, get the Y offset from the ground. Always make the Character’s Y = groundY+offsetY, unless he’s jumping or something.
OK,
So this is what I think,
If use raycast it will overlap ground when the slope is not flat,
and because the rigidbody physics, it will push character away a bit,
even worse it will still pushing if call this everyframe,
so I calculate the sphere hit point then cal back to the target we wanna it go,
just using spherecast,
but I dont actually try this yet, just think this might be work,
collider should be sphere or capsule
spherecast radius must as same as collider radius,
when character is not jump or not fall when nothing below it,
call this once,and move rigidbody to target,
then set velocity y to zero,and must be isGrounded,
the another problem is
there might be other cheaper way to calculate this thing,
because it use sqr, I think it will a little bit heavy,
hope someone can provide better method
the reason I don’t use hitpoint normal to cal back
is because, the normal may be not precise,
maybe it’s just a sphere thing like built-in sphere model
I don’t know Unity’s spherecast accuracy is enough or not
so this method might be more precise, but need be more cheaper
if you are planning to manage rigidbody height manually as we suggested…
whats so wrong (if) you placed collider at more height than simply placing it touching ground?
you don’t need your sphere to drag it self on ground… you can relay on raycast + repositioning in Y axis to place character in correct height.
look at image, with small offset for collider from ground… this way you can keep collider away from slops interaction! of course not all surfaces will be able to walk on… sharp slopes will collide with player and make it hard for player to climb, which does not break common games logic…
make mesh model legs to reach ground (so it doesn’t appear as if he is flying), while keep collider at small offset from ground.
Hey there,
Did you find proper way to solve this problem ? (Just not ramp or stairs, any kind of height like hills on terrain)
my old solution i proposed here still works like a champ… i use it personally…
Project your velocity onto the ground using Vector3.ProjectOnPlane(velocityVector, groundNormalVector)
This should solve your issue giving your character a constant speed up or down any slope without any lifting.
I’m having an odd problem when the character controller walks up slopes: it only works correctly if the slope (in this case, a ramp) is oriented along the global x-axis; but if it’s rotated 90 degrees so it’s along the z-axis, movement up the ramp is generally very slow and there are no footstep sounds (I added footsteps to the controller). This makes no sense to me, so I’m hoping someone can suggest a possible cause. I suppose I can just re-orient all ramps and staircases (which use an invisible ramp) so they face the right way, but that creates some problems.
apparently there is something wrong with your scripts.
but if your using (as an example) “vector3.right” to move a character, it will always effect along global x-axis, you need to use current object right direction, which is “transform.right”
I’m using transform.right for sidestrafing and the default Unity code for the rest (the main part of the latter is: Vector3 v = (m_Animator.deltaPosition * m_MoveSpeedMultiplier) / Time.deltaTime; )
it’s hard to tell what’s wrong without the full script that controls the character… are you rotating the character as well (the transform) to orient it toward the Z direction in world??
I’m rotating the character based on mouse input; the code for that is:
xRotation = Quaternion.AngleAxis(-_mouseAdjusted.y, targetOrientation * Vector3.right);
This does use Vector3.right (which another person thought might cause the problem), but in this case it needs to use that value to get the correct motion (I changed it to the character’s transform.right but that doesn’t solve the problem on ramps, it just messes up the process of swiveling the camera while looking around).
@HonoraryBob ahh i hate looking at quaternion scripts… makes my head spin… the vector3.right feels off…
but i generally i do not recommend the approach you are using… it’s unnecessarily complicate things…
it seems you explicitly control the movement relative to character transform orientation/direction … or world direction… in other words… the character move into a direction depending on it’s orientation or where it is facing in the world…
what i would do, is controlling the character movement without respect to it’s orientation… Simply use the position of the character , then add/subtract depending on the input direction… you just update the position where the character should go… simple and effective…
for rotation… you apply it for only “aesthetics and looks”… so depending where the character is currently heading, you update rotation so it is facing the direction currently moving towards… so even if your character started flipping or rotating around… it won’t effect the movement script.
the approach you currently using is useful for controlling space ships/ships/cars… where your ship rotation effects where your current thrust will apply forward speed… but for characters its totally not needed.
But the code doesn’t control the speed of the character while walking up a slope (which is where the problem lies) - that’s controlled by Unity’s rigidbody physics because the code just pushes the character at the same speed and then the character is slowed down by the rigidbody moving up a gradient. The problem is that the speed oddly depends on which direction the ramp is facing, which doesn’t make any sense. But it’s clearly due to the physics system, not my controller code because the latter doesn’t vary the speed. So that leaves the question of why the direction would make any difference - i.e. if a staircase is facing north the player shouldn’t move more slowly than if the staircase is facing east, but that’s what happens.
i guarantee to you that there is nothing wrong with unity’s physics engine.
you need to check how you setup your scene objects and your scripts… if you are dragging your character on ground… apply my solution that i proposed for the other guys earlier.
What could be wrong about the setup? The ramp is just a scaled quad tilted 54 degrees in the X axis; so I have no idea why rotating it around the Y axis would make any difference : the slope is still the same, the quad is still the same, and if it works while facing one direction then it should work when facing any other direction. My script just does what the default Unity third person controller does, since it was adapted from that. Again, if it works on ramps that are rotated in one direction then it should work for all directions.