DGL • Thema anzeigen - Shader- & CubeMap-Problem

Shader- & CubeMap-Problem

Moderator: DGL-Team

Seite 1 von 1

[ 4 Beiträge ]

Druckansicht

Vorheriges Thema | Nächstes Thema

Autor

Nachricht

WhiteHunter

Betreff des Beitrags: Shader- & CubeMap-Problem

Verfasst: Fr Aug 18, 2006 00:58

DGL Member

Registriert: Mo Sep 02, 2002 15:41
Beiträge: 867
Wohnort: nahe Stuttgart

Hi,

ich hab da ein kleines Problemchen, an dems grade happert. Ich rendere eine SkyBox mit einer CubeMap. Davor drehe ich die Texturen entsprechend einer Dauerrotation, danach zurück und um 180° (was seltsamerweise nur mit glRotatef(Pi, 0, 1, 0); funktioniert, obwohl alle anderen (Textur-)Rotationen in Grad erfolgen; was aber nichts mit dem Problem zu tun hat) verdreht, damit es auf dem nun gerenderten kleinen Cube vor mir gespiegelt aussieht. Nun will ich da noch einen Shader drauflegen. Allerdings lasse ich derzeit OpenGL mittels glTexGen bzw. über die glBitmap.pas die Texturkoordinaten berechnen. Nun sind diese anscheinend nicht in glSlang verfügbar, da der Cube typisch texturkoordinatenlos-einfarbig blieb. Das brachte mich dann auf diesen Thread, wo es zwar nicht um CubeMaps geht, was aber auch nicht mein Problem löst.

Zusammengefasst:

Mit Angaben von 2-dimensionalen Texturkoordinaten erhalte ich ein seltsam verzerrtes Bild mit Strahlen, zwar nicht vom Vertex- sondern vom Bildschirm-Mittelpunkt ausgehend, die texturähnliche Farben haben. Siehe auch Bild imAnhang.
Mit Angaben von 3-dimensionalen Texturkoordinaten erhalte ich zwar eine Textur, aber nur eine statische Fassung.
Mit der ObjectPlane- oder EyePlane-Lösung aus dem oben genannten Thread
Code:
1. vec4 ecPosition = gl_ModelViewMatrix * gl_Vertex;
2. gl_TexCoord[0].s = dot( ecPosition, gl_ObjectPlaneS[0] );
3. gl_TexCoord[0].t = dot( ecPosition, gl_ObjectPlaneT[0] );
4. gl_TexCoord[0].p = dot( ecPosition, gl_ObjectPlaneR[0] );
5. gl_TexCoord[0].q = dot( ecPosition, gl_ObjectPlaneQ[0] );
das gleiche Ergebnis wie mit 2-dimensionalen Texturkoordinaten
Mit deaktiviertem Shader funktioniert alles wunderbar, der Shader wird auch ohne Meldung kompiliert.

=> Wie kann ich also nun meine CubeMap mit glTexGen wie in glBitmap.pas mit einem Shader benutzen?

Hier nochmal mein derzeitiger kompletter Shadercode, falls doch irgendwo Fehler sein sollten:
Vertex:

Code:

void main(void)
{
        vec4 ecPosition = gl_ModelViewMatrix * gl_Vertex;
        gl_TexCoord[0].s = dot( ecPosition, gl_ObjectPlaneS[0] );
        gl_TexCoord[0].t = dot( ecPosition, gl_ObjectPlaneT[0] );
        gl_TexCoord[0].p = dot( ecPosition, gl_ObjectPlaneR[0] );
        gl_TexCoord[0].q = dot( ecPosition, gl_ObjectPlaneQ[0] );
        gl_Position = ftransform();
}

Fragment:

Code:

uniform samplerCube texUnit1;
 
void main(void)
{
        gl_FragColor = textureCube(texUnit1, vec3(gl_TexCoord[0]));
}

"Intern":

Code:

tCubeMap := TGLBitmapCubeMap.Create;
  for i := 0 to 5 do
  begin
    tCubeMap.LoadFromFile(ExtractFilePath(Application.ExeName)+'tex\cubemap'+tex[i]+'.bmp');
    tCubeMap.GenerateCubeMap(GL_TEXTURE_CUBE_MAP_POSITIVE_X_ARB+i);
  end;
   tCubeMap.Bind;
....
glUniform1i(glGetUniformLocationARB(SP.GetObject, PGLCharARB('texUnit1')), 0);
 

(glBitmap.pas Version 1.8.9 und dglOpenGL-Header Version 2.0)
Falls es eine Rolle spielen sollte, Treiber ist 91.31 ForceWare auf einem NV 7900GT-Chip und wie gesagt, ansonsten funktioniert alles prächtig.
Schonmal Danke im Voraus und fürs Durchlesen, ist etwas lang geworden.

MfG

Dateianhänge:

Dateikommentar: beschriebenes Renderverhalten, siehe Posting

screen_error1.jpg [177.1 KiB]
72-mal heruntergeladen

Nach oben

Sascha Willems

Betreff des Beitrags:

Verfasst: Fr Aug 18, 2006 12:23

DGL Member

Registriert: Mo Sep 23, 2002 19:27
Beiträge: 5812
Programmiersprache: C++

Zumindest in der 87.xxer Treiberreihe gabs (wenn ich recht entsinne) Probleme mit der Texturkoordinatengenerierung bei Nutzung von glsl, aber evlt. helfen die Shader hier weiter, die ich "damals" für meine 3D-Engine geschrieben habe, die verzichten da nämlich komplett drauf :

Vertexprogramm :

Code:

uniform vec4 light;
 
varying vec4 V_eye;
varying vec4 L_eye;
varying vec4 N_eye;
varying vec3 normal;
 
void main()
 {
 V_eye = gl_ModelViewMatrix * gl_Vertex;
 L_eye = (gl_ModelViewMatrix * light) - V_eye;
 N_eye = vec4(gl_NormalMatrix * gl_Normal, 1.0);
 
 gl_Position = gl_ProjectionMatrix * V_eye;
 V_eye = -V_eye;
 
 normal         = gl_Normal;
 }
 

Fragmentprogramm :

Code:

uniform samplerCube cubemap;
 
varying vec3 normal;
varying vec4 V_eye;
varying vec4 L_eye;
varying vec4 N_eye;
 
const float sharpness = 0.1;
 
void main()
 {
 gl_FragColor = textureCube(cubemap, normal, 0);
 }
 

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Nach oben

WhiteHunter

Betreff des Beitrags:

Verfasst: Fr Aug 18, 2006 13:45

DGL Member

Registriert: Mo Sep 02, 2002 15:41
Beiträge: 867
Wohnort: nahe Stuttgart

Nach einigem Ausprobieren und Weitersuchen bin ich auf eine Variante, mit zwar nicht identischen, aber für mich erstmal ausreichenden Ergebnissen "gestoßen":

Vertex:

Code:

void main()
{
        gl_Position = ftransform();
        gl_TexCoord[0] = ((gl_TextureMatrix[0] * gl_ModelViewMatrix)
                            * gl_Vertex) * vec4(1.0, 1.0, -1.0, 1.0);
}

Im Fragment die normale Texturkoordinatenübernahme.
Mich hat zunächst die gespiegelte Matrix überrascht, aber da es soweit funktioniert, dürfte es kein totaler Blödsinn sein.

MfG

Nach oben

WhiteHunter

Betreff des Beitrags:

Verfasst: Di Aug 22, 2006 10:37

DGL Member

Registriert: Mo Sep 02, 2002 15:41
Beiträge: 867
Wohnort: nahe Stuttgart

Nun hat mich die Sache irgendwie nicht losgelassen, da es bis jetzt nicht sonderlich gut aussieht und ich glaube, ich habe auch eine korrekte Lösung gefunden.
Also hab ich mir mal die Specifications zu OpenGL 2.0 angesehen. Dort fand sich Folgendes zu glTexGen:

Zitat:

If TEXTURE GEN MODE indicates REFLECTION MAP, compute the reflection
vector r as described for the SPHERE MAP mode. Then the value assigned to an
s coordinate is s = rx; the value assigned to a t coordinate is t = ry; and the value
assigned to an r coordinate is r = rz.
[...]
SPHERE MAP texture coordinates are generated
as follows. Denote the unit vector pointing from the origin to the vertex
(in eye coordinates) by u. Denote the current normal, after transformation to eye
coordinates, by nf . Let r = ( rx ry rz )T , the reflection vector, be given by
r = u − 2nfT (nfu) , [...]

Nun klingt "unit vector pointing from the origin to the vertex (in eye coords)" für mich wie

Code:

normalize(gl_Vertex * gl_ModelViewMatrix);

und "current normal, after transformation to eye coords" auch wie

Code:

normalize(gl_Normal * gl_NormalMatrix);

Nun gibt es in glSlang auch reflect(I, N), was "I – 2 * dot(N, I) * N" berechnet. Da nun REFLECTION_MAP und reflect irgendwie beieinander liegen, müsste die transponierte Matrix weiter oben irgendwie auch für ein Skalarprodukt stehen (zumindest hab ich da irgendwas in Erinnerung).
Daraus hab ich jetzt das gebastelt:

Code:

 
void main()
{
    gl_Position = ftransform();
    vec3 verNormal = normalize(gl_NormalMatrix * gl_Normal);
    vec4 verPosition = normalize(gl_ModelViewMatrix * gl_Vertex);
    gl_TexCoord[0] = vec4(reflect(vec3(verPosition), verNormal), 1.0);
}
 

Für mich sieht es derzeit ziemlich passend aus, obwohl mir aufgefallen ist, dass ich dringend Normalen korrigieren und noch was an der Textur-Drehung feilen muss. Auf jedenfall Danke an Sascha für Codeschnipsel, der mir einiges an Anregung gegeben hat.
Sollte nun doch jemand noch einen meiner berühmten Denkfehler entdecken, immer her damit.

MfG

Nach oben

Seite 1 von 1

[ 4 Beiträge ]

Foren-Übersicht » Programmierung » Shader

Wer ist online?

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.