Shader acting weird?
category: general [glöplog]
Hey guys,
I'm doing a parallax mapping exercise. I'm done, and it looks alright, but the shader is acting very differently to two pieces of code that I would otherwise assume yield the same result! And that's what I want to ask about.
Here's the first codesnippet which works as intended:
It gives this result:
Here is the other piece which does not work as intended, but I do not understand why:
I'm doing a parallax mapping exercise. I'm done, and it looks alright, but the shader is acting very differently to two pieces of code that I would otherwise assume yield the same result! And that's what I want to ask about.
Here's the first codesnippet which works as intended:
Code:
if(tc_dir.z < 0.0) {
while(tc.z > texture2D(tex_bump, tc.xy).r * MAX_HEIGHT && s++ < 2000) {
tc += tc_dir;
}
}It gives this result:
Here is the other piece which does not work as intended, but I do not understand why:
Code:
if(tc_dir.z < 0.0) {
while(tc.z > texture2D(tex_bump, tc.xy).r * MAX_HEIGHT && s < 2000) {
tc += tc_dir;
s++;
}
}
(And yes, all I do is moving the incrementing of s to the body of the loop)
In the first case the variable is incremented before the comparison and in the 2nd case it's incremented after, s values after the loop would be 2001 and 2000 respectively.
never liked( and used) "while {}" and never had logic operators (&&, ||) between values that don't carry brackets around them. I find the three lines almost unreadable.
What I don't get is that it shouldn't make much of a difference...
The first s++ gets always evaluated, but in the second part it does not. And the 2000 and 2001 mentioned above. It looks different because it's not thesame :)
And the second one is better than the first one because the compare might be short-circuited or not.
And the second one is better than the first one because the compare might be short-circuited or not.
The s boundary is unnecessarily high. It is just to keep the loop from infinite-looping right now, so it really shouldn't make such a big difference. I'm aware that on a fine-detail level, they are different, but still.
I agree with Navis and might add that it's bad karma to update the values which are being altered (e.g. "while (s++ < 10)" is less readable than "while (s<10) { s++; }")
altered = evaluated
The main problem here is that GLSL follows the same principle as C for short-circuit evaluation, that is in "if (a && b)" when 'a' evalueates to true, 'b' never gets executed. So if you intended that 's++' as loop limiting factor, it didn't work, because as long as the first part of the if was true, s never got incremented.
eh forget what i just said, i need more sleep
does this part get calculated on each round: texture2D(tex_bump, tc.xy).r * MAX_HEIGHT ? it looks terrible with an "8 bit" eye :)
