适当的矩阵乘法用于旋转/平移

Question

In order to rotate/translate object (rotation only about z-axis and translation only in xy plane) not just wrt to global center (device center) but also wrt other arbitrary points, I created an algorithm, which is correct (because all senior coders I have discussed with consider it correct), but it is taking a lot of time to remove an undesired translation in the implementation (algorithm was created on August 4 and was implemented on the same day, since then the code has been revised 15 times).

Here is the implementation http://www.pixdip.com/opengles/transform.php#ALGO1

The lines of code that are producing undesired translation are inside:

private static void updateModel(int upDown, float xAngle, float yAngle, float zAngle) {

and are listed below:

1. Matrix.multiplyMV(GLES20Renderer._uBodyCentreMatrix, 0, GLES20Renderer._ModelMatrixBody, 0, GLES20Renderer._uBodyCentre, 0);

2. objX = GLES20Renderer._uBodyCentreMatrix[0];

3. objY = GLES20Renderer._uBodyCentreMatrix[1];

The undesired translation along +Y persists even if the following changes are made:

1. objY = _uBodyCentreMatrix[1] - _uBodyCentre[1];

2. zAngle = 0;

3. ds = 0;

The value -0.545867f is added to the Y coordinate on every call to onDrawFrame() , because of these fields of the Renderer class:

private static final float[] _uBodyCentre = new float[]{-0.019683f, -0.545867f, -0.000409f, 1.0f};

protected static float[] _uBodyCentreMatrix = new float[4];

in http://www.pixdip.com/opengles/transform.php#FIELDS

I need help to understand why does that undesired translation happen, what is exactly wrong with the transformations, or is it the algorithm that is wrong.

Can Gimbal lock be an issue here ?

Please do not ask me to perform/practice simpler examples, because I have prepared the Renderer class for rotation/translation about global z-axis, and this new task that I am into, uses the same class with slight modification in updateModel()

(Please note that the desired rotation is only about z-axis and translation only in xy plane)

[API 10->15]

The actual Renderer class has two objects: tank turret(nozzle) and tank body , while turret(nozzle) has undesired forward translation, the body has undesired backward translation

Apk for translation/rotation about device center (which is easy to make in opengles 2.0): http://www.pixdip.com/opengles/global.php

Apk for translation/rotation about arbitrary points (which has undesired translation along +Y): http://www.pixdip.com/opengles/local.php

Apk for translation/rotation about arbitrary points in which updateModel() is called 4 times only: http://www.pixdip.com/opengles/limited.php and required code (which should be sufficient) is here: http://www.pixdip.com/opengles/code.php

Parts of object (nozzle/turret,body) are currently rotating about their own centres not the centre of object (which is _playerCentre), I will modify that later.

I have tried to demonstrate logic http://www.pixdip.com/opengles/images.php

Answer 1

It looks like the problem is:

Matrix.multiplyMV(GLES20Renderer._uBodyCentreMatrix, 0, GLES20Renderer._ModelMatrixBody, 0, GLES20Renderer._uBodyCentre, 0);

Matrix.multiplyMV is a method to multiply a 4 element vector by a 4x4 matrix and store the result in a 4 element column vector. In matrix notation: result = lhs x rhs. The resultVector element values are undefined if the resultVector elements overlap either the lhsMatrix or rhsVector elements.

I don't think you posted all the code so I can't check for sure, but judging by your naming of '_uBodyCentreMatrix' you are probably encountering an error because it is not a 4 element column vector.

I'm assuming that '_ModelMatrixBody' is a 4x4 matrix and '_uBodyCentre' is a 4 element vector, otherwise these could be problematic as well.

Answer 2

[SOLVED] java floating point errors were the only cause

M = T * I * T[inv]

did not result into an identity matrix, so instead of using Matrix.MultiplyMM

I type all the multiplications between the matrices

Answer 3

You could use a method like this:

public void rotateToAbritrary(float[] arbitraryPoint, float xAngle, float yAngle, float zAngle) {
    Matrix.translateM(modelMatrix, 0, arbitraryPoint[0], arbitraryPoint[1], arbitraryPoint[2]);
    float max = Math.max(xAngle, Math.max(yAngle, zAngle));
    if(max != 0.0f) Matrix.rotateM(modelMatrix, 0, max, xAngle / max, yAngle / max, zAngle / max);
    Matrix.translateM(modelMatrix, 0, -arbitraryPoint[0], -arbitraryPoint[1], -arbitraryPoint[2]);
}

That's how I see it, at least, I leave you to the implementation. I gather your code doesn't suffer the Gimbal lock.

Answer 4

http://tutorialrandom.blogspot.com/2012/08/how-to-rotate-in-3d-using-opengl-proper.html

I find this the simplest way to do rotations without getting any sort of gimbal lock or odd translation. its an iOS example but im sure can be applied easily to android. Also its for 3d rotations but can easily be applied to 2d by just not rotating about one of the axis.