Ich schreibe aktuell an einem Programm, dass (beliebige) Funktionen zeichnen soll. Die Funktion soll dabei in in einen Vertexshader eingebaut werden, und das funktioniert soweit auch.
Das Problem dabei ist, dass ich die Normalen nicht vorher berechnen kann, da die Funktion beim Kompilieren noch nicht bekannt ist. Deshalb musste dafür ein Geometryshader her. Ursprünglich gabs noch ein paar AccessViolations in der atioglxx.dll, seitdem ich im Immediate mode rendere sind die aber weg.
Jedenfalls, das Problem ist folgende Fehlermeldung:
Code:
ERROR: error(#277) Symbol 'pos[0]' usage doesn't match between two stages
in folgendem Shader:
Code:
varying in vec3 pos[4]; varying out vec3 position; varying out vec3 normal;
void main() { vec3 Normal = ((pos[3] - pos[1]) * (pos[3] - pos[2])).xyz; /*for (int i1 = 0; i1 < 4; ++i1) { position = pos[i1]; normal = Normal; gl_Position = gl_PositionIn[i1]; EmitVertex(); }*/ // ursprünglich benutzte ich diese Schleife. Hab dann probiert, ob die den Fehler verursacht, lag aber falsch
position = pos[0]; normal = Normal; gl_Position = gl_PositionIn[0]; EmitVertex();
position = pos[1]; normal = Normal; gl_Position = gl_PositionIn[1]; EmitVertex();
position = pos[2]; normal = Normal; gl_Position = gl_PositionIn[2]; EmitVertex();
position = pos[3]; normal = Normal; gl_Position = gl_PositionIn[3]; EmitVertex(); }
noch eigenartiger ist jedoch, dass ich dieselbe Fehlermeldung bakomme, wenn ich alle indices um 1 erhöhe. Dann kommt im Code nämlich kein 'pos[0]' mehr vor.
möglicherweise ist auch an den ProgramParamereri was falsch, ich wüsste aber nicht, was da falsch sein soll
GL_QUADS ist als Input-Typ nicht erlaubt. Wenn du Quads renderst musst du im Geometryshader wahrscheinlich GL_TRIANGLES nehmen, probiert hab ich das aber nicht. Siehe auch http://wiki.delphigl.com/index.php/GL_E ... nput-Typen
hab input auf GL_TRIANGLES gestellt, und output auf GL_TRIANGLE_STRIP, gibt aber immer noch dieselbe Fehlermeldung. Es wird auch nach wie vor erwähnt, dass alle drei shader 'was successfully compiled to run on hardware' . Die Fehlermeldung kommt übrigens doppelt, falls das irgendwas hilft.
der aktuelle shader ist:
Code:
varying in vec3 pos[3]; varying out vec3 position; varying out vec3 normal;
Zeig mal bitte alle drei Shader. Der Fehler kommt ja beim linken, oder? Das würde heißen die Shader sind für sich genommen ok, passen aber nicht zusammen.
Those usually imply that you have declared the same name as an attribute in the vertex shader, and a uniform in the fragment shader. Double-check your names, and make sure there are *no* overlaps.
Jetzt gehts theoretisch, aber die Normalen, die der Geometryshader ausspuckt sind nach wie vor eher merkwürdig. x und y kommt mir irgendwie mehr oder weniger vertauscht vor, während z viel zu hochfrequent ist(was bei einer niedrigfrequenten sinusfunktion nicht unbedingt sein sollte). der Fragmentshader wil auch nicht ganz so wie ich, er setzt alle pixeln schwarz. (um die Normalen anzusehen hab ich einen anderen Fragmentshader angehängt)
die hohe Frequenz in z richtung war dadurch bedingt, dass ich die hälfte der dreiecke kervehrt herum definiert habe. jetzt bleibt eigentlich nur noch das Problem mit der Beleuchtung ( ist auch nicht unbedingt nötig, soll ja nur Funktionen zeichnen ), und dass es im Immediate Mode A****lamgsam ist. Mit Displaylisten wirds auch eher noch langsamer
Displaylisten richtig angewendet sind das schnellste was es gibt. Dafür machen die aber nur bei statischer Geometrie Sinn. Wenn sich die Geometrie häufig ändert sind VBOs das Mittel der Wahl.
Zitat:
Jetzt gehts theoretisch, aber die Normalen, die der Geometryshader ausspuckt sind nach wie vor eher merkwürdig
Lass dir doch mal die Normalen als Farbe im Fragmentshader ausgeben. Dann siehst du schnell ob die vielleicht teilweise in die falsche Richtung (z.B. durch Vorzeichenfehler) zeigen oder so.
Lass dir doch mal die Normalen als Farbe im Fragmentshader ausgeben. Dann siehst du schnell ob die vielleicht teilweise in die falsche Richtung (z.B. durch Vorzeichenfehler) zeigen oder so.
So hab ich doch erst herausgefunden, dass sie vielleicht etwas merkwürdig sind. hab bloß Probleme, da was zu erkennen.
Zitat:
Displaylisten richtig angewendet sind das schnellste was es gibt. Dafür machen die aber nur bei statischer Geometrie Sinn. Wenn sich die Geometrie häufig ändert sind VBOs das Mittel der Wahl.
meine Geometrie ist doch statisch. eine einfache XZ Ebene. alles, was sich da ändert, wird im Vertexshader berechnet.
zudem krieg ich auch wenn ich statt ca. 60k Dreiecke nur ca. 10k Dreiecke zeichne keine besseren Frameraten. genau weiß ichs nicht, weil ich bisher keinen Framecounter eingebaut hab, aber so Daumen * Pi sinds 1 FPS. variiert auch ziemlich stark, nur halt unabhängig von der Anzahl der Dreiecke.
Das Problem mit den Normalen ist gelöst. Hab noch nen alten Backup von meiner Kameraklasse verwendet. Und da hab ich die Rotation in die Projectionsmatrix geschrieben. Das kann nicht gut gehen.
Registriert: Sa Aug 18, 2007 18:47 Beiträge: 694 Wohnort: Köln
Programmiersprache: Java
Ich bin zwar Shader-technisch etwas bewandert. Was Geometry Shader angeht allerdings nicht so dolle. Könnte mir jemand erläutern was o.g. Shader macht? Habe das immer so verstanden das man gl_Position ändert bevor man den Vertex emittiert. Findet da Tesselierung statt? Wird da automatisch interpoliert zwischen dem Vertex und dem Geometry Shader?
_________________ Es werde Licht. glEnable(GL_LIGHTING); Und es ward Licht.
Zitat aus einem Java Buch: "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off"
Mitglieder in diesem Forum: 0 Mitglieder und 27 Gäste
Du darfst keine neuen Themen in diesem Forum erstellen. Du darfst keine Antworten zu Themen in diesem Forum erstellen. Du darfst deine Beiträge in diesem Forum nicht ändern. Du darfst deine Beiträge in diesem Forum nicht löschen. Du darfst keine Dateianhänge in diesem Forum erstellen.