3D Mathematik und was mich sonst noch Wahnsinnig macht

[Slin]

Hallo,

Ich arbeite seit wenigen Wochen an einer Spieleengine für iPhone und Co (http://isdge.sf.net) und habe inzwischen wohl schon fast die Hälfte der Zeit in Animationen investiert nur um jetzt festzustellen, dass ich eine ganz wichtige Tatsache völlig missachtet habe. Jedenfalls habe ich die tolle Assimp für einen Konverter zu meinem eigenen Format missbraucht (nachdem ich an den Texturekoordinaten mit Collada total verzwefelt bin) und ziemliche Probleme die Koordinatensysteme "anzugleichen". Ich blicke inzwischen weder durch mein eigenes noch durch das was ich nach dem Importieren (ohne makeLeftHanded) mit Assimp erhalte durch. bei mir ist die y-Achse die, die nach oben zeigt und in der Assimp Dokumentation steht:

By default the data is returned in a right-handed coordinate space which for example OpenGL prefers. In this space, +X points to the right, +Z points towards the viewer and and +Y points upwards. In the DirectX coordinate space +X points to the right, +Y points upwards and +Z points away from the viewer.

und dennoch muss ich y und z vertauschen, wie kann das sein?
Reicht es bei den Matrizen in den "Bonespace" diese zu Column-Major umzuordnen und dann matrix*vertex zu berechnen? Bzw Y und Z eben auch noch entsprechend auszutauschen.
Kann ich die quaternions dann auch einfach direkt nutzen?

Quaternions nutze ich nur "intern", d.h. meine Objekte haben alle Eulerwinkel, dann ist doch Gimbal -Lock durchaus wieder ein Problem, oder? Bei meiner Quaternionklasse ist y und z im Vergleich zu dem was ich am Anfang erwartet habe vertauscht.

Jedenfalls denke ich darüber nach, meine Vektor, Quaternion und Matrix Klassen nochmal komplett neu anzufangen. Könnt ihr mir da irgendeine gute Quelle empfehlen die mir nicht noch abverlangt y und z und row und column major selbst zu verdrehen?

Aktuell bin ich einfach nur total verwirrt und versuche da wieder etwas Ordnung hinein zu bringen und wenn ihr mir dabei irgendwie helfen würdet wäre das toll :)
Übrigens sry, wenn dies die falsche Rubrik ist, aber am besten hätte es in alle drei zusammen gepasst.

Nils



So sieht die Berechnung meiner Worldspacematrix für Objekte aus:

Code: Alles auswählen

void sgObject::updateModel()
{
	matmodel.makeTranslation(position);
	matmodel.scale(scale);
	matmodel.rotate(rotation);

	matnormal.makeRotation(rotation);
}

Dies ist meine Matrixklasse: http://isdge.svn.sourceforge.net/viewvc ... iew=markup (die transformZY Methoden sind so auf jeden Fall falsch, aber das habe ich bei mir inzwischen korrigiert, hoffe ich zumindest :P)
und dies die der Quaternions: http://isdge.svn.sourceforge.net/viewvc ... iew=markup
Die Quaternionklasse ist von unterschiedlichen Quellen zusammenkopiert und angepasst, was viel falsches bewirkt haben könnte. Die Matrixklasse ist dagegen aus einem alten Projekt von mir kopiert nd da habe ich etwas selbst nachgedacht und dann herumprobiert bis es passte was also auch in vielen Fehlern geendet haben kann. Die Vektorklasse verlinke ich nicht, da ich mir ziemlich sicher bin, dass dort alles korrekt ist (und selbst wenn dies nicht so sein sollte, ist es für meine aktuellen Probleme irrelevant).
Dies nur für den Fall, dass hier jemand Langeweile und Lust darauf hat sich extrem häßlichen Code anzutun.

[Chromanoid]

Jedenfalls habe ich die tolle Assimp für einen Konverter zu meinem eigenen Format missbraucht (nachdem ich an den Texturekoordinaten mit Collada total verzwefelt bin) und ziemliche Probleme die Koordinatensysteme "anzugleichen".

Warum nimmst du nicht Assimp direkt mit in deine Engine auf? Ich habe Assimp in einem 3D Viewer für das iPhone eingebaut und da klappt alles wunderbar. Ich hab zwar keine Animationen drin (nicht implementiert), aber Texturen und Vertexfarben klappen (natürlich) wunderbar. Das einzige was ich gemacht habe ist einen ObjectiveC-Wrapper um die Assimp-Klassen zu bauen, der mir nen Index-Buffer zusammenbastelt und den ganzen kram als VBOs lädt. Bspw. MDL-Dateien wären doch optimal für eine 3d Engine.

Code: Alles auswählen

//Laden eines Models
NSString *path = [[NSBundle mainBundle] pathForResource:@"duck" ofType:@"dae"];
NSData *fileData=[[NSData alloc]initWithContentsOfFile:path];
testScene=[[SimpleScene alloc] initWithFileData:fileData filename:@"duck.dae"];

Das ganze läuft über NSData da die Modelle eigentlich in einer sqlite db drin sind...

Code: Alles auswählen

//SimpleScene.mm
-(id)initWithFileData: (NSData *) fileData filename:(NSString*)filename {
	self=[super init];
	const char *charPath = ( char *)[filename UTF8String];
	using namespace Assimp;
	Importer *importer=new Importer();

	importer->ReadFileFromMemory(fileData.bytes, fileData.length, aiProcessPreset_TargetRealtime_Quality|aiProcess_Triangulate,charPath);

	base=importer->GetOrphanedScene();
	meshes=[[NSMutableArray alloc]initWithCapacity:base->mNumMeshes];
	for(int i=0;i<base->mNumMeshes;i++){
		[meshes addObject:[[SimpleMesh alloc]initWithAiMesh:base->mMeshes[i]]];
	}
	materials=[[NSMutableArray alloc]initWithCapacity:base->mNumMaterials];
	for(int i=0;i<base->mNumMaterials;i++){
		[materials addObject:[[SimpleMaterial alloc]initWithAiMaterial:base->mMaterials[i]]];
	}
	return self;
}

Im SimpleMesh wird dann eigentlich nur ein Index-Buffer gebaut... Ist alles ein bisschen ressourcen verschwenderisch aber das ist im rahmen dieses Studienprojektes eher egeal...

Code: Alles auswählen

//SimpleMesh.mm
-(id)initWithAiMesh:(aiMesh*) mesh{
	self=[super init];
	vboVerticesName=-1;
	vboIndicesName=-1;
	vboNormalsName=-1;
	vboColorsName=-1;
	vboTexCoordsName=-1;
	
	base=mesh;
	//aiProcess_Triangulate muss beim laden gesetzt werden
	numIndices=base->mNumFaces*3;
	indices=new GLushort[numIndices];
	for(int i=0;i<base->mNumFaces;i++)
	{
		indices[i*3]=base->mFaces[i].mIndices[0];
		indices[i*3+1]=base->mFaces[i].mIndices[1];
		indices[i*3+2]=base->mFaces[i].mIndices[2];
	}
	//Normalen müssen gesetzt sein
	useNormals=true;
	useColors=false;
	useTexCoords=false;
	return self;
}

-(void)loadToOGLWithScene:(SimpleScene*)scene {
	glGenBuffers(1, &vboVerticesName);
	glBindBuffer(GL_ARRAY_BUFFER, vboVerticesName);
	glBufferData(GL_ARRAY_BUFFER, base->mNumVertices*3*sizeof(float), &base->mVertices[0].x, GL_STATIC_DRAW);
	glGenBuffers(1, &vboIndicesName);
	glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, vboIndicesName);
	glBufferData(GL_ELEMENT_ARRAY_BUFFER, numIndices*sizeof(GLushort), &indices[0], GL_STATIC_DRAW);
	
	if(useNormals)
	{
		glGenBuffers(1, &vboNormalsName);
		glBindBuffer(GL_ARRAY_BUFFER, vboNormalsName);
		glBufferData(GL_ARRAY_BUFFER, base->mNumVertices*3*sizeof(float), &base->mNormals[0].x, GL_STATIC_DRAW);
	}
	int colorChannel=((SimpleMaterial*)[scene->materials objectAtIndex:base->mMaterialIndex])->vertexColorChannel;
	useColors=(colorChannel>-1 && base->mColors!=NULL && base->mColors[colorChannel]!=NULL);
	if(!useColors){
		useColors=(base->mColors!=NULL && base->mColors[0]!=NULL);
		colorChannel=0;
	}
	if(useColors)
	{
		glGenBuffers(1, &vboColorsName);
		glBindBuffer(GL_ARRAY_BUFFER, vboColorsName);
		glBufferData(GL_ARRAY_BUFFER, base->mNumVertices*4*sizeof(float), &base->mColors[colorChannel][0].r, GL_STATIC_DRAW);
	}
	int texCoordChannel=((SimpleMaterial*)[scene->materials objectAtIndex:base->mMaterialIndex])->texCoordChannel;
	if(texCoordChannel>=0){
		texCoordDimension=base->mNumUVComponents[texCoordChannel];
		useTexCoords=(base->mTextureCoords!=NULL);
		useTexCoords=useTexCoords&& base->mTextureCoords[texCoordChannel]!=NULL;
		useTexCoords=useTexCoords&& texCoordDimension>0;
		if(useTexCoords)
		{
			GLfloat *texCoords=&base->mTextureCoords[texCoordChannel][0].x;
			if(texCoordDimension>0 && texCoordDimension<3)
			{
				texCoords=new GLfloat[base->mNumVertices*texCoordDimension];
				for(int i=0;i<base->mNumVertices;i++)
				{
					texCoords[i*texCoordDimension]=base->mTextureCoords[texCoordChannel][i].x;
					if(texCoordDimension>1)
						texCoords[i*texCoordDimension+1]=base->mTextureCoords[texCoordChannel][i].y;
				}
			}
			glGenBuffers(1, &vboTexCoordsName);
			glBindBuffer(GL_ARRAY_BUFFER, vboTexCoordsName);
			glBufferData(GL_ARRAY_BUFFER, base->mNumVertices*texCoordDimension*sizeof(float), texCoords, GL_STATIC_DRAW);
		}
	}
}

Vielleicht hilft dir das ja...

Liebe Grüße
Chromanoid

PS: http://download.java.net/media/java3d/b ... _2-src.zip ist eine gut lesbare Java Mathe Bibliothek mit Quaternionen, Matrizen und Vektoren... Ist glaube ich durch die sun code review maschinerie gegangen und dementsprechend ziemlich sicher bugfrei... da kann man sich gut dran orientieren.

[Slin]

Vielen Dank für deine Antwort.
Ich möchte die Engine unter der MIT-Lizenz aufziehen und die Lizenz von Assimp verträgt sich damit nicht so super, deshalb der Umweg über einen Konverter um dies zu verhindern. Es ist einfach so, dass ich bei einem einfachen iPhonespiel nicht zwingend einen Menüpunkt haben möchte in dem dann aufgeführt wird, dass Assimp genutzt wird.
Das Konvertieren und Importieren funktioniert ja auch problemlos und es wird alles korrekt gerendert, ich kann mir nur in Verbindung mit dem oben genannten nicht erklären, warum ich Y und Z vertauschen muss. Auch bilde ich mir eib, vor ein paar Tagen noch etwas von wegen 3DS Max Koordinatensystem in der Assimp Dokumentation gelesen zu haben?

Kann es sein, dass Assimp mit MDL Dateien mit Bones Probleme hat? Aber vielleicht ist da auch auf meiner Seite etwas schief gelaufen, als ich das getestet habe, denn als Gamestudio Nutzer habe ich eine recht große Sammlung an mdl Dateien.
Und vielen Dank für den Link, das gucke ich mir mal genauer an.

[eXile]

Für solche Fälle lege ich dir immer den Eberly (bzw. mittlerweile die Eberlys) nahe. Netterweise hat er seine gesamten Code-Bestandteile auch auch online gestellt:

http://www.geometrictools.com/LibMathem ... gebra.html

Damit kannst du deine Implementation ja mal gegentesten ...

[Chromanoid]

Auch bilde ich mir eib, vor ein paar Tagen noch etwas von wegen 3DS Max Koordinatensystem in der Assimp Dokumentation gelesen zu haben?

Ja, da ist die Z-Achse die Vertikale. D.h. wenn du daher deine Modelle nimmst, könnte das durchaus daran liegen. Benutze doch einfach mal die Test-Modelle aus Assimp, wenn du da auch das Problem hast, dann sollte es an deinem Code liegen...

BTW: Es handelt sich ja hier eher um eine Diskussion über Quellcode/Bugs... Sollen wir das ganze vielleicht mal verschieben?

[Slin]

Naja, ich nutze für meine Modelle Blender, weil mir für alles andere einerseits das Geld fehlt und und ich vor allem mit Blender sehr zufrieden bin. Die Beispielmodelle von Assimp sind bisher irgendwie an mir vorbeigegangen, die werde ich mir dann als erstes mal vornehmen. Danke für den Hinweis.
Deinen Link eXile werde ich mir auch mal angucken. So habe ich jetzt schonmal ein paar neue Ansätze um Ordnung in meine Verwirrung zu bringen :)

[Schrompf]

Über Bugs in MDL-Dateien kann ich nichts sagen... da wirst Du mal ein konkretes Beispielfile schicken müssen, zusammen mit einer Beschreibung, was Du erwartest, und was Du stattdessen bekommen hast.

Zum Koordinatensystem: wenn Du meinst, Y- und Z-Achse vertauschen zu müssen, dann benutzt Du evtl. ein linkshändiges Koordinatensystem. Das reine Vertauschen der beiden Achsen erzeugt aber eine Transformation mit Spiegelung drin - die kannst Du dann nicht mehr sinnvoll in Quaternions zerlegen, Animationen werden damit also nicht funktionieren. Probiere stattdessen mal den MakeLeftHanded-Post Processing Step bzw. die anderen Steps aus dem Dunstkreis.

[edit]Auch Assimp selbst hat Klassen für Vektor, Matrix und Quaternion. Die sind zwar nur aufs Minimum beschränkt, aber gut getestet. Schau Dir doch die mal an.

[Slin]

Also abgesehen davon, dass es sowas wie richtig oder falsch in dem Zusammenhang irgendwie ja nicht gibt, sind die Daten so, wie ich sie von Assimp bekomme bereits in der Form, in der man sie üblicherweise an OpenGL weitergibt, richtig?
Und wo ich gerade beim Fragen bin... Kann es sein, dass meine Worldmatrix nicht dazu geeignet ist die Normalen in den Worldspace zu transformieren? Denn irgendwie macht nicht nur die Scale-Komponente sondern auch schon die Translation Probleme, weshalb ich aktuell eine extra Matrix mit nur der Rotation an meinen Beleuchtungsshader übergebe.

[Aramis]

Ich möchte die Engine unter der MIT-Lizenz aufziehen und die Lizenz von Assimp verträgt sich damit nicht so super, deshalb der Umweg über einen Konverter um dies zu verhindern. Es ist einfach so, dass ich bei einem einfachen iPhonespiel nicht zwingend einen Menüpunkt haben möchte in dem dann aufgeführt wird, dass Assimp genutzt wird.

Daran soll es nicht scheitern … ich denke es waere voellig in Ordnung, sprich in Einklang mit der BSD–Lizenz, wenn der geforderte Hinweis auf Verwendung von Assimp sich auf der letzten Seite des Manuals (oder READMEs), Schriftgroeße 4 befaende :-)

Von meiner Seite sehe ich bei Verwendung in einer Engine die sowieso Open Source ist, grundsaetzlich ueberhaupt keine Lizenzprobleme. Mach was du willst :-)

Kann es sein, dass Assimp mit MDL Dateien mit Bones Probleme hat?

In Ermangelung freier Testdaten, moeglicherweise. Wenn du mir einen Satz geskinnter MDL-Modelle schicken kannst, gucke ich da gerne mal danach. Garantieren kann ich aber nichts, Bones neigen dazu enorm arbeitsintensiv zu sein weil jedes Format sie wieder anders auslegt …

Gruß, Alex

[Aramis]

Ok, … um die anderen Fragen auch noch zu beantworten.

wie ich sie von Assimp bekomme bereits in der Form, in der man sie üblicherweise an OpenGL weitergibt, richtig?

Ja, eben Betonung auf ueblicherweise. Eben genau das ist dein, wie auch unser, Problem: es gibt, was Koordinatensysteme angeht, nur wenig Konsens.

Kann es sein, dass meine Worldmatrix nicht dazu geeignet ist die Normalen in den Worldspace zu transformieren?

Nimm stattdessen die transponierte Inverse der Weltmatrix. Irgendwo im Internet hat es auch ein Paper mit der Erklaerung. Problem ist die Skalierungskomponente – fuer eine reine Rotationsmatrix entspraeche die transponierte Inverse ja wieder der originalen Matrix.

[Slin]

Ich habe jetzt nach ewigkeiten des Herumprobierens ein paar gut funktionierende Klassen. Nur sind z und y Achse, bei dem mit Assimp geladenen bob.md5mesh (aus den Assimp Beispieldateien) vertauscht. Wenn ich allerdings in meiner Spielwelt das Modell entlang der Y Achse verschiebe, handelt es sich durchaus um die Höhe realtiv zu meinem Untergrund und dem Skycube.

wie ich sie von Assimp bekomme bereits in der Form, in der man sie üblicherweise an OpenGL weitergibt, richtig?

Ja, eben Betonung auf ueblicherweise. Eben genau das ist dein, wie auch unser, Problem: es gibt, was Koordinatensysteme angeht, nur wenig Konsens.

Stimmt dieses Statement nicht, oder kann das trotz dem genannten Verhalten so sein? Zum Konvertieren eines Eulerwinkels zu einem Quaternion nutze ich jetzt sogar exakt den gleichen Code wie Assimp und bis auf das vertauschen von Zeilen und Spalten gilt das auch für die Rotationsmatrix, die aus dem Quaternion gebastelt wird. Die Matrix-Vektor und Matrix-Matrix Multiplikation macht auf mich auch einen korrekten Eindruck. Also zumindest stimmen die Ergebnisse (bis auf das verdrehte Modell) und es ist alles so, wie ich es erwarte.

Was in dem Zussamenhang aber komisch ist, ist die Tatsache, dass ich die Reihenfolge der Indizes umdrehen muss, wenn ich z und y vertausche, kann das sein?
Wenn ich aiProcess_makeLeftHanded setze, steht das Modell auf dem Kopf, aber die Indizesreihenfolge von Assimp stimmt dann trotz des Vertauschens, oder gerade wegen des Vertauschens von z und y Achse.
Was bedeutet das für meine Matrix Klasse? Mit der Multiplikation hat das doch nichts zu tun, oder? Erstelle ich eine "falsche" Translationsmatrix, aber da kann man doch nicht viel falsch machen?

Code: Alles auswählen

void sgMatrix4x4::makeTranslate(const sgVector3 &trans)
{
	makeIdentity();
	mat[12] = trans.x;
	mat[13] = trans.y;
	mat[14] = trans.z;
	mat[15] = 1.0;
}

Die Multiplikation sieht so aus:

Code: Alles auswählen

sgMatrix4x4 &sgMatrix4x4::operator*= (const sgMatrix4x4 &other)
{
	sgMatrix4x4 temp(mat);

	mat[0] = temp.mat[0]*other.mat[0]+temp.mat[4]*other.mat[1]+temp.mat[8]*other.mat[2]+temp.mat[12]*other.mat[3];
	mat[1] = temp.mat[1]*other.mat[0]+temp.mat[5]*other.mat[1]+temp.mat[9]*other.mat[2]+temp.mat[13]*other.mat[3];
	mat[2] = temp.mat[2]*other.mat[0]+temp.mat[6]*other.mat[1]+temp.mat[10]*other.mat[2]+temp.mat[14]*other.mat[3];
	mat[3] = temp.mat[3]*other.mat[0]+temp.mat[7]*other.mat[1]+temp.mat[11]*other.mat[2]+temp.mat[15]*other.mat[3];
	
	mat[4] = temp.mat[0]*other.mat[4]+temp.mat[4]*other.mat[5]+temp.mat[8]*other.mat[6]+temp.mat[12]*other.mat[7];
	mat[5] = temp.mat[1]*other.mat[4]+temp.mat[5]*other.mat[5]+temp.mat[9]*other.mat[6]+temp.mat[13]*other.mat[7];
	mat[6] = temp.mat[2]*other.mat[4]+temp.mat[6]*other.mat[5]+temp.mat[10]*other.mat[6]+temp.mat[14]*other.mat[7];
	mat[7] = temp.mat[3]*other.mat[4]+temp.mat[7]*other.mat[5]+temp.mat[11]*other.mat[6]+temp.mat[15]*other.mat[7];
	
	mat[8] = temp.mat[0]*other.mat[8]+temp.mat[4]*other.mat[9]+temp.mat[8]*other.mat[10]+temp.mat[12]*other.mat[11];
	mat[9] = temp.mat[1]*other.mat[8]+temp.mat[5]*other.mat[9]+temp.mat[9]*other.mat[10]+temp.mat[13]*other.mat[11];
	mat[10] = temp.mat[2]*other.mat[8]+temp.mat[6]*other.mat[9]+temp.mat[10]*other.mat[10]+temp.mat[14]*other.mat[11];
	mat[11] = temp.mat[3]*other.mat[8]+temp.mat[7]*other.mat[9]+temp.mat[11]*other.mat[10]+temp.mat[15]*other.mat[11];
	
	mat[12] = temp.mat[0]*other.mat[12]+temp.mat[4]*other.mat[13]+temp.mat[8]*other.mat[14]+temp.mat[12]*other.mat[15];
	mat[13] = temp.mat[1]*other.mat[12]+temp.mat[5]*other.mat[13]+temp.mat[9]*other.mat[14]+temp.mat[13]*other.mat[15];
	mat[14] = temp.mat[2]*other.mat[12]+temp.mat[6]*other.mat[13]+temp.mat[10]*other.mat[14]+temp.mat[14]*other.mat[15];
	mat[15] = temp.mat[3]*other.mat[12]+temp.mat[7]*other.mat[13]+temp.mat[11]*other.mat[14]+temp.mat[15]*other.mat[15];

	return *this;
}

Edit: Ich habe gerade mal ausprobiert was überhaupt was in meiner Spielwelt ist, ausgehend von einer nicht transformierten Kamera.
X nimmt nach rechts zu.
Y nimmt nach oben zu.
Z nimmt zur Kamera hin zu.

[Schrompf]

Das Koordinatensystem hängt nun leider auch noch von ner Menge anderer Sachen ab. Ganz am Ende zum Beispiel von Deiner View- und Projection Matrix. Oder auch von vielen anderen Sachen. Ich möchte jetzt aber auch nicht Deinen Code debuggen - das führt vom Hundersten ins Tausendste. Schnappe Dir einfach mal die Doku Deiner 3D-API und lies nach, wie da das finale Koordinatensystem aussieht. Dann kannst Du von da aus Schritt für Schritt zurückdenken, ob Deine jeweiligen Matrizen eine Transformation ergeben, die am Ende auf diesem Koordinatensystem rauskommt.

MakeLeftHanded müsste eigentlich nicht nötig sein, wenn Deine Zielplattform OpenGL benutzt. OpenGL ES ist glaube ich auch rechtshändig. Demzufolge müsste MakeLeftHanded eigentlich nicht nötig sein. Es kann aber sein, dass Du tatsächlich Z nach oben betrachtest und, anstatt zwei Achsen zu vertauschen, nur eine Rotation anwenden müsstest. Das kann ich aus der Entfernung aber nicht mit Sicherheit sagen... selbst erforschen!