[ASSIMP] aiScene > mMeshes > mTextureCoords?

[Eisflamme]

Hi,

ich bastele gerade an meinem kleinen Renderer weiter, der auf Assimp aufbaut. Ich kann halt jetzt Meshes schon laden und alles klappt so weit. Mein Problem sind aber die Texturkoordinaten, die in den Meshes vom aiScene-Objekte gespeichert werden. In der Doku steht ja, die Anzahl der mTextureCoords würde mNumVertices entsprechen. Aber das Array hat nur die Länge 1 und daher dumpt der Zugriff auf das zweite Element.

Mit dem AssimpViewer kann ich das Modell allerdings rendern. Ich habe dort Mal reindebuggt und sehe in der geladenen aiScene bei mTextureCoords auch nur ein Element.

Ich habe länger im AssimpViewer debuggt aber finde leider nicht die Stelle, wo die Texturkoordinaten angewandt werden. Vermutlich habe ich nen grundsätzlich Verständnisfehler, könnte mich jemand aufkläre? :)

Danke im Voraus!
VIele Grüße

[kimmi]

Du bist dir bewußt, das mTextureCoords die Texturkoordinaten in einem 2-dimensionalen Array speichert? Such doch im AssimpViewer einfach per Search nach m_TextureCoords und schau dir an, wie das dort gelöst wurde.
Ansonsten kannst du auch in der ZFXCE mal schauen, wie dort auf den Textur-Kram zugegriffen wird:
http://zfxce.git.sourceforge.net/git/gi ... 71;hb=HEAD ab Line 295.

Gruß Kimmi

[Schrompf]

aiMesh::mTextureCoords ist ein Array aus Texturkoordinaten-Arrays. Also ein Doppelzeiger. Jeder Mesh kann bis zu 4 verschiedene Sets an Texturkoordinaten haben. Jedes der Texkoord-Arrays ist dann mNumVertices groß, falls der Zeiger nicht NULL ist. Du wirst üblicherweise nur den ersten haben wollen, alle weiteren sind sehr selten.

Code: Alles auswählen

aiVector3D* texkoords = mesh->mTextureCoords[0];
for( size_t a = 0; a < mesh->mNumVertices; ++a)
  KopierMirDieTexKoords( texkoords[a]);

[Eisflamme]

Oh...
Ich muss multidimensionaler denken. :) Vielen Dank! Jetzt habe ich eine teilweise Anzeige. Leider sind ein paar Dreiecke jetzt nicht mit Textur belegt / es werden wohl keine Coords genutzt, obwohl die Anzahl der Coords == Anzahl der Vertices ist. Aber Mal schauen!

Danke!

[Schrompf]

Das kommt dann drauf an, wie Du sie verwendest. Benutzt Du einen Index-Buffer? Das solltest Du unbedingt, vor allem in Verbindung mit dem PPStep JoinUniqueVertices. Zeig mal Deinen Rendercode. Bzw. den Code, wie Deine Vertexstruktur aussieht und wie Du den Vertex- und IndexBuffer belädst.

[Eisflamme]

Hi,

Also ich kann halt zwischen VBO-Buffereinsatz hin- und hershiften. Die VBOs habe ich gerade deaktiviert. Ich weiß jetzt gar nicht, ob man das, was ich jetzt mache, IndexBuffer nennt, aber nachfolgend einfach Mal der Code.

Also zur Zeit habe ich testweise Mal meine OpenGL VBOs deaktiviert, d.h. ich habe einfach ein Array von Vertices und ein Array von Indices.

Hier der Rendervorgang:

Code: Alles auswählen

			// Set The Vertex Pointer To Our Vertex Data
		   glVertexPointer(3, GL_CoordinateType, 0, vertices_);

		   // Set The Color Pointer To Our Color Data
		   glColorPointer(3, GL_ColorType, 0, colors_);

		   // Set The Texture Coordinate Pointer To Our Texture Coordinate Data
		   glTexCoordPointer(2, GL_TextureCoordinateType, 0, textureCoordinates_);

		   // Set The Normal Pointer to our Normal Data
		   glNormalPointer(GL_NormalCoordinateType, 0, normals_);

		   if(indexCount_)
		   {
			   if(count)
				   glDrawElements(GL_TRIANGLES, count, GL_IndexType, indices_ + offset);
			   else
				   glDrawElements(GL_TRIANGLES, indexCount_, GL_IndexType, indices_ + offset);
		   }

indexCount_ ist hier > 0 und count, offset sind hier auch 0 (die Parameter wären für partielles Rendern bei mehreren Meshes nötig). GL_TextureCoordinateType ist GL_FLOAT, textureCoordinates_ ist vom Typ her eine Klasse mit zwei Floats (u,v).

Ich hatte auch schon die Vermutung, dass die Indices zu Problemen führen können... Freue mich über alle Ideen!

Viele Grüße

[kimmi]

Das grundlegende Rendern sieht Ok aus. Die States sind wahrscheinlich die problematische Ecke, wenn du dir die gesetzten Textur-Koordinaten angesehen hast ( wovon ich jetzt mal ausgehe ). Also:
Wie schaltest du die Texturen aktiv? Da jedes Mesh jeweils nur ein Material hat, mußt du das je Mesh vorher mit glEnable und glBindTexture für die Texturkoordinaten des mit glActiveTexture aktiv geschalteten Texturlevels setzen.

Gruß Kimmi

[Eisflamme]

Hi,

Also mein eigentlicher Algorithmus geht über alle Meshes, schaut je Mesh, welche Textur genutzt wird, und bindet die, also so, wie Du sagst. In meinem Beispielmodell habe ich jetzt allerdings nur ein einziges Mesh und auch nur eine Textur. Aus Debugginggründen setze ich die halt gerade hart vor dem Rendervorgang, d.h. ich habe:

Code: Alles auswählen

glBindTexture(GL_TEXTURE_2D, textureID_);

in meiner Texturklasse drin.

Code: Alles auswählen

glEnable(GL_TEXTURE_2D);

führe ich am Anfang meiner Applikation aus, sonst nutze ich kein glEnable.

Zum Teil wird die Textur ja auch angezeigt. Auf ein paar hundert Polygone sieht alles perfekt aus, aber ein paar Bereiche bleiben halt leer, d.h. haben lediglich die Grundfarbe.

[kimmi]

Konnten die Textur-Daten dort geladen werden? Also findet deine Anwendung die zugehörigen Images? Und wenn du nur 2D-Texturen benutzt, reicht natürlich ein glEnable-Call für alle, da hst du recht.

Gruß Kimmi

[Eisflamme]

Ja, also die Textur wird gefunden und ja auch zum großen Teil richtig angezeigt, nur ein paar Polygone bleiben leer. Ich habe mir das Modell auch Mal Polygon für Polygon aufbauen lassen. Ergebnis: Es fehlen zwischendurch Mal ein paar TexturCoords, nicht einfach am Ende oder so...

Allerdings sehen die Teile des Modells, wo die Textur drauf ist, anders aus als bei dem in AssimpViewer geladenen Modell, also ist das vll. noch irgendwie falsch verteilt.

Hab Mal nen Screenshot gemacht:

http://yfrog.com/6xscreenshotbznj

[kimmi]

Du renderst die Assimp-Daten direkt oder kopierst du die Modelldaten noch in eine eigene Mesh-Klasse von dir um?

Gruß Kimmi

[Schrompf]

Die Texturen sind schnuppe... die funktionieren ja offensichtlich, wenn Teile des Meshes eine Textur zeigen. Dein Rendercode aber passt nicht. Du benutzt gar keine Indizes. Indizes werden dazu verwendet, Vertizes wiederzuverwenden. Ein Rechteck zum Beispiel bestände aus 4 Vertizes für die vier Ecken und 6 Indizes, die jeweils angeben, aus welchen der vier Vertizes die zwei Dreiecke für das Rechteck aufgebaut sind. Also meinetwegen (0, 1, 2) und (1, 3, 2). Diese Indizes packt man üblicherweise in einen IndexBuffer, schön nacheinander jeweils drei Stück für ein Dreieck.

Assimp produziert von Haus aus erstmal nicht-indizierte Meshes. Das heißt, dass die Vertizes genau in der Reihenfolge auftauchen, in der die Dreiecke ihre Ecken benötigen. Dann gibt es natürlich auch viele Vertizes mehrfach im VertexBuffer. Assimp spuckt dann zwar immernoch einen IndexBuffer aus, aber der enthält dann nur noch linear steigende Dummy-Indizes in der Art (0, 1, 2), (3, 4, 5), (6, 7, 8) und so weiter. Wenn Du jetzt als Post Processing Step "JoinUniqueVertices" mit angibst, geht Assimp über die Meshes drüber und sucht solche doppelt auftauchenden Vertizes. Alle Dopplungen werden entfernt und der IndexBuffer wird angepasst, so dass die Dreiecke auf das Orginal anstatt die Dopplung verweisen. Das erspart ein Stück VideoSpeicher und kann auch Performance bringen, besonders in Verbindung mit dem OptimizeForVertexCache-PPStep.

Ich würde Dir aber auch abseits der Performance-Betrachtungen empfehlen, dass Du immer die indizierte Variante benutzt. Primär, weil ich gerade ziemliche Bedenken habe, ob der Triangulate-Step tatsächlich auch korrekt die Vertizes verdoppelt, wenn er Polygone in Dreiecke aufspaltet.. :-)

Ich kenne mich mit OpenGL und diesen Array-Funktionen nicht so aus, aber ich empfehle Dir, mal nach einer vergleichbaren Funktion zu suchen, die z.B. glIndexPointer oder so heißt. Du wirst dazu dann wahrscheinlich auch einen alternativen Zeichenaufruf brauchen, der z.B. glDrawIndexedElements heißen könnte. Schau mal in die Doku, ob es solche Funktionen gibt und was für Parameter die nehmen. Mit denen müsste der Mesh dann korrekt aussehen.

[Eisflamme]

Hi,

Die Assimp-Daten bastel ich mir in meine eigenen Strukturen. Normalenvektoren klappen beispielsweise ja auch, was man an der richtigen Beleuchtung sehen kann. Auch Farbwerte kann meine Klasse korrekt einbinden, sodass ich glaube, dass mein Rendervorgang eigentlich stimmt. Er klappt ja immer, nur halt nicht bei den Texturkoordinaten.

Also ich benutze gerade schon Indizes. Ich habe halt ein Array von denen und ich habe ein Array von Vertices. mit glDrawElements zeichne ich halt die Vertices, auf welche die Indizes verweisen, ganz wie es halt gedacht ist. Mein Mesh wird ja auch korrekt dargestellt, daher bin ich nicht sicher, ob ich jetzt das Problem verstanden habe.

Als postprocessing-Option gibt es bei mir nur "aiProcess_JoinIdenticalVertices" oder meinst Du etwas anderes? Und was ist OptimizeForVertex-PPStep? :)

Ach und die Polygone spaltet er in Dreiecke auf, weil ich ihm das Postprocessing-Ding übergeben habe, weil ich es einfacher

[kimmi]

@Schrompf: Hiermit macht Eisflamme einen Drawcall mit Indices:

Code: Alles auswählen

glDrawElements(GL_TRIANGLES, indexCount_, GL_IndexType, indices_ + offset);

Man beachte dabei indexCount_. Wenn der > 0 ist, wird der Code von Eisflamme mittels Indices gerendert ( siehe auch http://www.opengl.org/sdk/docs/man/xhtm ... ements.xml ).
Wenn nicht überall Textur-Kooridinaten vorhanden sind und das Originalmodell diese korrekt hält, tippe ich auf einen Bug ikm Kopier-Vorgang.
Kannst ja mal etwas von dem Code diesbezüglich zeigen.

Gruß Kimmi

[Eisflamme]

Hi,

Ich habe den Fehler gefunden. Das Problem lag tatsächlich in meiner Kopiermethode, aber irgendwie raff ich das nicht... Ich hab mir Mal alle uv-Koordinaten ausgeben lassen und die Ausgabe zeigt, dass der v-Wert zwischen 1.0f und 2.0f liegt!? Ich habe Mal spaßeshalber -1.0f gemacht und siehe da: perfekt!

Kann mir einer erklären, wieso assimp mir solche Werte liefert? :)

[Schrompf]

Assimp liefert solche Werte, wenn das Orginalfile solche Werte enthielt. Evtl. hast Du bei der Anzeige den WrapMode nicht ordentlich eingestellt. Man sollte bis auf vereinzelte Ausnahmen immer WRAP benutzen, nicht CLAMP, MIRROR oder wie sie sonst noch alle heißen.

[Eisflamme]

Moment, was hat die Anzeige denn genau damit zu tun? Wrapmode habe ich m.W. nicht geändert.

[Schrompf]

Das soll heißen, dass Texturkoordinaten auch problemlos den 0bis1-Bereich verlassen können... das ist ok. Der Texkoord-WrapMode bestimmt, wie die Grafikkarte Texturkoords außerhalb dieses Bereiches interpretiert. Ich habe keine Ahnung, was bei OpenGL das Default Setting dafür ist... daher empfehle ich, mal auszuprobieren, ob das direkte Setzen des WrapModes auf Repeat, Wrap oder wie auch immer das Ding bei OpenGL heißt, was hilft.

[kimmi]

Hier kannst du die entsprechenden OpenGL-State Setterei nachlesen:

http://www.flipcode.com/archives/Advanc ... ping.shtml

Wie die Default-Werte sind, weiß ich auch gerade nicht. Müßtest du da hoffentlich finden.

Gruß Kimmi

[Eisflamme]

Okay, aber wozu sind die Koordinaten denn größer als 1? Und wieso ist nur die v-Koordinate zwischen 1 und 2, während die u-Koordinate zwischen 0 und 1 liegt? Es gibt da keine Ausnahmen.

Also für mich sieht das etwas seltsam aus und ist Repetition der Textur nicht auch geringfügig aufwendiger als wenn man im normalen Bereich bleibt?

[Schrompf]

Texturkoordinaten können praktisch xbeliebige Werte annehmen. Und es ist in Performance-Hinsicht vollkommen schnuppe, in welchem Zahlenbereich sie liegen.