4. GLSL Shader - Problem beim darstellen von Texturen

GLSL Shader - Problem beim darstellen von Texturen

  • H

    Kennst Du ein Programm mit dem ich die Shader Debuggen kann?

    Hab ich noch nie gebraucht, da man die Richtigkeit einzelner Komponenten leicht ueberpruefen kann, indem man sie ins Farbregister schreibt.

    Wo sehe ich denn ob der Shader-Compiler irgend eine Fehlermeldung anzeigt?

    Das Laden und Kompilieren des Shaders regelt OSG ja vermutlich intern und von dessen Aufbau hab ich keine Ahnung.
    Regulaer ungefaehr so:

    char *shadersource= ...;
   int shadersize= ...
   unsigned int prog= glCreateProgramObjectARB();
   GLhandleARB shader = glCreateShaderObjectARB( ... );
   glShaderSourceARB(shader, 1, (const char**)&shadersource, &shadersize);

   glCompileShaderARB(shader);
   GLint compileStatus;
   glGetObjectParameterivARB(shader, GL_OBJECT_COMPILE_STATUS_ARB, &compileStatus);
   if (compileStatus!=GL_TRUE) // fehler: meldung auslesen
   {
	GLint size;
	glGetObjectParameterivARB(shader, GL_OBJECT_INFO_LOG_LENGTH_ARB, &size);
	if (size)
	{
		GLcharARB *log = (GLcharARB *) malloc(infoLogLength);
		glGetInfoLogARB(shader, size, NULL, log);
		printf(log);
		free(log);
	}
    0
  • J

    Hallo,
    habe jetzt mal ueberprueft ob der Shader richtig compiliert wird und er scheint wohl richtig zu sein. Ich bekommen die Meldung

    Linking osg::Program "" id=1 contextID=0
    Uniform "tex" loc=0 size=1 type=sampler2D

    Doch was koennte es denn jetzt sein? Wo kann ich den Fehler denn jetzt suchen?
    Hat jemand eine Idee?

    Danke

    0
  • H

    Wo kann ich den Fehler denn jetzt suchen?

    Ueberpruefe zunaechst ob die Fixed-Function-Pipeline wirklich korrekte Ergebnisse liefert (und diese nicht nur durch irgendwelche Renderstate-Reste produziert).
    Pruefe ob der Shader aktiv ist (indem Du zb eine definierte Farbe in gl_FragColor schreibst) und ob gl_MultiTexCoord0.st sinnvolle Daten enthaelt (dh ob Deine Vertexstruktur korrekt ist).

    0
  • J

    Also der Shader ist aktiv das habe ich schon gelegentlich mit einer Farbe getestet.
    Die FFP liefert korrekte Ergebnisse da bin ich mir sicher aber wie ueberpruefe ich ob gl_MultiTexCoord0.st sinnvolle Daten enthaelt?

    0
  • H

    gl_FragColor= vec4(gl_MultiTexCoord0.st, 0,0); sollte 'nen sinnvollen Gradient zeigen

    0
  • J

    also gl_MultiTexCoords0.st ergibt einfach nur schwarz wenn ich aber gl_MultiTexCoords1.st verwende
    bekomme ich ein sinnvollen Gradienten.
    Er zeigt einen Verlauf von Rot->Gelb->Gruen->Schwarz, aber warum nicht bei gl_MultiTexCoords0.st?

    0
  • H

    wenn ich gl_MultiTexCoords1.st verwende bekomme ich ein sinnvollen Gradienten, aber warum nicht bei gl_MultiTexCoords0.st?

    Schwer zu sagen.
    So wie das in den Beispielen ersichtlich ist, bindet OSG die Texturkoodinaten ja offenbar direkt an eine "Unit".
    Dem Konzept nach werden intern vermutlich mehrere Buffer gehalten, sodass kein weiteres Mapping zwischen Vertexstruktur und Shaderregistern stattfindet.
    Wahrscheinlich hast Du also nur irgendwo einen Fehler gemacht...

    0
  • J

    Ueber die Vertexstruktur kann ich nichts genaues sagen. Ich habe jetzt aber mal kein Objekt geladen sondern eine Pyramide manuell erstellt und so funktioniert es.
    Ich werd also mal naeher in das Collada Plugin von OSG schauen muessen und schauen wie ein Objekt geladen wird.

    0
  • J

    Ich habe nun rausgefunden woran es liegt. Wenn ich eine .dae Datei lade werden die Textur und die Texturkoordinaten in der TexturUnit 2 gespeichert und nicht in der TexturUnit 1. Wenn ich das aendere und alles in TexturUnit 1 gespeichert wird, funktioniert es. Wenn ich die Textur in Unit 2 belasse kann ich ja mit gl_MultiTexCoords1.st auf die Texturkoordinaten zugreifen was ich ja an dem Gradienten sehe. Nun muss ich aber auch auf die Textur in Unit 2 zugreifen was aber mein shader nicht macht. Er greift immer auf Unit 1 zu.
    Wie kann ich denn jetzt auf die Textur in der Unit 2 zugreifen?

    hier nochmal mein Fragment Shader

    uniform sampler2D tex;
varying vec2 texCoords;

void main()
{
gl_FragColor = texture2D(tex, texCoords);

}

    Vielen DAnk

    0
  • H

    Die Variable texCoords bezeichnet im Pixelshader ein "Register" das vom Vertexshader beschrieben wurde (und vom Rasterizer interpoliert wird).
    In diesem Fall (siehe Vertexshader aus erstem Post) befinden sich darin die s,t-Koordinaten aus MultiTexCoord[0].
    Du brauchst also einfach nur im Vertexshader die Daten reinschreiben die Du willst oder, wenn Du beide brauchst, ein weiteres varying definieren:

    varying vec2 tex1; 
varying vec2 tex2; 

void main()
{
    tex1= gl_MultiTexCoord0.st;
    tex2= gl_MultiTexCoord1.st;
    gl_Position = ftransform();
}

    uniform sampler2D map1;
uniform sampler2D map2;

varying vec2 tex1; 
varying vec2 tex2; 

void main()
{
  gl_FragColor = texture2D(map1, tex1)
               + texture2D(map2, tex2);
}
    0
  • J

    So hab ich das ja schonmal probiert aber eine Textur sehe ich leider nicht.
    Hier ist mein Code

    varying vec2 texCoords1;

void main()
{
	gl_Position = ftransform();
	texCoords1 = gl_MultiTexCoord1.st;

}

    uniform sampler2D tex1

varying vec2 texCoords1;

void main()
{
gl_FragColor = texture2D(tex1, texCoords1);
}
    0
  • H

    Wenn ich Deine Schilderung richtig verstehe, ist die Textur an Unit1 (also die zweite) gebunden?
    Dann brauchst Du einen zweiten Sampler.

    0
  • J

    Ja genau das ist richtig. Wenn ich es mit einem zweiten Sampler versuche hab ich das gleiche Problem. Du meinst best. so hier.

    varying vec2 texCoords1;
varying vec2 texCoords2;

void main()
{
	gl_Position = ftransform();
	texCoords1 = gl_MultiTexCoord0.st;
	texCoords2 = gl_MultiTexCoord1.st;
}

    uniform sampler2D tex1;
uniform sampler2D tex2;

varying vec2 texCoords1;
varying vec2 texCoords2;

void main()
{
gl_FragColor = texture2D(tex2, texCoords2);
}

    Wie gesagt die texCoords2 enthalt die richtigen Daten aber tex2 enthalt keine Textur

    0
  • J

    Hat keiner eine Idee, was falsch sein koennte oder was ich machen kann?

    0
Anmelden zum Antworten