Ich mal wieder und wieder mit einem Problem. Ich habe mein Skinningsystem auf Shader umgestellt, bzw. das wollte ich tun, allerdings funktioniert es nicht. Die Vorschläge für die Checkliste Shader bin ich durchgegangen, dabei ist mir aufgefallen, dass folgender Code wahrscheinlich fehlerhaft ist:


Denn ich hatte im Vertexshader einstehen und im Fragmentshader nicht. Müsste es dann nicht eigentlich einen Linkerfehler geben?

Naja, ich habe die Zeile dann erstmal entfernt und mit ihr alle Zeilen, die sich auf N beziehen. Allerdings sehe ich nichts. Der Fragmentshader funktionierte in einem anderen Programm einwandfrei, der Vertexshader ist zum ersten Mal im Einsatz, weshalb ich in ihm den Fehler vermute. Ich habe ihn auf das nötigste gekürzt (jetzt hat er kein Skinning mehr), um Fehler auszuschließen, allerdings ist immer noch nichts zu sehen. Hier ist er (tada!):
Übrigens funktioniert das kompilieren beider Shader ohne Fehler, das absichtliche Einbauen eines Fehlers führt auch zu einer Fehlermeldung.

Danke schonmal im Vorraus für euren Rat!

mrtrain

Ich weiß nicht, ob das so schlau ist eine w-Koordinate von 0 anzugeben. Bist du sicher, das es nicht eine 1 sein soll? Das wäre zumindest korrekt wenn du ein glVertex3f nachbauen willst.

Du vermutest ja einen Linkerfehler, daher wäre es wohl sinnvoll Vertex- und Fragmentshader zu posten.

Dein testen auf Linkerfehler sieht aber auf den ersten Blick gut aus, wobei du im Fehlerfall die Fehlermeldung vom Linker auslesen solltest.

Ich denke der Fehler liegt hier:

Wenn du die Translation in der Matrix berücksichtigen willst muss es vec4(a_Position, 1.0) lauten. (Edit: Hmpf, NerdIII war schneller )

_________________
Yeah!

Okay, danke für eure Antworten. Das mit der 0.0 war natürlich ein Fehler und jetzt sehe ich auch was (wenn auch nur Müll ). Also hier noch der Fragmentshader:
Der interpoliert zwischen Farbe und schwarz-weiß (mir war grad danach ).

Das sieht für mich derzeit nach einem logischen Fehler beim Schreiben in das VBO oder beim Setzen der Vertexattribute aus... Aber ich weiß nicht, ob es so sinnvoll ist, hier tonnenweise Code zu posten. Ich meld mich wieder, wenn ich 'nen genaueren Verdacht hab' oder dran verzweifle.

Achja, zum Linkerfehler: Man nehme einen der beiden Shader und schreibe vor die main() ein "varying vec3 N;". Es war erst beim Vertexshader, ich habe es experimentell auch mal getauscht. Jedenfalls hatte ich die Situation, dass ein Shader die Zeile drin hatte und der andere nicht. Und es hat keinen Linkerfehler gegeben. Normalerweise hätte es doch einen geben müssen, oder?

Unbenutzte varyings werden möglicherweise automatisch entfernt.

_________________
Yeah!

Ja, und Attribute wohl auch. Was ich euch vorhin beim Link-Code vorenthalten habe:
Bei den VertexAttributen, die ich zwecks Fehlereingrenzung nicht benutzt habe, lieferte glGetAttribLocation 4294967295, aka -1, zurück. Daher habe ich wohl auch nur Müll zu sehen bekommen, statt dem Model, dass ich eigentlich wollte. Allerdings dauert es jetzt ein bisschen, zu testen, ob das der einzige Grund war. Ich meld' mich dann wieder.

Das ist kein Bug, sondern ein Feature. Stell dir vor du verwendest Transform-Feedback und möchtest die Werte von N in ein Buffer-Objekt schreiben ohne sie im Fragment-Shader zu verarbeiten. Dann würdest du genau so vorgehen, das varying im Vertex-Shader deklarieren, im Fragment-Shader aber nicht. Umgekehrt ist das allerdings wirklich sinnlos würde ich meinen. Vielleicht reagieren unterschiedliche Treiber da anders.
(Wenn du willst das ein varying wirklich im gelinkten Programm ausgegeben wird, auch wenn - hardcore-Fall - der Compiler feststellt, dass eine if-Anweisung im Fragment-Shader immer true ergibt, und in diesem Pfad das varying nicht verwendet wird, etc.. etc.. dann kannst du vorm Linken mit ActiveVarying dafür sorgen. Diese Funktion existiert aber in erster Linie für Transform-Feedback.)

Transform-Feedback ist doch für GPGPU und sowas auf Karten ab DirectX 10? Naja, so fortgeschritten bin ich leider noch nicht, ich habe ja schon mit einfachen Vertexshadern zu kämpfen.

Vermutlich liegt der Fehler irgendwie beim Laden der Vertexdaten in den Grafikspeicher. Vielleicht gibt es da ja was zu beanstanden:
Sorry, dass ich hier so viel Code poste. Geht das eigentlich mit memcpy()?

edit: Hab's jetzt mal ohne memcpy() gemacht, was eigentlich auch viel eleganter ist. Das Ergebnis ist allerdings das gleiche.

Danke für weitere Antworten!

Das sieht mir korrekt aus. Das VBO.UnmapBuffer() am Ende tut auch das richtige?? Transform-Feedback funktioniert auf DirectX 10 Grafikkarten, wie zum Beispiel der Geforce 8600. Du könntest zum Beispiel deine gl_Position Daten nach dem Vertex-Shader in ein VBO schreiben lassen, um sie zu debuggen. So kompliziert ist das gar nicht. Ich verwende TF zum Beispiel so, um an die Bildschirmkoordinaten meiner Vertizes zu kommen. Andere rufen mehrfach hintereinander einen Geometry-Shader auf, der ihre Dreiecke jeweils feiner unterteilt oder lassen ihre Partikelengine auf der Grafikkarte laufen. Also es gibt durchaus eine Menge Anwendungen in denen man tatsächlich Geometrie damit verarbeitet und nicht nach außerirdischem Leben sucht o.ä.

Oh, die letzte Zeile habe ich nicht angepasst. Es ist nämlich so, dass ich eine VBO-Klasse habe, deren Methoden ich eigentlich in der C3D_Model::LoadToVRAM aufrufe. Bei VBO.Create und VBO.MapBuffer habe ich in meinem Post "entpackt" um es euch einfacher zu machen, bei VBO.Unmap habe ich es schlicht vergessen. Wird sofort angepasst. Inzwischen habe ich es wie gesagt auch schon ohne memcpy() probiert und der Fehler liegt vermutlich doch nicht beim Laden. *grübel*

So, ich glaube und hoffe den Grund gefunden haben, warum OpenGL nicht tut, was es soll. *hoff* Und zwar steht in der OpenGL-Dokumentation zu glVertexAttribPointer, was ich verwende, folgendes:
Wenn ich mich jetzt nicht vertue, heißt dass das sich glDrawArrays und glVertexAttribPointer nicht miteinander vertragen, richtig? Demnach bräuchte ich jetzt eine Alternative für eine der beiden Funktionen. Hat jemand einen Vorschlag?

edit: Ach Mist, ich hab da wohl die Klammern falsch gesetzt. So ist es wohl gemeint:Das initially bezieht sich also auch auf das nach dem "and"... oder? Soviel zur Punkt-vor-Strich Regel

Ich freue mich auf eure Antworten

mrtrain

Wie du schon selbst bemerkt hast musst du die nur einschalten. Das geht mit glEnableVertexAttribArray.

_________________
Yeah!