Turn asix to change direction

I have to turn axis of my player to change his direction.
How to do it?
Easy please, I’m noob.


you should post more information. I guess you use a PxController for your player.
There are 2 common types: PxCapsule or PxBox - Controller.

The PxController isn´t designed to rotate - its an kinematic actor which only moves
with the controller->move(…) function - even gravity doesnt affect it.
(For gravitiy, you need to code it and move the controller)

But you want to rotate your PxController.
Usually you rotate your mesh (player model) to the point of the walk direction.
Thus you need to calculate the walk direction of your PxController and the mesh.

The mesh have his own axis - the -z axis usually to move forward.
You need to rotate your player to the desired direction (usually y axis), and get the new z and x values. These values must be multipled by the desired velocity.
I didnt use any y changes in the mTranslate, so I set them to 0.
You must normalise the vector.

Something like this:
//mTranslate is a Vector3 - in PhysX: PxVec3
mTranslate = -mVelocity.z * mMeshNode->getOrientation().zAxis();
mTranslate += -mVelocity.x * mMeshNode->getOrientation().xAxis();
mTranslate.y = 0.f;

And move your controller like this:

Of course, you must change the code to your needs.

This is the way how the controller should move.
You need to set your orientation of your mesh along the mTranslate vector.
The mesh rotates inside the PxController - no need to rotate the PxController.
(Only when you are using the PxBoxController - the edges of the box could be a problem in some cases.)
The PxController (should) never rotate - look into the PhysXGuide.

Due to the fact that the PxController contains an “usually” PxActor, you could rotate
it manually - here is my post how you could do it.


But this is not recommended! (Reasons: look into the post)

Thanks you very much!

But for Player I used usual actor. I cooked convexmesh from my .x file.
My Player is a space ship, box or capsule is not suitable for it.

For move I used SetLineralVelocity.

And I use old version of PhysX (2.8).

You are welcome.

First: Why do you use PhysX 2.8.x ?
The newer PhysX 3.2.x is in many points better - (but it doesent have some features yet).


I´m not familiar with PhysX 2.x - but I guess the best way to implement the desired behaivor is to
raise a kinematic flag for your actor. (Or to use a kinematic actor - I dont know 2.x )

With the kinematic actor, you can move it without appling forces - you just set the destination offset (or delta move) - but you have to call it repeatly to move it.

I guess you can set the orientation - directly to the desired one -
or set an angular force for it. Just test it or look into the PhysXGuide 2.8x.

Yes. But kinematic actors does not collide with static…
And when I move kinematic actor it get wrong position.

When I set position on (0,0,0)
I get -0.0002, 0.9,0.3;

Why? I don’t know…

And I use 2.8 just because I don’t know how to apply 3.2 to my project.

I guess PhysX 2.x have also static vs kinematic collisions.
In PhysX 3.x you have to raise sceneDesc.flags =| PxSceneFlag::eENABLE_KINEMATIC_STATIC_PAIRS;
to enable static vs kinematic collisions.

This is an important flag - and I think PhysX 2.x have it too.
Think about a large level mesh - it wont be kinematic or even dynmaic because it never moves
or rotate. Thus it will be static (and for optimizing reasons).
And you will have a PxController which moves around on it - it need collisions there.
(When I remember correctly, Borderlands 1 uses PhysX 2.x - this is the scenario I explained above)

There is a migration guide inside the PhysXGuide 3.x.
Okay you must rewrite a little bit of your code, but … when you compare which features and bug fixes
Physx 3.x have - and improvments - you would like it.

(And PhysX 3.3 is comming too…)
-> The Step from 2.x to 3.x takes a little time, but its worth.
I think from 3.2.4 to 3.3 wouldnt be so hard. :)

Look here as a little reference for performance:

The position error could happend due to scaling / offset values.
(Or floating point errors? - but there are to high for it)

But as I said before, I dont know PhysX 2.x - so Im only guessing.
If you dont have much different actors / algorithm / NxForceField or what ever
(or are almost done with your game), I would
recommend everyone to change to the newer PhysX 3.x - even when PhysX 2.x receives updates.

Okay, when I use two commands together it’s working correct.


But I still have not collisions with static shapes. My player is a kinematic now and all levels is a static triangle meshes.

I heard PhysX 3.2 have not this problem?
Or do you know how to solve it?


I really dont know PhysX 2.x (I used it for a long time ago)

  • so I´m guessing that kinematic vs static is possible.
    But when I remebmer correctly, I´ve used kinematic vs static collisions.
    Kinematic vs static makes in my eyes sense - read the Borderlands example above.

PhysX 3.x doesnt have this problem - I use 3.2.4 - and everything work as expected.
I dont have my old code of PhysX 2.x - so I cant help you here.
Just google a little bit - or look into the PhysXGuide or look into the
SceneFlags - which you set when you create your scene.
Another way is to change your code to PhysX 3.x - when possible.

I´ve changed my whole project to PhysX 3.x long time ago.
It has taken time, of course, but the benefits have justified it.

There must be a sample in PhysX 2.x - look into the PhysX Sample folder.
–> Now you have to dig into the code - or test the samples.
I think there will be a sample which uses static vs kinematic collisions.

(Look at a cooked mesh - which uses a controller for the player)
I think there is a sample like this.

That right, but when I use a kinematic mesh, I change coords. And what will be when I pose my player into a wall?

Its a little hard for me to understand what you wrote.

I dont know what do you want to say with your last post.

I guess you want to say something like this:

When I´m using a kinematic actor I move it via moveGlobalPosition - thus I set the desired position offset manually. What will happen if I´m touching a wall and set the new position inside the wall?

I dont know if moveGlobalPosition is the right method to move kinematic actors -
but it doesnt sounds like you set the global position. ( which doesnt checks possible collisions )

I guess moveGlobalPosition will check against possible collisions (and static) - and wont
move your actor when a static mesh is between your desired position.

But to be sure - you have to read the PhysXGuide - or look into the samples.
Oh wait - I´ve download it and found this:

virtual void NxActor::moveGlobalPosition  ( const NxVec3 &  vec  )  [pure virtual] 

The moveGlobal* calls serve to move kinematically controlled dynamic actors through the game world. 

See moveGlobalPose() for more information.

Sleeping: This call wakes the actor if it is sleeping.

[in]  vec  The desired position for the kinematic actor, in the global frame. Range: position vector 

virtual void NxActor::moveGlobalPose  ( const NxMat34 &  mat  )  [pure virtual] 

The moveGlobal* calls serve to move kinematically controlled dynamic actors through the game world. 

You set a dynamic actor to be kinematic using the NX_BF_KINEMATIC body flag, used either in the NxBodyDesc or with raiseBodyFlag().

The move command will result in a velocity that, when successfully carried out (i.e. the motion is not blocked due to joints or collisions) inside run*(), will move the body into the desired pose. After the move is carried out during a single time step, the velocity is returned to zero. Thus, you must continuously call this in every time step for kinematic actors so that they move along a path.

These functions simply store the move destination until run*() is called, so consecutive calls will simply overwrite the stored target variable.

Note that in the future we will provide a mechanism for the motion to be blocked in certain cases (such as when a box jams in an automatic door), but currently the motion is always fully carried out.

Sleeping: This call wakes the actor if it is sleeping.

[in]  mat  The desired pose for the kinematic actor, in the global frame. Range: rigid body transform.

Did you see it? Its easy to read all important things in the docs. ( Took lesser than 30 seconds to find it)

Thus the usage of moveGlobalPosition is the right method to move your kinematic actor.

Oh, I’m sorry. My English is so bad, because in my country nobody care about this in school. But now I try to correct it every day.

Yes, you understood me right.

Unfortunatly, reading PhysXGuide is so hard to me.

Maybe collisions with static objects was released in 3.2 revision?

Hm. Its sad to hear it.

Maybe an online translator could help you a little bit.
To use moveGlobalPosition is the right way for moving kinematic actors.

PhysX 2.x and 3.x does have static collisions I think. (Look at the example…)
You just have to enable the flags for it.
Look into the samples.

Here is a nice quote from the Physx Doc:
Kinematic actors will collide with true dynamic actors but not with static actors.
This may also change in the future.
—> Easy read mode: Kinematic vs static is not (direct) possible

Another one:
Kinematics that move into contact with statics or with other kinematics will not generate contact reports.

—> Easy read mode: Kinematic vs static wont generate contact reports (For usage with onContact / onTrigger)

Look also in Collision Interactions section in the doc.

I guess before you try to figure out how you could achieve the right behavior,
you should consider of the usage PhysX 3.x. (Only when you dont have much code :) )

As I said in one post before, its easy to use it, it has better performance, and it has other benifits.

Okay, I got it, thank you very much for all.

It is so helpful for me.
I will try to read guide with translator and rewrite my engine on PhysX 3.2.

You are welcome.

I guess its better to rewrite your engine if you dont have much code / algorithm or something similiar related to PhysX.

I think there is a workaround for your problem, but you need to read much of the docs or in the code to find a solution.