Wieso kann dieser VertexShader überhaupt funktionieren. Anstelle von inColor und inPos, habe ich Fantasienamen geschrieben. Wie kann OpenGL überhaupt wissen was ich mit diesen Namen meine. Der Namen xxxin... ist im Delphi-Quellcode auch nirgends erwähnt.
Die Variable Color kann ich auch einen anderen Namen geben, nur muss sie im Fragment und im VertexShader gleich heissen. Diese Variable ist wohl die Verbindung zwischen den beiden Shadern.
Registriert: Mi Aug 14, 2013 21:17 Beiträge: 588
Programmiersprache: C++
Mit welchen Werten die in-Variablen eines Vertexshaders belegt werden sollen, legst du beim Aufruf von glVertexAttribPointer fest. Tust du dies nicht, sind die Werte undefiniert, würde ich sagen.
mathias hat geschrieben:
Die Variable Color kann ich auch einen anderen Namen geben, nur muss sie im Fragment und im VertexShader gleich heissen. Diese Variable ist wohl die Verbindung zwischen den beiden Shadern.
Korrekt. Zu jeder in-Variable im Fragmentshader muss es eine gleichnamige out-Variable im Vertexshader geben. Früher hieß das nicht in und out, sondern varying.
_________________ So aktivierst du Syntaxhighlighting im Forum: [code=pascal ][/code], [code=cpp ][/code], [code=java ][/code] oder [code=glsl ][/code] (ohne die Leerzeichen)
Registriert: Mi Aug 14, 2013 21:17 Beiträge: 588
Programmiersprache: C++
Du rufst zwei Mal glVertexAttribPointer auf und zwar mit 0 und 1 als erstes Argument. "Zufällig" sind das offenbar die Nummern, die dein Grafiktreiber für deine in-Variablen vergeben hat. Darauf kannst du dich nicht verlassen. Korrekterweise müsstest du diese IDs erst mit glGetAttribLocation abfragen (nach dem Linken) oder vor dem Linken mit glBindAttribLocation festlegen.
Edit: Eine weitere Möglichkeit ist es, die IDs der VS-Inputs mit dem keyword layout festzulegen. Beispiel:
Code:
#version 330
layout(location =345)invec3 xxxinPos;
layout(location =123)invec4 xxxinColor;
Dies geht in älteren GLSL-Versionen jedoch nicht. Kann sogar sein, dass dies erst mit #version 330 dazu gekommen ist.
_________________ So aktivierst du Syntaxhighlighting im Forum: [code=pascal ][/code], [code=cpp ][/code], [code=java ][/code] oder [code=glsl ][/code] (ohne die Leerzeichen)
Ich habe ein Tutorial dazu gefunden, dank deiner Befehle.
Ich hoffe das es jetzt so richtig ist. Wen ich jetzt die xxx reinschreibe, bleibt das OpenGL-Fenster leer. Ich habe die Werte von Pos_id und col_id abgefragt und da kommt -1, wen ich die xxx reinschreibe und das ist richtig so. Somit ist wieder eine Fehlerquelle ausgeschlossen. In dem Tutorials, es waren 2, nach denen ich mein Programm geschrieben habe, finde ich nichts von glGetAttribLocation. Bei den ids kommen 0 und 1 raus und dies wird wohl der Programmierer des Tutorials ausgenutzt haben
Code:
var
uiVBO:array[0..5]of UINT;
uiVAO:array[0..2]of UINT;
pos_id, col_id: GLint;
procedure TForm1.InitScene;
begin
ProgramID := InitShader;
glUseProgram(programID);
glClearColor(0.0,0.5,1.0,1.0);//Hintergrundfarbe: Hier ein leichtes Blau
// Enable depth test
glEnable(GL_DEPTH_TEST);
// Accept fragment if it closer to the camera than the former one
Ich habe noch was komisches in meinem Quelltext gefunden.
Wen ich es richtig verstehe, ist outColor auch undefiniert. In verschiedenen Tutorials über Licht habe ich gelesen, das man gl_FragColor nehmen kann. Auch diese Zeilen sind verschieden. alt: in vec4 Color; neu: varying vec4 Color;
Code:
#version 330
invec4 Color;// interpolierte Farbe vom Vertexshader
outvec4 outColor;// ausgegebene Farbe
void main(void)
{
outColor = Color;
}
Code:
#version 330
varyingvec4 Color // interpolierte Farbe vom Vertexshader
Registriert: Mi Aug 14, 2013 21:17 Beiträge: 588
Programmiersprache: C++
gl_FragColor und varying sind deprecated. Bei deren Benutzung in #version 330 wird der Compiler mindestens eine Warnung ausspucken. Aktuell sind in und out. outColor kannst du allerdings benennen, wie du willst. Da es die einzige out-Variable im Fragmentshader ist, weiß der Compiler, dass die Farbe gemeint ist.
Man kann auch mehr als nur eine Farbe im Fragmentshader ausgeben. Wie man dem Treiber dann sagt, welche Variable was sein soll, wüsste ich auch gerne. Vielleicht weiß das ja jemand hier.
_________________ So aktivierst du Syntaxhighlighting im Forum: [code=pascal ][/code], [code=cpp ][/code], [code=java ][/code] oder [code=glsl ][/code] (ohne die Leerzeichen)
Die Sprache hat sich nicht soo grundsätzlich geändert. Die wesentlichen Änderungen sind:
Alle eingebauten Variablen sind verschwunden (Ausnahme: gl_Position und gl_PointSize im Vertexshader, gl_FragCoord im Fragmentshader und wenige andere). Sie werden nun bei Bedarf selbst deklariert und übergeben.
Statt attribute wird im Vertexshader nun in geschrieben.
varying gibt es nicht mehr. Stattdessen werden diese Variablen im VS mit out und im FS mit in deklariert.
In der ersten Zeile jedes Shaders wird nun eine #version-Direktive geschrieben, z.B. #version 330 oder #version 120
Da die OpenGL-Funktionen zum Verwalten der Shader inzwischen im Kern angekommen sind, fällt natürlich das ARB am Ende weg.
_________________ So aktivierst du Syntaxhighlighting im Forum: [code=pascal ][/code], [code=cpp ][/code], [code=java ][/code] oder [code=glsl ][/code] (ohne die Leerzeichen)
Also bei Licht muss man jetzt ein wenig anders vorgehen, weil im Gegensatz zu früher als eine kleine feste Menge an Möglichkeiten vorgegeben war, man jetzt das Lighting selber programmieren kann.
Im Gegensatz zu früher, solltest du dir jetzt also erstmal überlegen, was du überhaupt benötigst um genau das dann in GLSL umzusetzen. Ich würde für den Anfang mal ein Pointlight umsetzen. Directionallight kann man damit im Prinzip ersetzen, wenn man die Lichtquelle weit genug weg setzt und Spotlights sind eher selten notwendig und sind außerdem genau genommen ein Pointlight mit einen Schatten außenrum. Viele Anwendungen brauchen auch kein Lighting oder es läuft da komplett anders ab. (2D) Wie in einen anderem Thema bereits ausgeführt, würde ich auch davon absehen, die Materialeigenschaften farbig zu speichern wie es auch früher in der Fixed-Pipeline der Fall war. Außerdem macht es heutzutage Sinn, die Lichtberechnung pro Fragment und nicht pro Vertex auzuführen. Gerade Glanzlicht sieht dann einfach deutlich besser aus und die Modelle müssen für gute Lichter nicht mehr unterteilt werden.
Diesen Code sollte für ein Point Light funktionieren, du musst ihn also möglicherweise noch erweitern. (zb. mehrere Lichter) Da ich ihn jetzt auf die Schnelle nicht ausprobiert habe keine 100% Funktionsgarantie.
Ich habe die Werte durch Konstanten ersetzt und die Texturenfunktion gelöscht. Von Licht keine Spur. Das einzige die Farben sehen komisch aus. Wen wenigsten die Farben beim drehen sich ändern würden. Habe ich da mit Normal und Position einen Fehler ?
Registriert: Mi Aug 14, 2013 21:17 Beiträge: 588
Programmiersprache: C++
Zum Fragmentshader:
Code:
float AmbientStrength =(0,1);
Fließkommazahlen schreibt man in GLSL nicht mit Komma, sondern mit Punkt. Die Klammern brauchst du dabei nicht. Schluckt der Compiler das einfach so?
Zum Vertexshader: Du solltest nicht den Positionsvektor als Normalenvektor missbrauchen. Steck die Normalen einfach mit ins VBO. Möglicherweise möchtest du inPos nicht einfach nach Position kopieren, sondern vorher mit meinMatrix multiplizieren. Dann vergiss nicht, Dies mit dem Normalenvektor ebenfalls zu tun:
Code:
Position = meinMatrix * inPos;
Normal =mat3(meinMatrix)* inNormal;
_________________ So aktivierst du Syntaxhighlighting im Forum: [code=pascal ][/code], [code=cpp ][/code], [code=java ][/code] oder [code=glsl ][/code] (ohne die Leerzeichen)
Ich vermute, die Normalen stimmen nicht. Du kannst auch einfach mal zum Testen die eizelnen Wertei wie Normalen im Shader ausgeben lassen. Also einfach zum Beispiel: "FragColor = vec4(NormalizedNormal, 1.0);"
Zitat:
Dann vergiss nicht, Dies mit dem Normalenvektor ebenfalls zu tun:
Das stimmt, allerdings sollte das so nicht funktionieren. Ich habe gerade so im Kopf, dass man Normalen mit der transponierten inversen Matrix multiplizieren muss. Warum das so ist, kann ich allerdings auch gerade nicht sagen, aber es gibt sicher einen mathematischen Grund.
Fließkommazahlen schreibt man in GLSL nicht mit Komma, sondern mit Punkt. Die Klammern brauchst du dabei nicht. Schluckt der Compiler das einfach so?
Komisch der Compiler hat das ',' geschluckt, sonst hätte ich dies gemerkt. Vielleicht hat der Compiler dies als Array angenommen. Ich habe die Klammern weggenommen und die ',' durch '.' ersetzt. Der Vertexshader habe ich abgeändert aber es kommt zur Fehlermeldung bei diesen beiden Zeilen. Was kommt in inNormal ?
Mitglieder in diesem Forum: 0 Mitglieder und 2 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.