[ASSIMP] Texturen laden ... ?

[Stefan Zerbst]

Ahoi,

nachdem mir mein 3ds Loader mal wieder Ärger gemacht hat habe ich mich endlich dazu durchgerungen mir mal ASSIMP vorzunehmen. Das ging erstaunlich schmerzfrei und das Interface macht einen netten Eindruck. Allerdings kann die Doku diesen Eindruck nicht ganz halten, gerade im Bereich Texturen ;)

Mein Problem ist, dass das Auslesen des Texturpfades fehlschlägt obwohl die Textur eines bestimmten Typs vorhanden sein sollte. Bevor ich mich selber durch ASSIMP grabe hoffe ich auf Erleuchtung durch die Assimpisten was mögliche Ursachen sein könnten:

Code: Alles auswählen

	for (uint32 i=0; i<scene->mNumMaterials; ++i)
	{
		aiMaterial *mat = scene->mMaterials[i];

		// blablablab Farben einlesen blabla ...

		aiTextureType types[] = { aiTextureType_NONE, aiTextureType_AMBIENT, aiTextureType_DIFFUSE, aiTextureType_EMISSIVE, aiTextureType_SPECULAR };
		uint32 num_tex_types = 5;
		aiString path;

		for (uint32 j=0; j<num_tex_types; ++j)
		{
			if (mat->GetTextureCount(types[j]) > 0 && path.length < 1)
			{
				if (!mat->GetTexture(types[j], 0, &path))
				{
					DebugMsg(String("extracting texture path from aiMaterial failed (type ") << j << ", count " << mat->GetTextureCount(types[j]) << ")");					continue;
				}

				break;
			}
		}
	}

Ich begnüge mich damit maximal eine Textur je Material zu laden, egal welcher von den unterstützen Typen das ist. Nun habe ich aber ein Material welches laut GetTextureCount eine Textur vom Typ aiTextureType_DIFFUSE haben sollte. Der Aufruf an GetTexture schlägt aber fehl. Ist das denn grundsätzlich richtig so an die Texturpfade zu kommen? Und unter welchen Bedingungen wird false zurückgeliefert?

Ciao,
Stefan

[Aramis]

Hoi,

freut mich dass du dich an Assimp heranwagst :-)

Mein Problem ist, dass das Auslesen des Texturpfades fehlschlägt obwohl die Textur eines bestimmten Typs vorhanden sein sollte

Ich denke nicht, dass es fehlschlägt ... aiMaterial::GetTexture hat (iirc) als Rückgabewert aiReturn, nicht bool. '0' ist aiReturn_SUCCESS und somit in Ordnung.

[Krishty]

Wenn Return-Codes an dieser Stelle nicht ausnahmsweise daseinsberechtigt wären (Assimps Portierbarkeit etc), dann wäre dieser Fehler ein Lehrbuchbeispiel dafür, warum man Exceptions nutzen sollte :D

[Stefan Zerbst]

Ah ... klarer Fall von kaum macht man's richtig schon geht's :mrgreen:

Dann wäre intensiveres Studium der Doku in diesem Fall doch sinnvoll gewesen. Meine Kritik an der Doku insgesamt bleibt dennoch bestehen, das würde den Einsatz von ASSIMP doch deutlich vereinfachen. Dazu kommt nun noch die Kritik an aiReturn. Wenn man detailliertere Fehlermeldungen braucht dann würde ich tatsächlich auf Exceptions oder Errors-Codes als Rückgabeparameter setzen. Den Rückgabewert einer Methode möchte ich für potenziell fehlschlagende Methode einfach nur als true oder false abfragen können.

Aber das ist alles Kritik auf hohem Niveau, meinen generellen Mesh-Loader werde ich durch ASSIMP wohl auf ein paar wenige Zeilen reduzieren können. Jetzt erstmal eine Woche Urlaub und dann gehe ich mal Skinned Meshes an. Man schauen wie sich ASSIMP dabei anfühlt :)

Ciao,
Stefan

[kimmi]

Allerdings bietet ASSIMP ein natives C-Interface an, um die Portierbarkeit zum Beispiel nach D möglich zu machen. Da gehen dann bedauerlicherweise keine Exceptions. Bei einem puren C++-Interface würden Exceptions in der Tat Sinn machen.

Gruß Kimmi

[Krishty]

Den Rückgabewert einer Methode möchte ich für potenziell fehlschlagende Methode einfach nur als true oder false abfragen können.

Darf ich dazu auch noch einen Rant rauslassen? Sowas ist imo ganz schlechter Stil … weil aus dem Namen der Funktion nicht hervorgeht, was ein zu true oder zu false ausgewerteter Rückgabewert bedeutet. (Dieses Problem hat man bei der WinAPI auch dauernd – manche Funktionen geben TRUE oder FALSE zurück, manche geben die Anzahl bearbeiteter Elemente zurück, und ohne in die Doku zu sehen weiß man nie, ob man auf oder gegen Null testen muss.)

Daher sehe ich das Problem nicht in dem Typ, den die Funktion zurückgibt, sondern darin, dass dieser Typ ohne Mucken zu bool konvertiert wird – hättest du die Fehlermeldung „aiReturn kann nicht zu bool konvertiert werden“ erhalten, hättest du die Stelle sofort zu if(aiReturn_SUCCESS == GetTexture(…)) oder zu if(aiSucceeded(GetTexture(…)) (falls Assimp soetwas bietet) geändert.

Hieße die Funktion, on the other hand, CanGetTexture(), wäre gegen bool nichts einzuwenden … dass diese Funktion überflüssig ist, ist klar, aber dieses Beispiel soll zeigen, worauf ich hinaus will …