Assimp

[dk*82]

hej leute,

kann mir vielleicht jemand erklären, wie ich assimp mit visual studio 2010 "verwende"?
auf der doku-seite von assimp steht nämlich, dass die pre-compiled libs lediglich für Visual C++ 2005 und 2008 verwendet werden können. wie muss ich nun bei VS 2010 vorgehen?
die dokumentation von assimp selbst und das PDF auf der CG-wiki-seite sind (für mich) nicht gerade hilfreicht, da ich bisher noch keine erfahrung mit C++ und mit visual studio habe. das ist alles ein bischen viel neues auf einmal

doku: http://assimp.sourceforge.net/lib_html/index.html
PDF: https://lva.cg.tuwien.ac.at/cgue/wik...nts:assimp.pdf

für eine schritt-für-schritt-anleitung wäre ich überaus dankbar
dominik

[Peachman]

Hallo dominik, folgende Schritte sollten dich zum Ziel führen:
1. Von der offiziellen Homepage den obersten Release assimp 2.0 für Any Platform herunterladen und in den Folder für deine external libs entpacken.
2. Bei den Project Properties in VS2010 unter "C/C++" > "General" bei "Additional Include Properties" eine Zeile hinzufügen die auf den "include" folder von assimp zeigt, ungefähr so:
"$(SolutionDir)external\assimp--2.0.863-sdk\include"
3. Unter "Linker" > "General" bei "Additional Library Directories" die win32 release libraries hinzufügen, ca. so: "$(SolutionDir)external\assimp--2.0.863-sdk\lib\assimp_release-dll_win32". Ich hab das für Debug und Release Konfiguration eingebunden, obs mit Debug library und win64 auch geht weiß ich nicht, einfach probieren.
4. Unter "Linker" > "Input" bei "Additional Dependencies" die Library "assimp.lib" zusätzlich einbinden.
5. Nach deinem ersten Build muss noch die Assimp32.dll (von (assimpdir)/bin/assimp_release-dll_win32) in den Ordner kopiert werden, wo VS2010 deine .exe hinspeichert, also typischerweise unter (solutiondir)/Debug.

lg
Christian

[Getshi]

ich hab etwas schwierigkeiten dabei model data einzulesen

void loadModelData(const string file) {
//Load file
Assimp::Importer importer;
const aiScene* scene = importer.ReadFile(file,
    aiProcess_CalcTangentSpace |
    aiProcess_Triangulate |
    aiProcess_JoinIdenticalVertices |
    aiProcess_FlipUVs     );
 if(!scene) {
   std::cerr << "assimp: importer.readfile failed to read the file!" <<endl;
}
//......

Es scheitert schon an ReadFile danach ist die scene nämlich null, aber der filepath sollt eig passen den ich angeb und viel mehr rückmeldung als access violation wo scene dann gebraucht wird bekomm ich nicht =/

außerdem wollte ich fragen wie man das am besten struktuiert, ich hab daweil das (fail)modelloading in einem eigenn cpp und hpp file und der legt ja vertices und indices laut folien vom wiki am heap an, wie bekomm ich die jetzt von dort wieder in mein main programm nach c++-best-practice (was ich als anfänger nicht beherrsche)? und danach muss mans auch wieder intelligent löschen können, muss ich dann die daten global im model.cpp file speichern und mit ner 2. function explizit löschen? oder muss man das main programm noch länger machen als es eh schon ist damit man alles dort zu verfügung hat. ich hoffe das ergibt gerade irgendeinen sinn

ah.. und soll man dieses struct wo die normals, positions etc drin sind mit glm vektoren oder mit assimp vektoren machen, daweil speicher ich die geholten assimp auf glm um

[ClemensRoegner]

Eine Moeglichkeit, wenn du eine Klasse hast, die deine gesamte Szene repraesentiert:
In dem Konstruktur dieser Klasse laedst du mit Assimp deine Daten und befuellst die Szene.
Im Destruktur baust du ne Routine, welche deine Daten wieder loescht.
In der Main erstellst du dann eine Instanz der Klasse und rufst dann (wenn notwendig) den Destruktur auf.

struct: ich wuerde glm vektoren verwenden

Hoffe, das hilft.

[mOfl]

Das Debugging, wenn ReadFile scheitert, ist in der Tat etwas schwer. Verwendest du einen relativen oder absoluten Pfad? Wenn relativ, mach mal einen absoluten Pfad daraus. Es gibt auch einige nicht offensichtliche Bedingungen in ReadFile, auch durch bestimmte Import Flags, z.B. eine maximale Anzahl an einzelnen Meshes oder eine Obergrenze an Vertices pro Mesh (obwohl die irgendwo bei 4 Millionen liegt, das sollte bei dir nicht das Problem sein). In jedem Fall gibt ReadFile einfach NULL zurück. Zwei Sachen kannst du prüfen:
- ReadFile mit 0 als zweitem Parameter aufrufen, also keine Import Flags verwenden
- Das Model mit dem AssimpViewer (gibt es separat auf http://assimp.sourceforge.net/main_downloads.html) öffnen. Wenn es da nicht geht, kann Assimp die Datei nicht lesen.

Allgemein ist es mehr als eine Überlegung wert, Assimp vom SVN (Daten gibts auch unter obigem Link) runterzuladen und zu kompilieren, immerhin ist die letzte Stable Version anderthalb Jahre alt und es hat sich einiges getan seither. Also es kann gut sein, dass irgendwelche Import-Bugs oder so gefixt wurden.

[Getshi]

Eine Moeglichkeit, wenn du eine Klasse hast, die deine gesamte Szene repraesentiert:
In dem Konstruktur dieser Klasse laedst du mit Assimp deine Daten und befuellst die Szene.
Im Destruktur baust du ne Routine, welche deine Daten wieder loescht.
In der Main erstellst du dann eine Instanz der Klasse und rufst dann (wenn notwendig) den Destruktur auf.

struct: ich wuerde glm vektoren verwenden

Hoffe, das hilft.

meinst du mit szene jetzt eine aiScene sprich ein model oder ein spiellevel oder ein ganzes spiel? ich nehm jetzt mal an ein level, wo man beim erstellen/öffnen alle benötigten models lädt. und wie benutze ich die daten dann - eine draw methode machen die alles für die szene übernimmt, also alle benötigten vaos enablen, zeichnen etc?

@mOfl das mit dem readfile hab ich gerade bemerkt war zum glück nur ein dummer fehler von mir, hab mir modelfile und modelpath als 2 strings gespeichert und dann addiert, aber ich hab statt dem modelpath bei mir den texturepath verwendet. also das einlesen stürzt jetzt nicht mehr ab. msus aber jetzt erst noch schaun ob ichs wirklich anzeigen kann. aber danke!

[ClemensRoegner]

meinst du mit szene jetzt eine aiScene sprich ein model oder ein spiellevel oder ein ganzes spiel?

Also eigtl solltest du in deinem Spiel fuer ein Level(=Szene) eine eigene "Verwaltung" haben. "Verwaltung" kann dann im Endeffekt vieles sein (Scenegraph,...). Diese "Verwaltung" der Szene und der darin enthaltenen Modelle solltest du dir selbst machen (an deine Anforderungen abgepasst). Assimp liefert dir mit aiScene nur ein Konstrukt welches das File beschreibt, das du geladen hast. Sprich das Assimp-Zeug solltest du eigtl nicht zum Rendern verwenden, sondern dir deine eigenen Klassenstruktur, die dir dein Level beschreibt basteln. (uebrignes die Assimp-Klassenstruktur ist an Collada angelehnt). Also das aiScene ding nur zum Daten auslesen verwenden.

ich nehm jetzt mal an ein level, wo man beim erstellen/öffnen alle benötigten models lädt. und wie benutze ich die daten dann - eine draw methode machen die alles für die szene übernimmt, also alle benötigten vaos enablen, zeichnen etc?

Hier gibt es natuerlich auch einige Moeglichkeiten. Du kannst natuerlich eine draw Methode schreiben, die alles fuer dich macht. Ob das sinnvoll ist, haengt davon ab wie Komplex das Spiel im Endeffekt sein wird (weil bei zu Komplexen Spielen die Methode explodiert und du nicht mehr weisst wo vorne und hinten ist.)
So, was ich dazu bis jetzt geschrieben habe, hilft dir natuerlich noch nicht weiter. Du stehst, wie vielleicht einige andere hier, vor dem grossen und sehr wichtigen Problem der Strukturierung eures Programms. Wie du das am Besten machst, haengt von deinen Anforderungen ab (wie oben bereits erwaehnt - vl kannst du dir schon denken dass deine draw-Routinen in der Klassenstruktur, welche die Szene beschreibt, gut aufgehoben sind. sie muessen aber nicht unbedingt dort sein). Ums kurz zu machen: Sprich bitte mal mit den Tutoren von Angesicht zu Angesicht darueber. Das ist mMn der einzig gute Schritt den du nun machen kannst. Beschreib' ihnen dein Spiel, also deine Anforderungen, und sie werden dir helfen die Klassenstruktur aufzubauen (und mach das bitte schnell - viel Zeit hast du nicht mehr).

P.S.: ich stehe leider atm nicht zur verfuegung, da ich nicht im Lande bin

[Getshi]

hmmm hab eine neue frage, ich hab den code wie in den folien versucht nachzubauen und da hat man ein structarray für alle vertexdaten (pos, normals, ....)
wie benutz ich das jetzt für die VBOs.


glBufferData(GL_ARRAY_BUFFER, model_vertices_size, model_vertices->pos, GL_STATIC_DRAW);

Das funktioniert natürlich so nicht, weil er über model_vertices iterieren muss udn von den einzelnen dann pos nehmen und ned über pos vom ersten. meine frage ist jetzt wie ich aus diesem structarray mir alle positionen als einzelnes array herausfilter. wenn das nicht wirklich geht ohne mühsam herumzukopieren dann wäre der code ja nicht wirklich sinnvoll oder?
ich könnt auch noch viel mehr pointer übergeben als nur 1 für indicesarray und 1 für structarray, halt für alles einzeln, pos normals, tangent, bitangent ,... aber das scheint mir auch ned das wahre zu sein
--EDIT
mit manuellem rauskopiern hab ichs mal probiert damit ich herumprobieren kann, aber ich krieg genau 3 buggy dreiecke aus dem model raus =/ und die assimp tutorials die ich finde haben alle extrem langen code und geben mir dadurch wenig einsicht

[mOfl]

Der Code in den Folien erzeugt ein großes Struct-Array "vertices", bei dem alle Attribute zu einem Vertex gespeichert werden, also das ist eine sehr lange Wurst, wo alle Vertices jeweils den Abstand sizeof(Vector4) + 3 * sizeof(Vector3) + sizeof(Vector2) haben. Diese Form von Buffer heißt interleaved. Der Vorteil ist, dass du nur einen einzigen Buffer brauchst, der Nachteil ist, dass es komplizierter zu handhaben ist als separate Buffer. Da du in Assimp in der aiScene ja abfragen kannst, wie viele Vertices dein Mesh hat, kannst du statt eines interleaved VBOs auch gleich zu Beginn separate Arrays für alle Attribute mit der Größe mNumVertices erstellen und einzelne Buffer verwenden - das bleibt dir überlassen.

Wenn du den Code so verwenden willst wie in den Folien, dann gibst du als Größe der einzelnen Elemente sizeof(sStdGeomVertex) an und die Position ist das Array selbst, in den Folien vertices. Du musst dich jetzt darum kümmern, dass die einzelnen Attribute auch an der richtigen Stelle im Shader ankommen. Dafür verwendest du glVertexAttribPointer, das erwartet einen Parameter stride, also die Schrittweite von einem Element zum nächsten, was genau der Größe des Structs entspricht. Zusätzlich gibst du noch ein Offset zum ersten Element des jeweiligen Attributs im Buffer als pointer an.

Wenn du nach interleaved VBO googlest, werden dir übrigens relativ oft die Funktionen glVertexPointer, glColorPointer, glNormalPointer, glTexCoordPointer u.ä. unterkommen - die dürft ihr für die Übung nicht verwenden, da sie deprecated sind. Also solchen Sample-Code am besten gar nicht anschauen. Es gibt auf der OpenGL-Seite ein paar gute Tutorials, auch eins für Interleaved VBOs ohne Deprecated Calls.

[Getshi]

aahhh. okay nur damit ich das jetzt richtig verstehe:

ich benutze nurnoch ein vbo, das ich mal generiere und binde, mit bufferdata buffer ich dann das ganze structarray "model_vertices" und sag im als size nur sizeof(sStdGeomVertex) und danach weise ich die gebufferten datan alle mit mehreren vertexattrib calls zu also mehrmals hintereinander glVertexAttribPointer mit verschiednen offsets aber immer dem gleichen stride.

wie zeichne ich dann damit, ganz normal mit (GL_TRIANGLES, 0, numVertices) ? ich nehm an die indices muss man auch noch intelligent verwenden =/
ich hoffe ich stelle nicht zu viele unnötige fragen, sollte ich der einzige sein der sich damit schwer tut

[mOfl]

ich benutze nurnoch ein vbo, das ich mal generiere und binde, mit bufferdata buffer ich dann das ganze structarray "model_vertices" und sag im als size nur sizeof(sStdGeomVertex) und danach weise ich die gebufferten datan alle mit mehreren vertexattrib calls zu also mehrmals hintereinander glVertexAttribPointer mit verschiednen offsets aber immer dem gleichen stride.

Genau.

wie zeichne ich dann damit, ganz normal mit (GL_TRIANGLES, 0, numVertices) ? ich nehm an die indices muss man auch noch intelligent verwenden =/
ich hoffe ich stelle nicht zu viele unnötige fragen, sollte ich der einzige sein der sich damit schwer tut

Das Zeichnen sollte eigentlich gar keinen Unterschied machen zwischen interleaved und normal. Die Indices sind ja von den Attributen unabhängig, also wenn du dir einen Index-Buffer erstellst, dann kannst du zum Zeichnen glDrawElements(GL_TRIANGLES, numIndices, GL_UNSIGNED_INT, NULL) verwenden. Den Index-Buffer pro Mesh erstellst du dir, indem du über die Faces des Meshs in der Assimp-Struktur iterierst und einfach die jeweils drei Indices in ein Array rausschreibst. Wenn du ohne Indices auskommst, dann sollte glDrawArrays(GL_TRIANGLES, 0, numVertices) korrekt sein.

[Getshi]

Also ich bekomm zwar keine fehler aber schwarz ist trotzdem alles, und ich vermute dass es was mit stride zu tun hat. in der doku steht etwas von byte offset, aber wie soll ich wissen wieviele byte ein struct mit mehreren glm vectors denn hat?
ich versuch gerade nur die position einzulesen und das model anzuzeigen und hab dafür im vertex shader location 0 für position (vec4) , welche ich auch mit glEnableVertexAttribArray(0) aktiviere (wobei ich mir eig noch immer nicht sicher bin trotz google etc. wann ich diese methode genau brauche)
im fragment shader sag ich ihm einfach er soll mir mal weiß anzeigen testhalber, aber ich seh nix =/ der array buffer offset macht mich auch etwas stutzig

glVertexAttribPointer( 0, // attribute 0 in vertex shader
4, // size
GL_FLOAT, // type
GL_FALSE, // normalized?
(4+3+2+3+3), // stride //not 0 because of struct
(GLvoid*)0 // array buffer offset
);

[BDL!]

Hallo,

Wenn deine Position die ersten 4 floats in deinem Strukt sind sollte der Array-Offset passen.
Anmerkung: statt (4+3+...) kannst du sizeof(DEINSTRUCT) verwenden.

[mOfl]

in der doku steht etwas von byte offset, aber wie soll ich wissen wieviele byte ein struct mit mehreren glm vectors denn hat?

sizeof(glm::vec4) sizeof sagt dir, wie viele Bytes ein Datentyp hat, das geht auch für Structs. Du musst bei Structs aber aufpassen, weil das afaik immer für 4-Byte-Blöcke optimiert wird, d.h. die Summe der einzelnen Vektoren ist nicht zwingend gleich der Größe des ganzen Structs, dazu hier eine kurze Erklärung: http://stackoverflow.com/questions/1...of-each-member

ich versuch gerade nur die position einzulesen und das model anzuzeigen und hab dafür im vertex shader location 0 für position (vec4) , welche ich auch mit glEnableVertexAttribArray(0) aktiviere (wobei ich mir eig noch immer nicht sicher bin trotz google etc. wann ich diese methode genau brauche)

Der Buffer hat erstmal überhaupt nichts mit dem Shader zu tun, das sind einfach Daten im Videospeicher. Willst du die im Shader verwenden, musst du dich selbst darum kümmern. Im Vertex Shader kannst du eingehende Attribute bestimmen, die ihre Daten aus dem Buffer nehmen, aber dazu musst du das jeweilige Attribut im Shader mit dem Buffer verknüpfen. Dafür hast du mehrere Möglichkeiten:
- Du gibst die Indizierung der Attribute explizit im Shader vor:

layout(location = 0) in vec4 inPosition;

- Du gibst die Indizierung explizit vor dem Linken des Shaders vor:

glBindAttribLocation(shaderHandle, 0, "inPosition");

Danach kannst du den Buffer mit dem Attribut verbinden (mit entsprechenden Parametern für deinen interleaved Buffer dann halt):

glEnableVertexAttribArray(0);
glVertexAttribPointer(0, 4, GL_FLOAT, GL_FALSE, 0, 0);

So, das Problem ist aber, dass die explizite Indizierung relativ unübersichtlich wird, wenn du mal ein paar Attribute hast, eventuell merkst, dass du ein Attribut nicht mehr brauchst, dafür aber zwei andere, dann noch einen Shader für mehrere Objekte verwenden willst, ... Deshalb empfiehlt es sich grundsätzlich, sich damit nicht rumzuschlagen, sondern nur über den Namen auf Attribute zuzugreifen (ebenfalls wieder eigene Parameter für stride verwenden):

int positionIndex = glGetAttribLocation(shaderHandle, "inPosition");
 
glEnableVertexAttribArray(positionIndex);
glBindBuffer(GL_ARRAY_BUFFER, positionVboHandle[i]);
glVertexAttribPointer(positionIndex, 3, GL_FLOAT, GL_FALSE, 0, 0);

Ich hoffe, so wird das etwas klarer. Der Sinn von glEnableVertexAttribArray ist, Attribute Location im Shader und Buffer zu verbinden.

der array buffer offset macht mich auch etwas stutzig
glVertexAttribPointer( 0, // attribute 0 in vertex shader
4, // size
GL_FLOAT, // type
GL_FALSE, // normalized?
(4+3+2+3+3), // stride //not 0 because of struct
(GLvoid*)0 // array buffer offset
);

Ja, der Stride hier stimmt nicht, weil das ein Wert in Bytes sein sollte, d.h. du müsstest alles noch mit 4 bzw. mit sizeof(float) multiplizieren, da ein Float 4 Bytes hat.

[Getshi]

also ich bekomm immer nur schwarz trotz allen tipps hier. allerdings funktionierts mit nicht ausgelesenen daten...

glBufferData(GL_ARRAY_BUFFER, sizeof(sStdGeomVertex),
model_vertices, GL_STATIC_DRAW);
//....
glVertexAttribPointer(
0, // attribute 0 in vertex shader
4, // size
GL_FLOAT, // type
GL_FALSE, // normalized?
sizeof(sStdGeomVertex), // stride //not 0 because of struct
(GLvoid*)0 // array buffer offset
);

funktioniert nicht, hingegen ein würfel mit manuell getippten vertices funktioniert mit folgendem

glBufferData(GL_ARRAY_BUFFER, sizeof(g_vertex_buffer_data),
g_vertex_buffer_data, GL_STATIC_DRAW);

glVertexAttribPointer( 0, // attribute 0 in vertex shader
3, // size
GL_FLOAT, // type
GL_FALSE, // normalized?
0,//sizeof(sStdGeomVertex), // stride //not 0 because of struct
(GLvoid*)0 // array buffer offset
);

---EDIT

huch.. wenn ich die size beim bufferdata ändere bekomm ich wenigstens wilde dreiecke

glBufferData(GL_ARRAY_BUFFER, sizeof(sStdGeomVertex)*model_vertices_size,
model_vertices, GL_STATIC_DRAW);

[BDL!]

Hallo,

glBufferData(GL_ARRAY_BUFFER, sizeof(sStdGeomVertex),
model_vertices, GL_STATIC_DRAW);

Ich glaube da passt die Größenangabe nicht. sizeof(sStdGeomVertex) liefert dir die Größe deines Strukts in Byte zurück. Hier musst du aber die Gesammtgröße der Daten angeben die du an OpenGL sendest. Also irgendwas wie sizeof( sStdGeomVertex ) * vertexCount.

Edit: Du kannst mal mit gDebugger überprüfen ob die korrekten Daten im VBO stehen, dann kann man das mal als Fehlerquelle ausschließen.

[Getshi]

also größenangabe hab ich geändert, siehe edit oben. allerdings bis ich mit gdebugger was herausfinde würds lang dauern, hab nach visual studio extension gesucht und da gibts die amd version der sagt mir aber etwas von kernel debugging ist nicht möglich und viel info zeigt er mir auch nicht.

aber das model kann im assimpviewer normal angezeigt weredn und so hol ich mir die positionen


const struct aiMesh* mesh = scene->mMeshes[0];

aiVector3D getpos = mesh->mVertices[i]; vertices[i].pos = vec4(getpos.x, getpos.y, getpos.z, 1.0f);da sollte doch dann kein fehler drin sein

[mOfl]

Du hast ja geschrieben, dass dein hardcoded Würfel-Beispiel funktioniert. Versuch doch mal, dich von da langsam an einen interleaved Buffer heran zu tasten, also speicher z.B. mal zu den Positionen noch Normalen und schau, ob du es dann noch zum Laufen bekommst. Das sollte sich im gDEBugger auch einfach debuggen lassen.

[Getshi]

also ich hab den hardcoded würfel mal auf homogene koordinaten geändert, immernoch hardcoded, passt.
ich hab die daten mit nonsense daten interleaved (weil ich eig nurmal schaun will das vertex funktioniert und ich das endlich check) nach folgendem musster,
v1x v1y v1z v1w a1 a2, v2x .... die nonsense daten sind 5.0f also ist es ca so 1, 1, 1, 1, 5, 5, .. -1, -1, 1, 5, 5 .. in der art
die daten passen wie ich sie interleaved hab, manuell überprüft.

es sind beim würfel 3*2*6 vertices und daher 216 floats insgesamt.
im gdebugger wenn ich mir das vbo anschaue, dann passt die größenangabe mal, weil es sind 216 plätze da, alelrdings sind 90% davon mit floatminimum oderwasähnlichem befüllt also -1,0737418e+008
die ersten 41 plätze sind nicht dieser wert sondern mehr oder weniger random -1 und 1 wobei der 40. und 41. sind 5 .. das ganze ist mal ohne stride eignestellt bei den anzeigeoptionen, d.h. eig sollte es wie oben beschrieben aussehen =/
und egal wie ich bei gdebugger vbo anzeige mit stride und offset spiele ich schaff es weder gscheit die vertex daten noch die nonsense daten zu separieren, egal was ich tu es werden eig nur mehr -1.07
-----EDIT
ah nvm ich seh grad einen gröberen fehler bei mir - beim erstellen des interleaved data ersetz ich immer die letzten 4 weil ich nur 1 schritt weitergeh, zeig aber nur die neuen an zum vergleich deswegen hats ok ausgeschaut
------EDIT2

also ich kanns im debugger jetzt mit stride 8 auf die richtigen vertex daten einschränken, d.h. die richtigen daten sind mal im vbo nehm ich stark an.
allerdings gezeichnet wird mir trotzdem nur käse.

glVertexAttribPointer(
0, 4, GL_FLOAT, GL_FALSE, sizeof(float)*2, 0
);

[BDL!]

Hallo,

Der Vertex-Attrib-Pointer passt sicher nicht. Du schreibst hier, dass dein Datensatz pro Vertex zwei floats groß ist. Gleichzeitig versuchst du aber einen vec4 damit zu befüllen. Bei VertexAttribPointer ist die vorletzte Angabe die größe jedes Vertices und die letzte der Offset zum Beginn des Vertices.

[Getshi]

ahhhh okay. das stride im vbo-anzeige modus ist wieviel ausgelassen werden soll NACH dem aufnehmen also v1,v2,v3,v4 dann 2*float auslassen, deswegen hab ich das so übernommen
aber das stride bei attribpointer ist dann das ganze zusammen ._. also ich seh jetzt nen würfel. danke

[Getshi]

soo also muss es doch in irgendeiner art am model einlesen liegen. wie gesagt: assimp viewer schaffts.

hier hab ich mal ein bild vom relevanten model einleseteil und vbo ansicht die genau die positionsdaten anzeigt, vllt hilft das mir zu helfen =(


die daten scheinen nämlich ziemlich falsch zu sein aber eig hab ich kA
---
edit: hab das gefühl das modell loading muss komplett überarbeitet weden ws, hab gedacht es wird gehenwenn ich das wie in den folien nachmach aber im assimpviewer besteht das model aus vielen meshes und dann gibts noch teilweise texturen bei modells teilweise nicht, manchmal farben ode auch nicht. ich glaub ich komm nicht drum herum mir von irgendwo diese 3 a4seitenlangen assimp codes anzuschaun und selbst nachzumachen
----
edit2:
kann mir vllt jemand ein richtig gscheites assimp tutorial empfehlen?

[ClemensRoegner]

Also die Daten scheinen richtig zu sein. Und die markierte 1 passt schon so.

Wenn du sagst, dass dein Model aus vielen meshes besteht(also nicht so daher kommt wie du es gerne haettest), dann gibts vorerst nur eine Loesung: ein simples Modell laden. Fuer die kommende Abgabe brauchst du nicht die finalen Modelle sondern nur Platzhalter.

[Getshi]

Also die Daten scheinen richtig zu sein. Und die markierte 1 passt schon so.

Wenn du sagst, dass dein Model aus vielen meshes besteht(also nicht so daher kommt wie du es gerne haettest), dann gibts vorerst nur eine Loesung: ein simples Modell laden. Fuer die kommende Abgabe brauchst du nicht die finalen Modelle sondern nur Platzhalter.

nja aber bevor ich mit viel pseudoloading jetzt dann teste und dann einen gröberen mehraufwand hab wenn ich das ganze dann neu mache mit gscheit und komplett laden wobei ich dann renderiung davon wieder neu schreiben muss dann mach ich das lieber gleich solang noch ferien sind. ich find allerdings keineguten tutorials, eig nur 2 oder 3 die aber jeweils anders an die sache rangehen aber nie ganz durchsichtig.

[BDL!]

Da hast es ja schon hinbekommen einen Würfel mit interleaved VBOs zu zeichnen. Dann erstell dir jetzt mal ein 3D-Modell des selben Würfels, und versuch den zu laden. Dann siehst du wo sich die Unterschiede zum direkt gebastelten Würfel ergeben.

[Getshi]

Da hast es ja schon hinbekommen einen Würfel mit interleaved VBOs zu zeichnen. Dann erstell dir jetzt mal ein 3D-Modell des selben Würfels, und versuch den zu laden. Dann siehst du wo sich die Unterschiede zum direkt gebastelten Würfel ergeben.

das bringt mir aber auch nicht viel weil so wie ich das hab ist das scwer erweiterbar und zusätzliche funktionalität würde heißen von neu aufbauen (zb wenn ich n panzermodel hab und den oberen teil, der vllt ein eigenes mesh ist drehen zu können) hab jetzt versucht das neu zu machen aber es wird einfach unübersichtlich plus dann noch mein unkönnen in c++ machts für mich fast unmöglich deswegen such ich nach einem tutorial wo das halbwegs die funktionalität hat die ich brauchen würd und ned unmengen mehr mit aufwendigen texturloading oder recursive rendering von nodes, ich hätt gern einfach meine meshes in einem objekt zusammengefasst und renderbar, aber wie die stunden vergehen vergeht auch meine motivation, deswegen durchstöber ich einfach morgen google weiter

[Getshi]

heureka. ich sehe vermutlich alle meshes! allerdings mit 2 gröberen problemen.
1. die meshes starten irgendwie alle im ursprung d.h. falsche relative positionen
2. wenn ich das komplette modell rotiere um die x achse, dann verschwindet es irgendwann im hintergrund relativ buggy
bilder dazu:

---EDIT
gelöst mit postprocessingflag aiProcess_PreTransformVertices

[dk*82]

soo also muss es doch in irgendeiner art am model einlesen liegen. wie gesagt: assimp viewer schaffts. hier hab ich mal ein bild vom relevanten model einleseteil und vbo ansicht die genau die positionsdaten anzeigt, vllt hilft das mir zu helfen =( die daten scheinen nämlich ziemlich falsch zu sein aber eig hab ich kA --- edit: hab das gefühl das modell loading muss komplett überarbeitet weden ws, hab gedacht es wird gehenwenn ich das wie in den folien nachmach aber im assimpviewer besteht das model aus vielen meshes und dann gibts noch teilweise texturen bei modells teilweise nicht, manchmal farben ode auch nicht. ich glaub ich komm nicht drum herum mir von irgendwo diese 3 a4seitenlangen assimp codes anzuschaun und selbst nachzumachen ---- edit2: kann mir vllt jemand ein richtig gscheites assimp tutorial empfehlen?

hej getshi, kannst du mir bitte verraten, wie auch ich zu dieser ansicht komme

[Zaru]

Nach den ganzen C++ Problemen bisher war ich echt froh, dass Assimp so einfach funktioniert hat.

[ClemensRoegner]

heureka. ich sehe vermutlich alle meshes! allerdings mit 2 gröberen problemen.
1. die meshes starten irgendwie alle im ursprung d.h. falsche relative positionen
2. wenn ich das komplette modell rotiere um die x achse, dann verschwindet es irgendwann im hintergrund relativ buggy
bilder dazu:

---EDIT
gelöst mit postprocessingflag aiProcess_PreTransformVertices

Also ich denke da passt etwas mit deinen Matrizen nicht. Entweder die FarPlane der Projection Matrix ist zu gering oder die Reihenfolge der Transformationen ist falsch.

[dk*82]

kann mir bitte jemand verraten, wie ich zu dieser ansicht komme?


(screenshot von Getshi)

ich verzweifel nämlich schon langsam, weil ich im wahrsten sinne des wortes nur schwarz sehe
das model-loading funktioniert soweit ja, aber es wird einfach nix angezeigt. würde echt gern wissen, was in meinen VBOs steht.

vielen dank für eure hilfe,
dominik

[mOfl]

Das sollte sich mit der Visual-Studio-Integration von gDEBugger (http://developer.amd.com/tools/gDEBu...s/default.aspx) erreichen lassen, selbst getestet habe ich das aber nicht.

[Getshi]

also ich hab mir das amd gdebugger visual studio plugin/addin runtergeladen (http://developer.amd.com/tools/gDEBu...s/default.aspx)
dann hast du in der toolbar oben einen gDebugger eitnrag, dort kannst du dann opengl breakpoints setzen wie zb glBufferData und mit gDebugger debuggen.
da is dann anders als beim normalen debugger bleibt de rnur bei den openGL breakpoints stehen und du hast glaub ich auch keine local variablen mehr gespeichert, also ich empfehle glBufferData zu setzen und dann noch step over damit der schritt ausgeführt wird, dann kannst du rechts (oderso) in der gDebugging liste dann die vbos zb anschauen

wichtig ist noch dass bei interleaved vbos der stride der dort einzugeben nicht wie bei glVertexAttribPointer (ich glaub das war die funktion) das ganze interleaved struct ist sondern struct minus der anzuschauenden variable
klingt wirr. zb du hast vec3 vec3 vec2 als ein struct zb für position, normals, UV-coord. dann wäre bei attribpointer der stride sizeof(float)*8 aber bei vbo anzeigen je nachdem float*6 bzw float* 5 glaub ich

[dk*82]

danke getshi für die ergänzungen!

so, meine VBOs werden korrekt befüllt, es wird aber trotzdem nichts (also nur schwarz) angezeigt...
das heißt also weitersuchen

[Getshi]

jetzt wird mein neues model das ich in blender gemacht hab und mit assimpview schön anzeigen kann bei mir inside-out angezeigt =(

ich vermute stark dass es was mit normals zu tun hat. weil wenn ich das in blender inside-out mache und dann exportier dann ists bei mir richtig.
ich find nur grad nicht woran das liegt. ich benutze GL_CULL_FACE aber das sollte ja eig mit vertexorder arbeiten und wenn ich über Assimp flipWindingOrder mache dann ändert sich garnix =/ plus wenn ich CULL_FACE wegmache dann sieht man dass die normals verkehrt sind.
--
und assimpview schafft es korrekt anzuzeigen egal wie ichs exportiere

[mOfl]

Welche Import-Flags verwendest du denn?

[Getshi]

Welche Import-Flags verwendest du denn?

daweil genUVCorrds, FixInfacingNormals(macht keinen unterschied) und GenNormals, wobei das model eig normals und UV coords selber hat

[mOfl]

Hm also solange du Texturkoordinaten und Normalen im Model hast, machen GenUVCoords und GenNormals / GenSmoothNormals gar nichts. FixInfacingNormals ist glaube ich nur dann geeignet, wenn die Normalen einzelner Vertices falsch sind, das liefert oft auch keine richtige Lösung. Kannst du mal bitte das Flag aiProcessPreset_TargetRealtime_MaxQuality ausprobieren? Das ist das Standardflag und bietet so ziemlich alles an Optimierung an, was Assimp kann.

[Getshi]

Hm also solange du Texturkoordinaten und Normalen im Model hast, machen GenUVCoords und GenNormals / GenSmoothNormals gar nichts. FixInfacingNormals ist glaube ich nur dann geeignet, wenn die Normalen einzelner Vertices falsch sind, das liefert oft auch keine richtige Lösung. Kannst du mal bitte das Flag aiProcessPreset_TargetRealtime_MaxQuality ausprobieren? Das ist das Standardflag und bietet so ziemlich alles an Optimierung an, was Assimp kann.

mh ich glaub dann will er alles mit indices haben weil die triangles sind relativ wirr jetzt. habs daweil ohne indices nur direkt alle vertices

[mOfl]

Was heißt "alle Vertices"? Inklusive aller Duplikate, also #Vertices = #Triangles * 3? Das macht dir Assimp beim Laden automatisch, um das fürs Rendering zu optimieren. Also prinzipiell kannst du mit Assimp ohne Probleme auch ohne Indizes arbeite. Bist du dir eigentlich sicher, dass es an den Normalen liegt? Das siehst du ja relativ leicht, wenn die Beleuchtung genau den falschen Bereich beleuchtet oder wenn du dir einfach die Normalen ausgeben lässt. Umgedrehtes Culling erkennst du am besten mit Beleuchtung, sonst ist das fies, weil du teilweise Dinge siehst, die perspektivisch einfach falsch aussehen, z.B. Rotation in die vermeintlich falsche Richtung.

[Getshi]

Was heißt "alle Vertices"? Inklusive aller Duplikate, also #Vertices = #Triangles * 3? Das macht dir Assimp beim Laden automatisch, um das fürs Rendering zu optimieren. Also prinzipiell kannst du mit Assimp ohne Probleme auch ohne Indizes arbeite. Bist du dir eigentlich sicher, dass es an den Normalen liegt? Das siehst du ja relativ leicht, wenn die Beleuchtung genau den falschen Bereich beleuchtet oder wenn du dir einfach die Normalen ausgeben lässt. Umgedrehtes Culling erkennst du am besten mit Beleuchtung, sonst ist das fies, weil du teilweise Dinge siehst, die perspektivisch einfach falsch aussehen, z.B. Rotation in die vermeintlich falsche Richtung.

ja daweil hab ich eben ohne indices gearbeitet aber das flag-preset würde das verlangen.

ich bin mir relativ sicher dass es an den normalen liegt. also wenn ich in blender die normalen invertiere dann siehts so aus wie bei mir, komischerweise schafft assimpviewer aber sowohl falsche als auch richtig gedrehte normals anzuzeigen, ich aber nur falschrum gedrehte. und wenn ich wie gesagt culling abschalte dann ist das modell genau verkehrt herum beleuchtet

[mOfl]

und wenn ich wie gesagt culling abschalte dann ist das modell genau verkehrt herum beleuchtet

Wie das? Wenn dein Backface Culling stimmt, darfst du zwischen Culling an und Culling aus überhaupt keinen Unterschied sehen, weil die gecullten Flächen immer verdeckt sind.

[Getshi]

Wie das? Wenn dein Backface Culling stimmt, darfst du zwischen Culling an und Culling aus überhaupt keinen Unterschied sehen, weil die gecullten Flächen immer verdeckt sind.

mein model ist ja jetzt aus irgendeinem grund inside-out, d.h. wenn ich culling angeschalten habe dann werden genau die eigentlich sichtbaren flächen weggeschnitten.
flipwindingorder macht aber keinen unterschied als importflag, daher kA was ich tun kann dagegen
-EDIT
wobei ich nicht sicher bin ob sich flipwindingorder vllt nur auf indices auswirkt und nicht auf vertices

[mOfl]

mein model ist ja jetzt aus irgendeinem grund inside-out, d.h. wenn ich culling angeschalten habe dann werden genau die eigentlich sichtbaren flächen weggeschnitten.

Ach jetzt verstehe ich das Problem, tut mir leid. Ich hab das so gelesen, als wären nur die Normalen invertiert. Ok, dann müsste es eigentlich mit dem Call glFrontFace(GL_CCW) bzw. glFrontFace(GL_CW) (musst du ausprobieren) zu machen sein. Ich weiß gar nicht, ob es in Assimp selbst eine Möglichkeit gibt, die Polygon Order zu ändern, eventuell mit dem Flag aiProcess_Triangulate, aber das ändert vielleicht auch nur Polygone mit mehr als 3 Vertizes. Eigentlich musst du das in Blender selbst machen, afaik wird das mit dem Normal Flip gemacht.

[Getshi]

ah okay, hab garnicht drangedacht dass es sein kann dass modells in blender vllt andersrum sind. ich werds nochmal probieren indem ich die models in blender invertier
--EDIT
so jetzt passts. hab gedacht weil das in blender dann falsch ausschaut dass ich irgendwas in openGL oder assimp falsch mach.
ich mein ist trotzdem möglich, da assimpview beide arten korrekt anzeigt aaaaber so ists einfacher für mich

[dk*82]

damit niemand den selben fehler macht wie ich...

beim laden eines models mit assim bezüglich der transformationsmatrizen folgendes beachten:

    aiMatrix4x4 matrix = node->mTransformation;

    /*
    // THIS IS THE WRONG WAY
    m_matrix = glm::mat4(
        matrix.a1, matrix.a2, matrix.a3, matrix.a4, 
        matrix.b1, matrix.b2, matrix.b3, matrix.b4, 
        matrix.c1, matrix.c2, matrix.c3, matrix.c4, 
        matrix.d1, matrix.d2, matrix.d3, matrix.d4
    );
    */

    // THIS IS THE RIGHT WAY
    m_matrix = glm::mat4(
        matrix.a1, matrix.b1, matrix.c1, matrix.d1, 
        matrix.a2, matrix.b2, matrix.c2, matrix.d2, 
        matrix.a3, matrix.b3, matrix.c3, matrix.d3, 
        matrix.a4, matrix.b4, matrix.c4, matrix.d4
    );

ist ziemlich ärgerlich, wenn man es (wie ich) falsch macht und dann ziemlich lange braucht, bis man draufkommt