geom.Matrix3D.interpolate and interpolateTo * possible bug... #3506

emergence75 · 2024-10-06T06:13:10Z

emergence75
Oct 6, 2024

i have been playing arround now for about several weeks to understand how this feature works...

since it's not possible to check the native flash implemention how flash does it, i rebuild the process in actionscript and came along a weird behaviour...

the most simple testcase to reproduce the main problem...

import flash.geom.Matrix3D;
import flash.geom.Vector3D;
import flash.geom.Orientation3D;

// define two Matrix3D transforms
var matrix1:Matrix3D = new Matrix3D();
matrix1.appendTranslation(300, 200, 200);
matrix1.appendScale(2, 2, 2);
matrix1.appendRotation(30, Vector3D.Z_AXIS);
matrix1.appendRotation(-45, Vector3D.Y_AXIS);

var matrix2:Matrix3D = new Matrix3D();
matrix2.appendTranslation(100, 100, 100);
matrix2.appendScale(1, 1, 1);
matrix2.appendRotation(90, Vector3D.Y_AXIS);
matrix2.prependRotation(45, Vector3D.X_AXIS);

var interpolatedMatrix:Matrix3D;
// interpolate between the two matrices
interpolatedMatrix = Matrix3D.interpolate(matrix1, matrix2, 0); // we set this here to zero 

trace('original', matrix1.rawData);
trace('\n');

var vec;
trace('QUATERNION original');
vec = matrix1.decompose(Orientation3D.QUATERNION);
trace(vec[1], vec[1].w); // rotation part
trace('\n');

trace('result', interpolatedMatrix.rawData);
trace('\n');
trace('QUATERNION interpolated');
vec = interpolatedMatrix.decompose(Orientation3D.QUATERNION);
trace(vec[1], vec[1].w); // rotation part

trace('\n');
trace('QUATERNION are different, why ?');

i'm pretty sure in the meantime that the interpolate or interpolateTo does not remove the scale from the raw matrix (mr)...

the decompose in general does following tasks

get position (tx, ty, tz) = mr[12], mr[13], mr[14]
get perspective * what flash ignores
get scale
a.) remove scale.x from mr[0],mr[1],mr[2]
b.) remove scale.x from mr[4],mr[5],mr[6]
c.) remove scale.x from mr[8],mr[9],mr[10]
get skew * what flash ignores
a.) calc skew.x, remove it from the mr
b.) calc skew.y, remove it from the mr
c.) calc skew.z, remove it from the mr
get rotation (as QUATERNION)

to get the scale values the decompose does something like this...

			var scale = new Vector3D();

			scale.x = Math.sqrt(mr[0] * mr[0] + mr[1] * mr[1] + mr[2] * mr[2]);
			scale.y = Math.sqrt(mr[4] * mr[4] + mr[5] * mr[5] + mr[6] * mr[6]);
			scale.z = Math.sqrt(mr[8] * mr[8] + mr[9] * mr[9] + mr[10] * mr[10]);

			if (mr[0] * (mr[5] * mr[10] - mr[6] * mr[9]) - mr[1] * (mr[4] * mr[10] - mr[6] * mr[8]) + mr[2] * (mr[4] * mr[9] - mr[5] * mr[8]) < 0) {
				scale.z = -scale.z;
			}

so far so good...

when 3.a 3.b and 3.c are not made like this

			mr[0] /= scale.x;
			mr[1] /= scale.x;
			mr[2] /= scale.x;
			mr[4] /= scale.y;
			mr[5] /= scale.y;
			mr[6] /= scale.y;
			mr[8] /= scale.z;
			mr[9] /= scale.z;
			mr[10] /= scale.z;

you will get at point 5. a near correct looking x,y,z,w
(important to notice this is not a normal vector, its a quaternion)
but without 3.a, 3.b and 3.c it's not right...

the interpolation example demonstrates such a behaviour...
the returned rawData shows that the mr[0][1][2], mr[4][5][6], m[8][9][10]
do not have removed the scale.x, scale.y, scale.z

the interpolate methods need this basic decompose steps for all further calculations,
the method with scale 1,1,1 works as expected, all other scale factors result in an unexpected quaternion

which results in the end in a false calculation for all steps the interpolate does afterwards...
in most cases the effect is minimal, and the animation looks good,
but in other cases the slerp calculation results in a wrong rotation direction...

can someone confirm ?

ajwfrost · 2024-10-11T12:07:41Z

ajwfrost
Oct 11, 2024
Maintainer

I confess I'm struggling to follow the logic here to work out exactly what you think is going wrong..

In terms of the normalisation: this is mentioned in the documentation for interpolateTo but not in the documentation for the static interpolate method.

In case of interpolation, the scaling value of the matrix will reset and the matrix will be normalized

In practice, all of the ActionScript calls end up in the same underlying geometry classes doing the same calculations, so there should be the same result whether you call the static or member versions, and whether you pass in an output value or not. One warning: it's possible that the interpolateToOutput method may give odd results if you pass in one of the input matrices as the output object.

But then .. the maths involved here is basically:

work out the interpolated transform (which is just the input value, with t=0)
get the quaternion values for the "from" and "to" matrices (and this stage involves normalisation)
calculate a resulting quaternion using a slerp
apply this to rotation to the "from" matrix
set back that original interpolated transform

Not sure if any of those stages might be going wrong .. if there's a worked example we can put in some output at each stage to show what's happening. The slerp has some threshold condition but that's not limiting things with the values you have here..

For that decompose method, it's converting it but not applying the normalisation when it works out the quaternion value.

Going back to your original example, I think what you are trying to demonstrate is

Take two different transformation matrices
Create an interpolation matrix between these - but with the percent value as zero (which means it should actually be identical to the initial matrix? or maybe, be normalised, but at least point the same way)
When you decompose these two matrixes using the quaternion mechanism, the angles here should therefore be the same .. but they're not

Looking at it again - there may be an issue with the "to quaternion" method when the normalisation is happening. Essentially we have a quaternion value that we get initially from the "from" matrix, and the slerp is essentially a no-op, but when we set up the matrix using this quaternion value, it's different. If we then calculate the quaternion again, we get the same as before, and this time if we set up the matrix again using this value, it doesn't change i.e. it's different from the original matrix but we've hit a steady state.

As I understand it, we should essentially be able to do to:

calculate quaternion from a matrix
set up a new matrix using this value
repeatedly without things changing (or at least, without the quaternion value changing, the matrix may have changed scale..)?

The original "to quaternion" function matches the code that's here, at least for the case it's hitting (positive 'tr') - it's structured a little differently and optimised to avoid division, but otherwise looks the same. But then the normalisation happens.. and then we set up the new matrix from this.

We'll try to dig a bit more into this ...! but if you have any step-by-step or reference code, it would be handy :-)

thanks

0 replies

emergence75 · 2024-10-12T08:53:09Z

emergence75
Oct 12, 2024
Author

Create an interpolation matrix between these - but with the percent value as zero (which means it should actually be identical to the initial matrix? or maybe, be normalised, but at least point the same way)

correct, with a value zero we must get the inital quaternion from the first matrix... (the quaternion must be identically)

i have here a decompose method, which basically should do what flash does...

		public function decompose(orientationStyle:String = "eulerAngles"):Vector.<Vector3D> {

			if (!(orientationStyle == Orientation3D.AXIS_ANGLE || orientationStyle == Orientation3D.EULER_ANGLES || orientationStyle == Orientation3D.QUATERNION)) {
				throw new Error("Error #2187: Invalid orientation style " + orientationStyle + ".  Value must be one of 'Orientation3D.EULER_ANGLES', 'Orientation3D.AXIS_ANGLE', or 'Orientation3D.QUATERNION'.", 2187);
			}

			var mr = this.rawData;

			var pos = new Vector3D(mr[12], mr[13], mr[14]);
			mr[12] = 0;
			mr[13] = 0;
			mr[14] = 0;

			var scale = new Vector3D();

			scale.x = Math.sqrt(mr[0] * mr[0] + mr[1] * mr[1] + mr[2] * mr[2]);
			scale.y = Math.sqrt(mr[4] * mr[4] + mr[5] * mr[5] + mr[6] * mr[6]);
			scale.z = Math.sqrt(mr[8] * mr[8] + mr[9] * mr[9] + mr[10] * mr[10]);

			if (mr[0] * (mr[5] * mr[10] - mr[6] * mr[9]) - mr[1] * (mr[4] * mr[10] - mr[6] * mr[8]) + mr[2] * (mr[4] * mr[9] - mr[5] * mr[8]) < 0) {
				scale.z = -scale.z;
			}

			if (0) { // i think interpolate does something like this...
				// set it to 1... best try so far...
				// it seems flash does only set this to 1 when interpolating
				// if this is true, it's a bug...
				scale.x = scale.x < 0 ? -1 : 1;
				scale.y = scale.y < 0 ? -1 : 1;
				scale.z = scale.z < 0 ? -1 : 1;
			}

			mr[0] /= scale.x;
			mr[1] /= scale.x;
			mr[2] /= scale.x;
			mr[4] /= scale.y;
			mr[5] /= scale.y;
			mr[6] /= scale.y;
			mr[8] /= scale.z;
			mr[9] /= scale.z;
			mr[10] /= scale.z;

			var rot = new Vector3D();

			switch (orientationStyle) {
				case Orientation3D.AXIS_ANGLE:
					rot.w = Math.acos((mr[0] + mr[5] + mr[10] - 1) / 2);

					var len = Math.sqrt((mr[6] - mr[9]) * (mr[6] - mr[9]) + (mr[8] - mr[2]) * (mr[8] - mr[2]) + (mr[1] - mr[4]) * (mr[1] - mr[4]));

					if (len != 0) {
						rot.x = (mr[6] - mr[9]) / len;
						rot.y = (mr[8] - mr[2]) / len;
						rot.z = (mr[1] - mr[4]) / len;
					}
					else {
						rot.x = rot.y = rot.z = 0;
					}
					break;

				case Orientation3D.QUATERNION:
					var tr = mr[0] + mr[5] + mr[10];

					if (tr > 0) {
						rot.w = Math.sqrt(1 + tr) / 2;

						rot.x = (mr[6] - mr[9]) / (4 * rot.w);
						rot.y = (mr[8] - mr[2]) / (4 * rot.w);
						rot.z = (mr[1] - mr[4]) / (4 * rot.w);
					}
					else if ((mr[0] > mr[5]) && (mr[0] > mr[10])) {
						rot.x = Math.sqrt(1 + mr[0] - mr[5] - mr[10]) / 2;

						rot.w = (mr[6] - mr[9]) / (4 * rot.x);
						rot.y = (mr[1] + mr[4]) / (4 * rot.x);
						rot.z = (mr[8] + mr[2]) / (4 * rot.x);
					}
					else if (mr[5] > mr[10]) {
						rot.y = Math.sqrt(1 + mr[5] - mr[0] - mr[10]) / 2;

						rot.x = (mr[1] + mr[4]) / (4 * rot.y);
						rot.w = (mr[8] - mr[2]) / (4 * rot.y);
						rot.z = (mr[6] + mr[9]) / (4 * rot.y);
					}
					else {
						rot.z = Math.sqrt(1 + mr[10] - mr[0] - mr[5]) / 2;

						rot.x = (mr[8] + mr[2]) / (4 * rot.z);
						rot.y = (mr[6] + mr[9]) / (4 * rot.z);
						rot.w = (mr[1] - mr[4]) / (4 * rot.z);
					}
					break;

				case Orientation3D.EULER_ANGLES:
					rot.y = Math.asin(-mr[2]);

					if (mr[2] != 1 && mr[2] != -1) {
						rot.x = Math.atan2(mr[6], mr[10]);
						rot.z = Math.atan2(mr[1], mr[0]);
					}
					else {
						rot.z = 0;
						rot.x = Math.atan2(mr[4], mr[5]);
					}
					break;
			}

			var vec = new Vector.<Vector3D>([]);

			vec.push(pos);
			vec.push(rot);
			vec.push(scale);

			return vec;
		}

the problem in interpolate is that it does not do it in this way...

i think the interpolate method implements its own decompose logic which goes wrong...
see position => // i think interpolate does something like this...

1 reply

ajwfrost Oct 17, 2024
Maintainer

Okay so with your AS3 implementation, that's giving the same results as the built-in "decompose" method, although it looks like some of the methods used to calculate some values are different..

The "interpolate" method does not use this at all though. It's got some logic to deal with the translation part based on the proportion/ratio given; but then it looks at the quaternion values for the "from" and "to" matrices - where these are normalised - and does a "slerp" calculation to work out the actual quaternion based on the proportion/ratio of interpolation. It applies this to the original "from" matrix by rotating using that quaternion, and then applies the translation. There's no mention of scale in this, and it doesn't use any of the logic from the "decompose" method.

So .. potentially there is indeed something missing, in terms of the 'scale' part (which I think is what you're mentioning in your original post, "the method with scale 1,1,1 works as expected, all other scale factors result in an unexpected quaternion"

I'm still not sure I'm understanding all this properly, but essentially - I believe - a Matrix3D object can be used as a 3D transform matrix for a point. So if we take a particular point (1,1,1) and apply a Matrix3D object, it will give us a different point. And if we do the same with a different Matrix3D object, we get a second point. So then, interpolating between these matrixes give us a resulting Matrix3D object which we can apply to (1,1,1) to get a point that's meant to be between those other points. If that's the case .. then I would have though when using zero as the interpolation factor, we should always end up with the same Matrix3D object that we pass in - or rather, that we end up with a Matrix3D object that gives the same resulting point if we apply it to (1,1,1) again.

We can try checking this kind of behaviour to validate that understanding! Plus I'm also thinking it may be worth us creating an AS3 version of the calculations that the runtime is doing in working out the interpolation, so that you can see how it's operating...

thanks

emergence75 · 2024-10-17T18:31:32Z

emergence75
Oct 17, 2024
Author

i've already created a interpolate version which is identical when scale is 1,1,1
this might be useful...

		public static function interpolate(thisMat:Matrix3D, toMat:Matrix3D, percent:Number):Matrix3D {

			var debug:Boolean = false;
			
			//var method:String = 'quaternion'; // eulerAngles, axisAngle, quaternion
			var method:String = Orientation3D.QUATERNION;

			var decomposedA:Vector.<Vector3D>, decomposedB:Vector.<Vector3D>;

			decomposedA = thisMat.decompose(method);
			decomposedB = toMat.decompose(method);

			// 0 = translation, 1 = rotation, 2 = scale
			// 3 = skew, 4 = perspective * own implementation
			//trace('skew', decomposedA[3], decomposedB[3]);
			//trace('pers', decomposedA[4], decomposedB[4]);

			if (debug) trace('scales', decomposedA[2], decomposedB[2]);
			
			var v0:Vector3D = decomposedA[1];
			var v1:Vector3D = decomposedB[1];
			
			var dot:Number = v0.x * v1.x + v0.y * v1.y + v0.z * v1.z + v0.w * v1.w; // we reuse this later below...
			var cosOmega:Number = dot;

			if (cosOmega < 0) {
				cosOmega = -cosOmega;
			}

			var k0:Number, k1:Number;

			if (cosOmega > 0.9999 || percent == 0 || percent == 1) {
				// If the quaternions are nearly identical, perform a linear interpolation
				k0 = 1 - percent;
				k1 = percent;
				if (debug) trace('linear');
			} else {
				// Otherwise, use spherical linear interpolation (Slerp)
				var sinOmega:Number = Math.sqrt(1 - cosOmega * cosOmega);
				var omega:Number = Math.atan2(sinOmega, cosOmega);
				var oneOverSinOmega:Number = 1 / sinOmega;
				k0 = Math.sin((1 - percent) * omega) * oneOverSinOmega;
				k1 = Math.sin(percent * omega) * oneOverSinOmega;
				if (debug) trace('slerp');
			}
			if (debug) trace('k0', k0, 'k1', k1);
			
			var scale = new Vector3D();
			// lerp... yes...
			scale.x = decomposedA[2].x * (1 - percent) + decomposedB[2].x * percent;
			scale.y = decomposedA[2].y * (1 - percent) + decomposedB[2].y * percent;
			scale.z = decomposedA[2].z * (1 - percent) + decomposedB[2].z * percent;

			if (debug) trace('scale', scale); // not in use by flash...

			var tx:Number, ty:Number, tz:Number;
			// pretty sure this is what flash does... lerp... yes...
			tx = decomposedA[0].x * (1 - percent) + decomposedB[0].x * percent;
			ty = decomposedA[0].y * (1 - percent) + decomposedB[0].y * percent;
			tz = decomposedA[0].z * (1 - percent) + decomposedB[0].z * percent;

			//trace(decomposedA[2].x, decomposedB[2].x, scale.x);
			var x:Number, y:Number, z:Number, w:Number;
			
			if (debug) trace('v0', v0, v0.w); // for the first vector * rotation
			if (debug) trace('v1', v1, v1.w); // for the second vector * rotation

			// If the angle is greater than 180 degrees, negate the quaternion to take the shorter path
			if (dot < 0.0) { 
				// all parts of the quaternion must be touched... don't use .negate(); .w is not touched...
				if (debug) trace('quaternion v1 inverted');
				v1.x = -v1.x;
				v1.y = -v1.y;
				v1.z = -v1.z;
				v1.w = -v1.w;
			}

			x = v0.x * k0 + v1.x * k1;
			y = v0.y * k0 + v1.y * k1;
			z = v0.z * k0 + v1.z * k1;
			w = v0.w * k0 + v1.w * k1;

			// Normalization of the quaternion, otherwise we could get a not wanted scale effects
			if (1) {
				var magnitude:Number = Math.sqrt(x * x + y * y + z * z + w * w);
				x /= magnitude;
				y /= magnitude;
				z /= magnitude;
				w /= magnitude;
			}

			// note: we completely ignore the perspective mr[3], mr[7], mr[11], mr[15]
			// and skew logic... the data for skew and perspective is available in extended decompose now
			// just do a simple lerp for skew and perspective
			
			var mr:Vector.<Number> = new Vector.<Number>(16, true);
			
			// recompose matrix raw with quaternion (without 12,13,14 this is basicly quaternion to matrix)
			mr[0] = (1 - 2 * y * y - 2 * z * z);
			mr[1] = (2 * x * y + 2 * w * z);
			mr[2] = (2 * x * z - 2 * w * y);
			mr[3] = 0;
			mr[4] = (2 * x * y - 2 * w * z);
			mr[5] = (1 - 2 * x * x - 2 * z * z);
			mr[6] = (2 * y * z + 2 * w * x);
			mr[7] = 0;
			mr[8] = (2 * x * z + 2 * w * y);
			mr[9] = (2 * y * z - 2 * w * x);
			mr[10] = (1 - 2 * x * x - 2 * y * y);
			mr[11] = 0;
			mr[12] = tx;
			mr[13] = ty;
			mr[14] = tz;
			mr[15] = 1;
			
			if (0) { // if you want scale interpolated * activate me * this would be correct...
				// Apply scale to X, Y, Z axes
				for (var i:int = 0; i < 3; i++) {
					mr[i] *= scale.x;  // X-axis
					mr[4 + i] *= scale.y;  // Y-axis
					mr[8 + i] *= scale.z;  // Z-axis
				}
				if (debug) trace('scaled mr', mr);
			}
			
			var m:Matrix3D = new Matrix3D(mr);
			
			return m;

		}

2 replies

ajwfrost Oct 18, 2024
Maintainer

Okay thanks - so yes that's pretty much what is happening in the C++ code here, with one exception around scaling (see below). And it gives me similar results, if I keep that final block as if (0). So basically, if we take a point (1,1,1) and apply the initial transformation matrix1 from your original snippet, we get:
Vector3D(-57.73719787597656, 649.1422119140625, 510.7766418457031)
If I do the interpolation using the built-in AS3 methods with 0 percent, and then apply the resulting matrix to (1,1,1), we get:
Vector3D(-57.5008544921875, 647.7626342773438, 509.7020263671875)
And we get the same with the AS3-based version that I just created based (roughly i.e. for the simplified case of zero percent) on the C++ code.
If I then use your above code, I also get:
Vector3D(-57.288909912109375, 647.7761840820313, 509.8106994628906)

But if I change your final if (0) to if (1) then I get:
Vector3D(-57.73719787597656, 649.1422119140625, 510.7766418457031)

I mentioned a difference in your routine about the scaling: as well as that bit at the bottom, you are also doing a decompose to get the quaternion there - but this is a different value from what we get. Because when we calculate the quaternion for this, we do not adjust the scale (i.e. the decompose part here is skipping the division by scale.x/scale.y/scale.z). We then have to normalise the quaternion (you do this, but in the tests here, that's actually not changing anything..). So, that might explain the slight differences in the results between your AS3 code and the actual implementation in C++.

My understanding from all of this though, is that your method - if we factor back in the scale values - is actually a more correct version...

My worry is that changing this could have interesting/unwanted side effects for people who are using this (although I'm starting to wonder, if it is this inaccurate, how many people are actually using this method!!)

ajwfrost Oct 18, 2024
Maintainer

FYI the 'interpolate' function we've got in AS3 now:

        public function interpolate(from : Matrix3D, to : Matrix3D, ratio : Number) : Matrix3D
        {
                var oneMinusRatio : Number = 1.0 - ratio;
                var fromData : Vector.<Number> = from.rawData;
                var toData   : Vector.<Number> = to.rawData;

                // in C++ we don't currently normalize the matrix prior to calculating the rotation
                // But our 'corrected' code would set this to true (we adjusted your 'decompose' method so we
                // only do the divide-by-scale block if this third argument is 'true'...)
                var decomposedFrom : Vector.<Vector3D> = decompose(from, Orientation3D.QUATERNION, CORRECTED);
                var decomposedTo   : Vector.<Vector3D> = decompose(to  , Orientation3D.QUATERNION, CORRECTED);
                                        
                var interpolated_translation : Vector3D = new Vector3D(
                        oneMinusRatio * fromData[12] + ratio * toData[12],
                        oneMinusRatio * fromData[13] + ratio * toData[13],
                        oneMinusRatio * fromData[14] + ratio * toData[14]); // could use decomposedFrom[0]...
                var interpolated_scale : Vector3D = new Vector3D(
                        oneMinusRatio * decomposedFrom[2].x + ratio * decomposedTo[2].x,
                        oneMinusRatio * decomposedFrom[2].y + ratio * decomposedTo[2].y,
                        oneMinusRatio * decomposedFrom[2].z + ratio * decomposedTo[2].z );

                var fromQuaternion : Vector3D = decomposedFrom[1];
                // Ignore "to" seeing as we have ratio = 0.0....

                trace("From quaternion = " + fromQuaternion.x + ", " + fromQuaternion.y + ", " + fromQuaternion.z + ", " + fromQuaternion.w);
                // we only need to normalize if we didn't do this in the decompose..
                if (!CORRECTED) fromQuaternion = fully_normalize(fromQuaternion);
                trace("From quaternion normalized = " + fromQuaternion.x + ", " + fromQuaternion.y + ", " + fromQuaternion.z + ", " + fromQuaternion.w);
                // apply this rotation to a new matrix
                var result : Matrix3D = matrixFromQuaternion(fromQuaternion); // same as your code
                // if we're trying to correct this, re-apply the scale
                if (CORRECTED) result.appendScale(interpolated_scale.x, interpolated_scale.y, interpolated_scale.z);
                // set the translation values
                result.appendTranslation(interpolated_translation.x, interpolated_translation.y, interpolated_translation.z);
                return result;
        }

So you can see the bits that the C++ isn't doing currently:

Because it's not using the 'decompose' method, it's not doing the normalisation of the matrix prior to calculating the rotation, and instead is normalising the quaternion after calculating it
It then completely ignores any scale values, the resulting matrix is just based on rotation and translation

If we were to make changes in the runtime for this:

do you have a useful and fairly complete/complex application that uses these calculations in order to present things visually, so that we could see what actual impact this has in practice?
if so / if you wanted a corrected runtime to test with, what platform would be best? Windows/macOS etc?

thanks

emergence75 · 2024-10-18T08:27:59Z

emergence75
Oct 18, 2024
Author

My worry is that changing this could have interesting/unwanted side effects for people who are using this (although I'm starting to wonder, if it is this inaccurate, how many people are actually using this method!!)

thats a good question...

if you want to bring in scale again and don't want to break existing projects, i would suggest to add an additional optional parameter
to these both methods...

function interpolate(from : Matrix3D, to : Matrix3D, ratio : Number, corrected = false) : Matrix3D
function interpolateTo(to : Matrix3D, ratio : Number, corrected = false) : Matrix3D

and by the way also in the Utils3D.pointTowards method, which also uses this interpolate method (scale gets removed)
and in the Matrix3d.pointAt -> scale is not removed... hmm... another topic..

do you have a useful and fairly complete/complex application that uses these calculations in order to present things visually, so that we could see what actual impact this has in practice?

i've created a visual demo in flash cs 5.5 which includes a demo for the interpolate problem...
(included also additional decompose compose logic for skew and perspective -> optional)
interpolating in flash method red, my implemention in green and a third method (grey) direct interpolation a matrix raw (which is completly wrong but shows the correct start and end point for the interpolation)
the code is currently a bit messy, since its my testing playground...

once finished the code would end up in ruffle and openfl (i hope...)

demo1.zip
demo2.zip

demo1 does apply scale
demo2 does not apply scale

if so / if you wanted a corrected runtime to test with, what platform would be best?

i use Windows 11

2 replies

ajwfrost Oct 24, 2024
Maintainer

Hi

Thanks for all this... one comment though on this proposal:

function interpolate(from : Matrix3D, to : Matrix3D, ratio : Number, corrected = false) : Matrix3D
function interpolateTo(to : Matrix3D, ratio : Number, corrected = false) : Matrix3D

We got into trouble before, when we introduced the ...ToOutput variants - or rather, before we created those separate functions, we had first created functions that just added the output optional parameter. You'd have thought that adding an optional parameter like your proposal above wouldn't actually affect existing code, but it basically broke Flex... because they have classes that derive from these internal Flash/AIR ones.

So if we changed from
function interpolate(from : Matrix3D, to : Matrix3D, ratio : Number) : Matrix3D
to
function interpolate(from : Matrix3D, to : Matrix3D, ratio : Number, corrected = false) : Matrix3D
then I think it would do the same: anyone deriving a class from Matrix3D who overrides that function, would find that their code no longer compiled.

Better options are either:

Create new functions for it e.g. interpolate2
Introduce a feature flag into the XML descriptor file e.g. <interpolationFix>true</interpolationFix> (which is a bit clunky?)
Just make the fix to be dependent upon the namespace i.e. we apply the fix if the application namespace is 51.2, which would mean for any older/existing applications, there's no change, and it's only when someone republishes their application with the newer AIR SDK (hopefully testing it first) then they would get the fix.

If you're changing it to work properly in Ruffle with this fix under the existing function name, then it might be simpler to just go with option 3...!

thanks

ajwfrost Oct 24, 2024
Maintainer

Ah .. having written that, I've just realised that in the Ruffle code, you did go with the extra corrected parameter... not sure how many Flex apps would be using Ruffle but it might be worth checking this kind of side-effect!

emergence75 · 2024-10-18T15:46:17Z

emergence75
Oct 18, 2024
Author

the decompose part here is skipping the division by scale.x/scale.y/scale.z)

i think if the routine adds this, the quaternion would be identical to my version... and this wouldn't break much from the compatibility...

My understanding from all of this though, is that your method - if we factor back in the scale values - is actually a more correct version...

you are right, it would be more correct...

i've implemented a more cleaned up version here
https://github.com/emergence75/ruffle-clone/blob/master/core/src/avm2/globals/flash/geom/Matrix3D.as
and here
https://github.com/emergence75/ruffle-clone/blob/master/core/src/avm2/globals/flash/geom/Utils3D.as

additional last parameter correct

by the way... thx for your time...

0 replies

emergence75 · 2024-10-24T18:42:42Z

emergence75
Oct 24, 2024
Author

Honestly, I don’t have much knowledge about the Flash internals. I was just glad that my rusty ActionScript still worked.

Ideally, I would prefer to get rid of this corrected == false entirely and do it the right way. Starting from namespace 51.2, this compatibility is no longer available in this area...

I think if someone had used this faulty interpolate, the common workaround at the time would likely have been to set the scaling to 1,1,1 before the interpolation without touching the tx, ty, tz parameters, and then apply the (interpolated) scaling afterward.

As you already mentioned, who would even use this method if it’s so flawed?

A kind of switch to enforce the old behavior might be useful—perhaps a global variable within ActionScript, for example. I can’t really say much about an XML switch, but that might also be a possibility...

2 replies

emergence75 Oct 24, 2024
Author

don't know if it is a possible solution to not changing the arguments...
https://airsdk.dev/reference/actionscript/3.0/arguments.html

if a hidden last parameter is provided -> force behaviour...

nope... does not work...

ajwfrost Oct 25, 2024
Maintainer

Hi

When you're dealing with just Flash-based applications, the bug compatibility is purely based on the SWF version - i.e. if you have a SWF with a particular version code, it can change the runtime behaviour, so that old/existing SWFs don't suddenly change how they work, but people who are creating new SWFs would update their version number in order to take advantage of new features as well as fixes like this.

In AIR we have the additional "namespace" for the XML application descriptor which gives us the additional control i.e. 51.0, 51.1, 51.2 etc whilst the SWF version stays at 51. So that was what I had thought to use, rather than any change of arguments. In AIR we also have a link between the SWF version and the namespace in that you can't load a newer SWF version with an older namespace - if you have a namespace version of 50.x, you can't load a SWF version 51.

AIR is also a bit muddied because people need to keep updating their applications in order to cope with the ever-changing requirements from Android + iPhoneOS etc. I don't actually think people would need to change their app descriptor or their SWF version - at least, unless they need any of the newer functionality that gets added via those mechanisms.

Anyway .. it's not an ideal world; for AIR I think we'll go with a fix for apps targeting 51.2 and above; for Ruffle you would have the choice to either fix it for everyone regardless of whether they knew about it or not - or to only apply the fix if it is a 'new' application using a particular SWF version or with a different API or similar. Or perhaps I guess if the SWFs are still hosted within an 'embed' tag, or some sort of HTML element, there could be a 'bug compatibility' flag set up via that perhaps? (i.e. like the 'global variable' but triggered outside the SWF?)

Tricky to find a perfect solution, there's always a risk a change like this would cause issues to existing apps..

thanks

emergence75 · 2024-11-06T19:15:02Z

emergence75
Nov 6, 2024
Author

this might be a solution

https://github.com/emergence75/ruffle/blob/flash.geom-alternate/core/src/avm2/globals/flash/geom/Matrix3D.as

see public static function get correct() and public static function set correct()

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

geom.Matrix3D.interpolate and interpolateTo * possible bug... #3506

{{title}}

Replies: 7 comments 7 replies

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

Select a reply

geom.Matrix3D.interpolate and interpolateTo * possible bug... #3506

emergence75 Oct 6, 2024

Replies: 7 comments · 7 replies

ajwfrost Oct 11, 2024 Maintainer

emergence75 Oct 12, 2024 Author

ajwfrost Oct 17, 2024 Maintainer

emergence75 Oct 17, 2024 Author

ajwfrost Oct 18, 2024 Maintainer

ajwfrost Oct 18, 2024 Maintainer

emergence75 Oct 18, 2024 Author

ajwfrost Oct 24, 2024 Maintainer

ajwfrost Oct 24, 2024 Maintainer

emergence75 Oct 18, 2024 Author

emergence75 Oct 24, 2024 Author

emergence75 Oct 24, 2024 Author

ajwfrost Oct 25, 2024 Maintainer

emergence75 Nov 6, 2024 Author

emergence75
Oct 6, 2024

Replies: 7 comments 7 replies

ajwfrost
Oct 11, 2024
Maintainer

emergence75
Oct 12, 2024
Author

ajwfrost Oct 17, 2024
Maintainer

emergence75
Oct 17, 2024
Author

ajwfrost Oct 18, 2024
Maintainer

ajwfrost Oct 18, 2024
Maintainer

emergence75
Oct 18, 2024
Author

ajwfrost Oct 24, 2024
Maintainer

ajwfrost Oct 24, 2024
Maintainer

emergence75
Oct 18, 2024
Author

emergence75
Oct 24, 2024
Author

emergence75 Oct 24, 2024
Author

ajwfrost Oct 25, 2024
Maintainer

emergence75
Nov 6, 2024
Author