2012-03-27 12 views
0

ich durch das Tutorial werde bei http://arcsynthesis.org/gltut/Positioning/Tut03%20More%20Power%20To%20The%20Shaders.htmlopengl Fragment-Shader bedingte Anweisung ausgelöst nicht

Ich bin zur Zeit auf einer Lektion, die ein Dreieck entsteht, bewegt er sich in einer kreisförmigen Richtung und nach und nach die Farbe von weiß zu grün wechseln. Die Farbe springt nach einem vollständigen Zyklus wieder auf Weiß zurück. Ich versuche, die Farbe schrittweise von Weiß zu Grün und zurück zu bewegen. Meine Bedingungsanweisung zum Festlegen meiner Farbänderungsrichtung scheint niemals als wahr auszuwerten, sodass meine Änderung niemals wirksam wird.

Hier ist mein Fragment Shader.

#version 330 

out vec4 outputColor; 

uniform float fragLoopDuration; //5.0f 
uniform float time; 


const vec4 firstColor = vec4(1.0f, 1.0f, 1.0f, 1.0f); 
const vec4 secondColor = vec4(0.0f, 1.0f, 0.0f, 1.0f); 

void main() 
{ 
    bool myFlag = false; //flag will indicate which direction color change will take. 
    float currTime = mod(time, fragLoopDuration); 
    float currLerp = currTime/fragLoopDuration; //currLerp range = (0.0f-1.0f) 
    if (currLerp == 0.9f) myFlag = !myFlag; //this flag is not geting triggered. 
    if (myFlag) outputColor = mix(secondColor, firstColor, currLerp * -1.0f + 1.0f); //green to white 
    if (!myFlag) outputColor = mix(firstColor, secondColor, currLerp); //white to green 
} 
+0

So ..., was Ihre Frage ? –

+0

Sorry, Problem ist meine bedingte Anweisung zu setzen mein Flag scheint nie als wahr auszuwerten. So tritt meine gewünschte Änderung der Farbe nie auf. – Paul

Antwort

2

Leider Problem ist meine bedingte Anweisung meines Flag zu setzen scheint nie zu true ausgewertet.

Was erwarten Sie? Damit currLerpgenau gleich 0,9f, currTime und fragLoopDuration sein kann, müssen sehr spezifische und sehr genaue Werte sein. Wenn currTime ist sogar leicht aus, um sogar 0,000001, dann currLerp wird nicht genau gleich 0,9f, und damit Ihre Bedingung wird nie wahr sein.

Im Allgemeinen sollten Sie nie einen Float für Gleichheit testen. Das heißt, gleich einem anderen Wert.

Und auch wenn es genau gleich ist, wird es immer nur passieren einmal. Es wird also auf genau einem Bild wahr sein; das nächste Bild, wenn currLerp ist 0,95f oder etwas, es wird wieder falsch sein.

Ich schätze, Sie meinen >= eher als ==.


Als Nebenwirkung wird der Code strukturiert nicht, wie die meisten Programmierer es tun würde.

Sie haben dieses Flag gesetzt. Dann haben Sie zwei if-Anweisungen, eine, die ausgeführt wird, wenn das Flag wahr ist, und eine, die ausgeführt wird, wenn das Flag falsch ist. Dies ist eine Verschwendung und schlechte Codierung Stil. So ziemlich jede Sprache mit if wird auch eine Form von else haben: die Sache, die passiert, wenn die Bedingung nicht wahr ist.

Der Standard-Weg, dies zu tun, ist hier:

if (myFlag) 
    outputColor = mix(secondColor, firstColor, currLerp * -1.0f + 1.0f); 
else 
    outputColor = mix(firstColor, secondColor, currLerp); 

Und da Sie myFlag nur einmal verwenden, gibt es keinen Punkt in sogar eine Variable mit:

if (currLerp == 0.9f) //Fix this, of course 
    outputColor = mix(secondColor, firstColor, currLerp * -1.0f + 1.0f); 
else 
    outputColor = mix(firstColor, secondColor, currLerp); 
+0

Danke für die Stilkritik. Vielleicht könntest du auch sagen, wie du meinen gewünschten Effekt erreichen kannst? – Paul

+0

@Paul: Wenn ich dir nur die Antwort geben würde, [hätte ich es nicht als weitere Studie zugewiesen] (http://stackoverflow.com/users/734069/nicol-bolas);) –

+0

if (currLerp <0.5f) outputColor = mix (secondColor, firstColor, currLerp); sonst outputColor = mix (firstColor, secondColor, currLerp); Dies führt zu einem sanften Übergang, jedoch leidet die Farbintensität für Grün, weil niemals ein voller currLerp-Wert erreicht wird. Erfüllt dies die Anforderungen oder gab es eine andere Lösung? – Paul