coelacant1 / prototracer Goto Github PK

The current Quaternion implementation shows different behavior when applied to 2D vectors compared to the 3D counterpart, this breaks some of the normal properties of Quaternions. Specifically, rotating a vector by a Quaternion using Quaternion::RotateVector() and rotating the result back using Quaternion::UnrotateVector() should return the original vector. This is the case for 3D vectors but doesnt apply in the 2D case. The following code snippet demonstrates the difference:

Quaternion testQuat = Rotation(EulerAngles({ 20.0f, 0, 0 }, EulerConstants::EulerOrderXZYS)).GetQuaternion();
Vector3D testVec(1, 2, 0);
Vector3D testRot = testQuat.RotateVector(testVec);
Vector3D testRotInv = testQuat.UnrotateVector(testRot);
printf("rotated: %.2f, %.2f, %.2f\n", testRot.X, testRot.Y, testRot.Z);
printf("unrotated: %.2f, %.2f, %.2f\n", testRotInv.X, testRotInv.Y, testRotInv.Z);

Vector2D testVec2D(1, 2);
Vector2D testRot2D = testQuat.RotateVector(testVec2D);
Vector2D testRotInv2D = testQuat.UnrotateVector(testRot2D);
printf("rotated 2D: %.2f, %.2f\n", testRot2D.X, testRot2D.Y);
printf("unrotated 2D: %.2f, %.2f\n", testRotInv2D.X, testRotInv2D.Y);

This difference is caused by the implicit use of a 3D Vector with 0 as a Z coordinate in Quaternion::RotateVector(Vector2D v) since a normal 3D rotation can result in a nonzero Z coordinate, eg in the given test case rotating (1, 2, 0) results in (1.00, 1.88, 0.68), discarding the Z coordinate breaks the inverse transform.

A possible workaround could for example be extracting the corresponding 2D transformation in the XY plane from the Quaternion (eg using the corresponding euler angles) and using that in the 2D rotation functions.

The current implementation of the predefined objects passes pointers to local member variables to the Object3D constructor, which in turn creates a copy of the TriangleGroup using modifiedTriangles = new TriangleGroup(originalTriangles);. This copy constructor copies the vertices and triangles, but stores the pointer to the IndexGroup. The TriangleGroup destructor then attempts to call delete[] indexGroup;. This is only safely possible when the IndexGroup was dynamically allocated and is not referenced anywhere else. In the case of the predefined Objects the IndexGroup is defined as a local member variable, therefore the use of delete[] is invalid and leads to undefined behavior. A similar issue exists for the vertices array of a TriangleGroup since the array pointer is copied in the constructor as well.

Other similar issues:

• PixelGroup() allocates the pixel array using new[] but ~PixelGroup() attempts to delete it using delete instead of delete[]

The practical impact of these issues is likely small though since Objectd3D instances are typically only destroyed at program exit.

To get the actual faces to show up on the leds, these releases need the face object(s) to be transformed so that anything will actually display on the matrixes. Transform meaning translate, rotate, and reflect. This hasn’t been a problem with other older releases ie 1.0.3.