DGL • Thema anzeigen - GLSL Unterschiede ATI<->NVidia

GLSL Unterschiede ATI<->NVidia

Moderator: DGL-Team

Seite 1 von 1

[ 13 Beiträge ]

Druckansicht

Vorheriges Thema | Nächstes Thema

Autor

Nachricht

mahe

Betreff des Beitrags: GLSL Unterschiede ATI<->NVidia

Verfasst: Di Feb 24, 2009 21:17

DGL Member

Registriert: So Feb 22, 2009 17:34
Beiträge: 5

Hallo erstmal! (mein erster Post)

Erstmal möchte ich mich für die unglaubliche Menge an Wissen, welche ihr in Eurem Wiki bereitstellt, bedanken!
Da ich nur sporadisch mit OpenGL arbeite ist dies wirklich eine große Hilfe für mich.

Nun zu meinem Problem:

Ich hab mir einen Shader gebastelt welcher meine Sprites (nur 2D und orthogonal) mittels Normalmap mit einer schönen Beleuchtung versieht.
Das funktioniert auch einwandfrei aber leider nur auf einem PC.
Hier wo es das tut was es soll habe ich eine ATI-X1800, auf einem zweiten PC mit einer Geforce 6200 sieht alles etwas seltsam aus.

Zur Veranschaulichung füge hier zwei Bilder:
So soll es sein (ATI): http://files.terraex.de/ATI-X1800.JPG
So siehts mit Nvidia aus: http://files.terraex.de/Geforce6200.JPG

Und hier ist der entsprechende Shader: http://files.terraex.de/shader.txt

Die Nvidia-Karte oder deren Treiber scheinen überhaupt etwas seltsam zu arbeiten.
Zum Beispiel kompilierte es nicht als ich in zwei Funktionen jeweils eine lokale Variable mit selben Namen hatte.

Da ich mich hier im Forum schon eine Zeit herumtreibe und mir scheint, dass einige sehr erfahrene Leute hier sind, hoffe ich, dass mir jemand irgendwie weiterhelfen kann.

Nach oben

Schläfer

Betreff des Beitrags:

Verfasst: Di Feb 24, 2009 21:45

DGL Member

Registriert: Fr Okt 03, 2008 13:32
Beiträge: 367

Hm, die Farben werden mit "att", sowie die jeweiligen Lichtteile mit "diff" und "spec", multipliziert. Dabei wird aber auch der Alphawert verändert, sodass weiter entfernte oder vom Licht abgewandte Teile transparent werden. Beim Specularanteil ist das vielleicht egal, aber bei Diffuse nicht so gut, denke ich.

Nach oben

mahe

Betreff des Beitrags:

Verfasst: Di Feb 24, 2009 22:02

DGL Member

Registriert: So Feb 22, 2009 17:34
Beiträge: 5

Oja, das hab ich übersehen.

Ich hab den Alpha-Anteil jetzt herausgenommen und berechne den nur über die zwei Texturen:

Code:

gl_FragColor = vec4( color.rgb*lightRes.rgb, color.a*normal.a);

Interessant dass das hier am PC überhaupt nicht ausgewirkt hat.

Auf jeden Fall sind die Affen jetzt auch am anderen PC nicht mehr durchsichtig.
Die Farben stimmen allerdings immer noch nicht und die Farb-Textur wird anscheinend auch nicht einberechnet.
Also bis auf die Transparenz keine Verbesserung

Nach oben

Coolcat

Betreff des Beitrags:

Verfasst: Di Feb 24, 2009 22:36

DGL Member

Registriert: Do Dez 29, 2005 12:28
Beiträge: 2249
Wohnort: Düsseldorf
Programmiersprache: C++, C#, Java

Was ist der Sinn dieser Rotations-Matrix? Was spricht gegen gl_NormalMatrix? (da wäre dann komplett ModelView drin, also auch Kamerabewegung und sowas)

Warum rechnest du da manchmal Vektor * Matrix und nicht Matrix * Vektor, was richtig wäre? Da ich dazu keine Definition finde, wäre es möglich das der ATI-Treiber das einfach umdreht, also Matrix * Vektor rechnet, und Nvidia das macht was du sagst...was natürlich in Müll resultiert.

_________________
Yeah! :mrgreen:

Nach oben

mahe

Betreff des Beitrags:

Verfasst: Di Feb 24, 2009 23:08

DGL Member

Registriert: So Feb 22, 2009 17:34
Beiträge: 5

Die Rotationsmatrix hat eigentlich nur historische Gründe und ich habs einfach noch nicht entfernt

Habs aber nachgeholt und das hat wie erwartet keine Auswirkungen.

Wegen den Matrizen-Multiplikationen:
Die Rotationsmatrix ist doch die einzige Matrix die ich habe. Alles andere sind Vektoren und Skalare.
Ich hab dort sicherheitshalber die Faktoren vertauscht (Matrix*Vektor), hat jedoch auch nichts bewirkt.

Nach oben

Coolcat

Betreff des Beitrags:

Verfasst: Di Feb 24, 2009 23:31

DGL Member

Registriert: Do Dez 29, 2005 12:28
Beiträge: 2249
Wohnort: Düsseldorf
Programmiersprache: C++, C#, Java

Zitat:

Die Rotationsmatrix ist doch die einzige Matrix die ich habe.

Du hast da noch ne gl_TextureMatrix[0]

Zeig doch nochmal den aktuellen Code...ich habe keine Lust mir jetzt deine Änderungen da rein zu denken

_________________
Yeah! :mrgreen:

Nach oben

mahe

Betreff des Beitrags:

Verfasst: Mi Feb 25, 2009 12:30

DGL Member

Registriert: So Feb 22, 2009 17:34
Beiträge: 5

Danke erstmal für Deine bisherige Hilfe!

So sieht der Shader jetzt aus:

Code:

(Vertex-Shader)
void main(void)
{
    gl_Position = ftransform();
    gl_TexCoord[0] = gl_TextureMatrix[0] * gl_MultiTexCoord0;
}
 
(Fragment-Shader)
uniform sampler2D colorMap;
uniform sampler2D normalMap;
uniform int lights;
 
vec4 lighting(gl_LightSourceParameters light, vec3 normal) {
 
    float att;
    vec3 lightVector;
 
    if (light.position.w != 0.0) {
        float dist = distance(light.position.xyz, gl_FragCoord.xyz);
        att  = light.constantAttenuation;
        att += light.linearAttenuation * dist;
        att += light.quadraticAttenuation * dist * dist;
        att  = 1.0 / att;
        lightVector = normalize(light.position.xyz - gl_FragCoord.xyz);
    } else {
        att = 1.0;
        lightVector = normalize(light.position.xyz);
    }
 
    vec3 reflectVector = reflect(-lightVector, normal);
    vec3 viewVector = vec3(0,0,1);
 
    float diff = max( dot(normal, lightVector), 0.0 );
    float spec = max( dot(reflectVector, viewVector), 0.0 );
    spec = pow(spec, gl_FrontMaterial.shininess);
 
    vec4 ambient  = gl_FrontMaterial.ambient  * light.ambient;
    vec4 diffuse  = gl_FrontMaterial.diffuse  * light.diffuse  * diff;
    vec4 specular = gl_FrontMaterial.specular * light.specular * spec;
 
    vec4 color = ambient + diffuse + specular;
 
    return color * att;
}
 
 
void main (void)
{
    vec2 texCoord = gl_TexCoord[0].st;
    vec4 color  = texture2D(colorMap,  texCoord);
    vec4 normal = texture2D(normalMap, texCoord);
    vec3 normalVector = gl_NormalMatrix * normalize( normal.xyz-0.5 );
        
    vec4 lightRes = lighting(gl_LightSource[0], normalVector);
    if (lights > 1) {lightRes += lighting(gl_LightSource[1], normalVector);}
    if (lights > 2) {lightRes += lighting(gl_LightSource[2], normalVector);}
    /*if (lights > 3) {lightRes += lighting(gl_LightSource[3], normalVector);}
    if (lights > 4) {lightRes += lighting(gl_LightSource[4], normalVector);}
    if (lights > 5) {lightRes += lighting(gl_LightSource[5], normalVector);}
    if (lights > 6) {lightRes += lighting(gl_LightSource[6], normalVector);}
    if (lights > 7) {lightRes += lighting(gl_LightSource[7], normalVector);}*/
    
    gl_FragColor = vec4( color.rgb*lightRes.rgb, color.a*normal.a);
}
 

Ich hab gehofft, dass ich einen offensichtlichen Fehler mache der einfach behoben ist (was ja auch teilweise der Fall war

).

Aber ansonsten werde ich in den nächsten Tagen schrittweise versuchen den Fehler zu eruieren.
Muss mich nur am anderen PC ein bisschen besser einrichten damit das Testen schneller geht.

Nach oben

Coolcat

Betreff des Beitrags:

Verfasst: Mi Feb 25, 2009 12:58

DGL Member

Registriert: Do Dez 29, 2005 12:28
Beiträge: 2249
Wohnort: Düsseldorf
Programmiersprache: C++, C#, Java

Zitat:

Ich hab gehofft, dass ich einen offensichtlichen Fehler mache der einfach behoben ist

Noch was gefunden....

Code:

float dist = distance(light.position.xyz, gl_FragCoord.xyz);

Du vergleichst da Punkte aus verschiedenen Vektorräumen. gl_FragCoord ist in Fensterkoordinaten!

Füge ein varying position im Vertexshader ein und arbeite dann damit.

Code:

varying vec4 position;
 
position = gl_ModelViewMatrix * gl_Position;

Allerdings dürfte das keinen Unterschied bei der Grafikkarte machen.

_________________
Yeah! :mrgreen:

Nach oben

damadmax

Betreff des Beitrags:

Verfasst: Mi Feb 25, 2009 13:22

DGL Member

Registriert: Sa Aug 18, 2007 18:47
Beiträge: 694
Wohnort: Köln
Programmiersprache: Java

Code:

gl_FragColor = vec4( color.rgb*lightRes.rgb, color.a*normal.a);

Ich mag mich jetzt irren. Aber was soll in "normal.a" drin stehen? Ich kenne Normalmaps nur in 24bittige Ausführung.

Eventuell könnte hier auch noch ein problem liegen.

Code:

vec3 normalVector = gl_NormalMatrix * normalize( normal.xyz-0.5 );

Code:

vec3 normalVector = gl_NormalMatrix * normalize( normal.xyz - vec3(0.5) );

Vielleicht interpretieren die Treiber das unterschiedlich.

_________________
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"

on error goto next

Nach oben

Coolcat

Betreff des Beitrags:

Verfasst: Mi Feb 25, 2009 13:49

DGL Member

Registriert: Do Dez 29, 2005 12:28
Beiträge: 2249
Wohnort: Düsseldorf
Programmiersprache: C++, C#, Java

Zitat:

Vielleicht interpretieren die Treiber das unterschiedlich.

Also das ist in der Spezifikation so definiert, aber nen Versuch ist es natürlich Wert.

_________________
Yeah! :mrgreen:

Nach oben

Kyro

Betreff des Beitrags:

Verfasst: Mi Feb 25, 2009 18:51

DGL Member

Registriert: So Okt 26, 2003 20:07
Beiträge: 249

Coolcat hat geschrieben:

Zitat:

Ich hab gehofft, dass ich einen offensichtlichen Fehler mache der einfach behoben ist

Noch was gefunden....

Code:

float dist = distance(light.position.xyz, gl_FragCoord.xyz);

Du vergleichst da Punkte aus verschiedenen Vektorräumen. gl_FragCoord ist in Fensterkoordinaten!

Füge ein varying position im Vertexshader ein und arbeite dann damit.

Code:

varying vec4 position;
 
position = gl_ModelViewMatrix * gl_Position;

Allerdings dürfte das keinen Unterschied bei der Grafikkarte machen.

selbes gilt natürlich auch für

Code:

lightVector = normalize(light.position.xyz - gl_FragCoord.xyz);

ich wär mir nicht so sicher, dass es am shader liegt. Für mich sieht das eher so aus, als würde was bei der Samplerübergabe im Programm nicht passen und beide Sampler die Normalmap-Pipeline ansprechen - Zeig diesen Code auch mal.

_________________
I'm not the signature, I'm just cleaning the floor...

Derzeitiges Projekt:
FireBlade Particle Engine (Release R2 2009.06.29)

Nach oben

mahe

Betreff des Beitrags:

Verfasst: Do Feb 26, 2009 16:46

DGL Member

Registriert: So Feb 22, 2009 17:34
Beiträge: 5

Coolcat hat geschrieben:

Code:

float dist = distance(light.position.xyz, gl_FragCoord.xyz);

Du vergleichst da Punkte aus verschiedenen Vektorräumen. gl_FragCoord ist in Fensterkoordinaten!

Füge ein varying position im Vertexshader ein und arbeite dann damit.

Code:

varying vec4 position;
 
position = gl_ModelViewMatrix * gl_Position;

Allerdings dürfte das keinen Unterschied bei der Grafikkarte machen.

Müsste in meinem Fall auch - bis auf die Z-Koordinate des Sprites - aufs selbe rauskommen.

damadmax hat geschrieben:

Ich mag mich jetzt irren. Aber was soll in "normal.a" drin stehen? Ich kenne Normalmaps nur in 24bittige Ausführung.

Da es meine Normal-Map ist, weiß ich, dass da ein Alpha-Kanal ist :wink:

Dafür hat die ColorMap keinen bzw. keinen interessanten.

Kyro hat geschrieben:

Ja, sieht leider wirklich nicht mehr nach einem Shader-Problem aus.
Die Transparenz am Anfang lag wirklich an der Berücksichtigung des Alpha-Kanals beim Licht.
Die bunten Farben rühren aber scheinbar wo anders her.

Ich hab einen einfachen Shader ausprobiert der eine Textur ohne Änderung anzeigen sollte und das hat auch nicht funktioniert.

Da ich festgestellt habe, dass die Shader-Unterstützung bei weitem nicht so verbreitet ist wie ich gedacht habe, werd ich mein Programm sowieso umschreiben müssen damit es auch ohne funktioniert.
Bei der Gelegenheit werd ich die OpenGL-Befehle usw. untersuchen.

Muss ich eigentlich immer alle Uniforms neu übergeben wenn ich einen Shader verwende (mache ich jetzt) oder reicht es Änderungen zu übergeben?
Ich meine, bleiben die Uniforms erhalten wenn ich zwischenzeitig einen anderen oder keinen Shader verwende?

Und was passiert wenn ein Uniform fehlt? Ist das Verhalten dabei definiert?

Nach oben

Coolcat

Betreff des Beitrags:

Verfasst: Do Feb 26, 2009 18:02

DGL Member

Registriert: Do Dez 29, 2005 12:28
Beiträge: 2249
Wohnort: Düsseldorf
Programmiersprache: C++, C#, Java

Zitat:

Und was passiert wenn ein Uniform fehlt? Ist das Verhalten dabei definiert?

Ja, es ist in soweit "definiert", das die entsprechende Variable dann undefiniert ist

Zitat:

Da ich festgestellt habe, dass die Shader-Unterstützung bei weitem nicht so verbreitet ist wie ich gedacht habe

Immer schön auf Extensions bzw. OpenGL-Version testen!

_________________
Yeah! :mrgreen:

Nach oben

Seite 1 von 1

[ 13 Beiträge ]

Foren-Übersicht » Programmierung » Shader

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 12 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.