Device/Screen Orientation messing with Physics/Forces?

Questions & Answers
1

Below my code to control a marbel object that is also capable of jumping/bouncing by adding vertical force via accelerometer. This works but with a problem related to Portrait and PortraitUpsideDown. Seems PortraitUpsideDown messes somehow with AddForce in global y (accelerometer axis z = global axis y). While in Portrait orientation control behaves as expected on all axis, but with PortraitUpsideDownBelow forces in global y seem to be much smaller. Thus the object (e.g. ball) doesn’t jump high enough in PortraitUpsideDown Orientation. Forces along global x/z seem to be correct and reasonable for both orientations. It’s worth to say that I don’t autorotate during gameplay but fix the autorotation in a previous scene (menu). I can’t get why there is an anomaly with forces along global y axis and already willing to say this is a unity bug. Anyone run into this or see an error in the code?

public var force : float = 0.2;
    public var forcefactorY : float = 4;//fine tuning

    public var clamping : float = 0.01;

    static var allowFixedUpdateLoop : boolean = true;
    public var accumulateForceOnJump : boolean;
    public var delayAccumulationStop : float = 0.333;

    private var fixingDeviceOrientation : float;
    private var dir : Vector3 = Vector3.zero;
    private var dirY : float;

    function Start()
    {
        if( Screen.orientation == ScreenOrientation.PortraitUpsideDown )
        {
            fixingDeviceOrientation = -1;

//Nasty workaround: multiplying with 3.333 to compensate mysterious
//loss of force in PortraitUpsideDown orientation, still Input doesn't feel
//the same when tryin to make the object bounce or jump as in Portrait.

            forcefactorY *= 3.333 * force; 
            force = -force;
        }
        else
        {
            fixingDeviceOrientation = 1;
            forcefactorY *= force;
        }
    }

    function FixedUpdate()
    {
        if(allowFixedUpdateLoop)
        {
            AccelerometerController();
        }
    }

    function OnCollisionStay(collision : Collision)
    {   
        allowFixedUpdateLoop = false;
        AccelerometerController();
    }

    function OnCollisionExit(collison : Collision)
    {
        AccumulateForceOnJump();
    }

    function AccelerometerController()
    {   
        //accelerometer and inputs are calculated here

            dir.x = -Input.acceleration.y;
            dir.z = Input.acceleration.x;
            dir.y = Input.acceleration.z;
            if (dir.sqrMagnitude > 1)
            {
                dir.Normalize();
            }
            dirY = dir.y;
            if (dirY < 0)
            {
                dirY = 0;
            }

            if (Mathf.Abs(dir.z) < clamping)
            {
                dir.z = 0;
            }           
            if (Mathf.Abs(dir.x) < clamping)
            {
                dir.x = 0;
            }
            rigidbody.AddForce(dir.x * force, dirY * forcefactorY, dir.z * force);

    }

    function AccumulateForceOnJump()
    {
        allowFixedUpdateLoop = true;
        yield WaitForSeconds(delayAccumulationStop);
        allowFixedUpdateLoop = accumulateForceOnJump;
    }
2

After continued tests it appears not to be a Unity bug nor a user script error, but it’s hardware specific (iPad). I suspect the position of the accelerometer not centered in the iPad thus the momentum when trying to jump/bounce the ball is quite different depending on how the device is held (Portrait or PortraitUpsideDown). This results in a inconsistent/confusing jump-behaviour of the ball. Very bad for marble/ roll the ball games with a jumping ball on iPad, unfortunately. On other (smaller) devices it seems to be ok.