PlayerActor setVelocityDirection


Recommended Posts



Right now, I believe the only way to control a PlayerActor is through its Controls interface. You can set to move forward, backward, left, right, etc.


However, this is somewhat restrictive if we'd like to use PlayerActor for any other form of movement scheme.


Would it be possible to add a function that gives us finer grain control such as:


setVelocityDirection(vec3 direction)

Causes the actor to move in this direction. Does not affect the actor's rotation.


It would be okay to have this method override the Controls-based control. Or, vice versa, and require users of this method to clear the Controls.


I'd very much like this functionality in the next SDK release. Should be a small quick addition :)





Michael Zhang

Link to post

setVelocityDirection(vec3 direction)



setViewDirection(vec3 direction) // Character View, not the camera's

would be great)

Link to post

Ok, we'll work on adding setVelocityDirection() function so it could be available in the next update or the one following it.

Link to post

PlayerSpectator and non-physical PlayerActor are affected by Player::setVelocity() function directly. This is a world space velocity vector. You can change it if you want.

Physical PlayerActor has internal BodyRigid which can be differently controlled by script.

Link to post

Hey Frustum,


Setting velocity directly bypasses all the built in behavior such as acceleration.

We would like to take advantage of the built in functionality of PlayerActor.


Thus, we are requesting the option of specifying an arbitrary movement direction (since Controls are limited to 8 cardinal directions).

Link to post
  • 2 weeks later...

Why not get the current player velocity, sum it up with velocity you need in the current frame and set the resulting sum for the player? That should not interfere with acceleration.

Link to post

Update: Oops, forgot to attach. Now it's attached.


Having some trouble with it.


I've attached a test case. It should be run with editor-loaded to see the Player Actor's shape capsule.


Right now, using the setVelocity, it just falls and slides along the terrain.


If you could get the following to work in this test case:


1) control direction of velocity by setVelocity

2) move along +X axis direction from start location, WITHOUT sliding (slowly ) down the slope to the right

(This is a problem I've been struggling with for a very long time...removing gravity is not a solution.)


3) stay grounded when moving from a rising slope to a flat slope.

actor.setTransform(translate(-50, -1, 10)); // line 30 replace

Replace line 30 with this, and see how when the actor goes over the first hill, it flies off the ground due to updward momentum. I'd like it to stay grounded.



Any help is appreciated, thanks.

Link to post

Friction does not change that setVelocity(vec3) doesn't modify the actor's velocity.


If you uncomment lines 27 and 28, (to enable forward controls), then, you will see the other issues about sliding down slopes due to gravity, and getting air-time when coming off slopes.

Link to post
  • 2 weeks later...

setVelocity() sets velocity to the node. When the actor is simulated physically, these transformations are ignored, because the actor is driven by a body. So you can either:

  1. Set actor.setPhysical(0); and move the player via setVelocity()
  2. Or simulate the player physically (setPhysical(1);), access its body and move the body as you want

Please check the attachment. There is no problem with physical actor behavior - it stands still on the ground and does not slide. There really seems to be an issue with sliding of non-physical actor though; will pass this bug to our devs. As a a workaround, you can use a physical actor.


Edited by manguste
Link to post

BTW, you can check how the player is handled in one of the network test world. There the behavior of the actor is handled in a custom way, without using Controls. May be it would be of help:

method move(Vec3 displacement_vector) in data/network/comon/pawn/pawn_collidable.h

Link to post

My guess is that the collision handling of the PlayerActor causes it to be "pushed" according to the normal of the slope, as opposed to upwards.


If it pushes too far, then it falls to make contact with the terrain, effectively traveling a tiny horizontal distance each time. This would create a gradual sliding effect.


Maybe you could implement another mode of gravity for PlayerActor, that disables gravity when grounded and will rest on a terrain that is detected using an intersection query with a specified terrain mask.

You could also specify a slope threshold, so that if the terrain is too far of a drop, then gravity is used.

Link to post
  • 2 weeks later...

Can I get confirmation of the alternative gravity implementation of always sticking to the ground unless jumping? Or, if a flag is set.

Link to post

Our developers are working on players right now, so gravity issue will be dealt with pretty soon.

Link to post