[ASSIMP] Normierung von Quaternionen

[CodingCat]

Das neue PhysX SDK (3.2) verhält sich sehr vorbildlich bei der Validierung von Daten. So bin ich aufgrund neuerlicher Crashes meines Import-Tools (fehlgeschlagene PhysX Assertions) darauf gestoßen, dass aiMatrix4x4::decompose() gar keine normierten Quaternionen liefert. Das könnte der Grund für eine Vielzahl von Problemen sein, die ich im letzten Jahr mit PhysX hatte (vor meinem Bug Report zu Mesh Scaling war PhysX selbst jedoch an einigen Stellen so buggy, dass ich den Fehler bis gerade eben nie vernünftig lokalisieren konnte). Deshalb die Frage: Ist das so gewollt?

Obendrein hat sich wohl leider ein grober Bug in die aiQuaternion::Normalize()-Funktion eingeschlichen, dessen bisherige Unbemerktheit schon äußerst überraschend ist: :mrgreen:

Code: Alles auswählen

inline aiQuaternion& aiQuaternion::Normalize()
{
	// compute the magnitude and divide through it
	const float mag = x*x+y*y+z*z+w*w;
	// BUG: mag ist Betrag zum Quadrat, Quadratwurzel fehlt
	if (mag)
	{
		x /= mag;
		y /= mag;
		z /= mag;
		w /= mag;
	}
	return *this;
}

[dot]

Eine kleine Optimierung wäre hier potentiell auch, die Division der einzelnen Komponenten durch eine Multiplikation mit dem Kehrwert zu ersetzen, da der Compiler (zumindest MSVC unter /fp:precise) in der Regel diese Transformation afaik nicht vornehmen darf.

[Schrompf]

Also der aktuelle Code dazu sieht so aus:

Code: Alles auswählen

template<typename TReal>
inline aiQuaterniont<TReal>& aiQuaterniont<TReal>::Normalize()
{
	// compute the magnitude and divide through it
	const TReal mag = sqrt(x*x + y*y + z*z + w*w);
	if (mag)
	{
		const TReal invMag = static_cast<TReal>(1.0)/mag;
		x *= invMag;
		y *= invMag;
		z *= invMag;
		w *= invMag;
	}
	return *this;
}

Man könnte noch die Wurzel ins if() reinziehen, aber da ich Null-Quaterions für unwahrscheinlich halte, ist das nur müßige Überlegung. Mit welcher Assimp-Version arbeitest Du?

[CodingCat]

2.0 Revision 863 laut revision.h (letzte offizielle Veröffentlichung?). Wenn das inzwischen gefixt ist, umso besser. Wie das dann jetzt mit decompose() ausschaut, muss ich erst nachsehen.

[Krishty]

Eine kleine Optimierung wäre hier potentiell auch, die Division der einzelnen Komponenten durch eine Multiplikation mit dem Kehrwert zu ersetzen, da der Compiler (zumindest MSVC unter /fp:precise) in der Regel diese Transformation afaik nicht vornehmen darf.

Mit gutem Grund – man liegt halt meist mindestens ein ULP daneben. Dann rechnet man das Quaternion zur Matrix um, dann die Matrix zu Euler-Winkeln, und schon kracht es weil acos(1.000001f) berechnet werden soll – oder es kracht genau nicht.