In meinem aktuellen Shader-Projekt (BumpMapping) will ich den vorher berechneten TangentSpace per glVertexAttrib an meine Shader übergeben. irgendwie macht das ganze aber Probleme. Gehe ich richtig in der Annahme, dass man nicht gleichzeitig glVertexAttribute und glVertex/glTexCoord verwenden darf?
In einen älteren Thread bin ich dann noch auf folgendes gestossen:



Muss ich das auch in meinem Fall enablen? Ich habe keine Pointer, sondern übergebe nur drei Vektoren (Tangent, Binormal, Normal)?

_________________
"Du musst ein Schwein sein in dieser Welt, sangen die Prinzen, das ist so 1.0. Du musst auf YouTube zeigen, dass dir dein Schweinsein gefällt, das ist leuchtendes, echtes Web 2.0."
- Hal Faber
Meine Homepage: http://laboda.delphigl.com

Wenn man Attribute benutzt, dann für alles Attribute, weil diese generischen Attribute letztlich auf die allgemeinen abgebildet werden. Das Verhalten ist glaube ich auch bei ATI und NVidia Karten unterschiedlich und bei ARB_fp auch offen gelassen worden.
Am einfachsten ist es natürlich auch für die anderen Vektoren Texturekoordinaten zu benutzen. Dann spart man sich die Sache mit GetAttribLocation. Das Vertex Format ist ja eher eine grundlegende Sache, so daß man das eigentlich ruhig schon so festlegen kann. Früher hatte der ATI Treiber auch Probleme mit Vertex Buffern wenn man generische Attribute verwendet hat. Wie das jetzt ist weiß ich nicht, da ich auch Texture Koordinaten verwende.

OK, Vielen Dank für die schnelle Anwort!

_________________
"Du musst ein Schwein sein in dieser Welt, sangen die Prinzen, das ist so 1.0. Du musst auf YouTube zeigen, dass dir dein Schweinsein gefällt, das ist leuchtendes, echtes Web 2.0."
- Hal Faber
Meine Homepage: http://laboda.delphigl.com

Noch eine andere interessante Idee ist es die Vertex Attribute mittels #define in einer Datei zu definieren und diese dann mit #include in alle Shader einzubinden.



Dann braucht man die Attribute nicht bei jedem Shader extra setzen und ist trotzdem flexibel, wenn man das Format mal ändern möchte. Wenn man den Vertex irgendwie gepackt hat, kann man das Entpacken und andere nützliche Sache wie MVP auch noch gleich mit einbauen.

Hey, das hab ich gar ned gewusst, das man da auch "auslagern" kann, danke für die Info.
Rein routinemäßig : Wird das auch von allen modernen GraKas unterstützt. Ich bin es nämlcih leid, x Fehler in meinen Proggs zu suchen, und dann nach Tagen festzustellen, dass es an einem alten Treiber oder Inkompatibiläten liegt. Alternativ, kennt jemand ne Seite, wo jemand schon mal solche Fehlerquellen auflistet?

_________________
"Du musst ein Schwein sein in dieser Welt, sangen die Prinzen, das ist so 1.0. Du musst auf YouTube zeigen, dass dir dein Schweinsein gefällt, das ist leuchtendes, echtes Web 2.0."
- Hal Faber
Meine Homepage: http://laboda.delphigl.com

Das #include geht leider nur mit NVidia Karten zur Zeit, obwohl diese Direktive reserviert ist. Daher muß man es dann selber programmieren.
Leider kenne ich auch solch eine Seite nicht. Man sollte zumindest meinen, daß man auf der sicheren Seite ist, wenn man nur ARB Extensions benutzt, aber bei glsl gibt's, wie schon oft angesprochen, erhebliche Unterschiede. Man kann im NVidia NVemulate Tool, die Option "Strict Shader Portability Warnings" einschalten und erhält zumindest Hinweise wenn man gegen die Spezifikation verstößt.
Meine Eindrücke zur Kompatibilität:
Habe auch eine ATI Radeon 9800 pro und da ist glsl total unbrauchbar, aber arb_fp sehr schön schnell und optimiert. Mehr als 6 Texturezugriffe habe ich mit glsl nicht hinbekommen, obwohl man 32 hat. Vielleicht in einem neueren Treiber. Bei NVidia wird aber anscheinend auf der Assembler Ebene nicht mehr so stark optimiert, so daß ich in dem gleichen ARB_fp Shader, der auf der alten Radeon lief auf der mehr oder weniger neuen GF, alle Temp Register verbraucht hatte. Der NVidia glsl Compiler ist aber bis auf einige Sachen sehr gut. Habe mir mal die Assembler Ausgaben angesehen und da wird versucht das ganze optimal hin und her zuschieben, so daß die Anzahl der gerade benutzen Temp Register möglichst klein bleibt. Auf der Radeon funktioniert es nicht, aber bei der GF geht das glsl Prinzip mit der optimalen Kompilierung auf. Leider zu einem recht hohen Preis. Selbst einfache Shader brauchen schon >50ms und länger zum Kompilieren, so dass eine dynamische Generierung wegfällt. Braucht man ja eigentlich auch nicht. Man hat ja wunderbar, if/else for und while Schleifen und alles im Fragment Shader. Habe zwar keine Ahnung wie das jemals auf einer Radeon 9800 laufen soll, aber maximal 65535 Befehle erreicht man auch mit glsl nicht so schnell. Multipass Rendering gehört dann wohl der Vergangenheit an. Nur die Schleifen sind noch nicht so optimiert wie sie sein könnten. Habe auf opengl.org was da zu geschrieben. Selbst wenn man eine Uniform Variable als obere Grenze nimmt, wird immer dynamisches Branching erzeugt und bei if/else werden auch beide Zweige ausgeführt, selbst wenn der eine von beiden länger ist, als ein dynamisches if kosten(6 Zyklen) würde. Es ist also noch nicht alles so super optimal, aber angesichts dieser genialen Möglichkeiten lohnt es sich meiner Meinung nur auf glsl zu setzen, wenn man auch die ps30 voll ausreizt. EXT_fbo gibt's von ATI auch nicht und die PBuffer sind zu allem Überfluß auch noch um ein Vielfaches langsamer.
Leider sieht's mit der Kompatibilität nicht so toll aus und ich wüßte auch keine bessere Lösung als auf beiden Karten zu testen, wenn man wirklich sicher gehen will. Die Extensions Liste von delphi3d.net ist recht gut, aber bei so speziellen Sachen hilft sie auch nicht weiter.