X is UP?

[RobertMtx]

So I've noticed that the PhysX SDK appears to assume the X axis is up, such as during geometry shape creation, and the fact that planes have their normal facing on positive X.

I'm still integrating the SDK into my existing (large scale) custom game engine, and I am wondering what the implications of this are. In my engine, X is sideways, Z is depth, and positive Y is vertical up. The XZ plane is the ground plane. Apart from that, all of my game's math objects are nearly identical to PhysX, to the point where I can reinterpret_cast them directly on the same memory as PhysX math objects. But that won't matter if PhysX thinks X is up. If I ignore all of this and just integrate as-is, does this mean PhysX will think my world is running sideways? I see its possible to set a custom gravity vector, but are there any other considerations?

For example, I have to rotate capsules by 90 degrees after they are created, so they point vertical (I assume so, I haven't been able to test yet). Is there anything else I need to consider regarding this sideways situation? I'm assuming most game engines have something other than X as their vertical axis?

Thanks for any advice!

[PierreTerdiman]

I think there is some confusion here.

There is a convention regarding the X axis for shapes and joints, but it has nothing to do with which way is up. PhysX does not "assume the X axis is up", does not "think X is up", not at all. It is not only "possible to set a custom gravity vector", it is in fact mandatory - since PxSceneDesc::gravity is zero by default. So which way the object will fall ("sideways" or not) is up to you here.

Now the convention used for planes, capsules, but also for joints (the prismatic axis, the hinge axis, etc, are all defined as the X axis for API consistency with shapes) is just that - a convention. I suppose X was the most neutral choice, since indeed it is rarely the intended up axis, and thus everybody is treated equally there (both users with Y up or Z up have to deal with this, PhysX does not prefer one of the other).

This convention is unrelated to which way is up, because "up" is usually a global, world-space decision, while shapes and joints are all defined in local space, i.e. in this case a PxGeometry (and in particular PxPlaneGeometry or PxCapsuleGeometry) never exists in isolation, it always has a corresponding PxTransform defining its local pose.

So all you have to do is define this local pose's rotation, so that it rotates your shape (plane/capsule) from the X axis to your desired up axis (which doesn't even have to be Y or Z: the character controller module for example supports arbitrary up axes, as seen in SampleCustomGravity for example). You can use e.g. the PxShortestRotation() function for that.

If you are already rotating your capsules 90 degrees, then that's all there is to it. For simple objects with a single shape like a simple capsule, you can choose to rotate it using the local pose (PxShape::setLocalPose) or the global pose (PxActor::setGlobalPose). For compound objects you'll need to use the local pose.

[RobertMtx]

That's great to hear. I just wanted to make sure there wasn't anything I wasn't considering. Some APIs, having a different coordinate system, can have a lot of side effects, so its great to hear that's not the case. Thanks for the detailed explanation!