void mainImage( out vec4 _FragColor, in vec2 _FragCoord )
{
// standard uv fixup
vec2 p = (2.0*_FragCoord.xy-R.xy)/R.y + 0.5*vec2(sin(0.2*T),sin(0.3*T));
// get the recursion values
float i = floor(T-length(p)),
m = T - i-length(p),
z = pow(2.718, -log(3.333)*m) * .08,
v = 0.;
// get the zoom position
p = p*z+ P(i);
for (float r = 0.; r < 9.; ++r)
p += (P(i+r+1.) / 3.333) * pow(1. / 3.333, r);
// recursion
for (float r = 0.; r<9.; ++r)
{
// rotate
m = -A(i);
p=vec2(p.x*cos(m) - p.y*sin(m), p.x*sin(m) + p.y*cos(m));
// yin yang function
float b = 5.*z/min(R.y, R.x),
c = 1.0,
l = length(2.0*p + vec2(0, 1)),
d = l;
if (p.x < 0.0)
c = mix(c, 0.0, smoothstep(1.0-b, 1.0+b, l));
l = length(2.0*p - vec2(0, 1));
if (p.x > 0.0)
c = mix(0.0, c, smoothstep(1.0-b, 1.0+b, l));
if (p.y > 0.0)
d = l;
v = mix(c, v, smoothstep(1.0-b, 1.0, length(p)));
if (d > .6)
{
// stop if outside
v = mix(step(0.0, p.y), v, smoothstep(.6+.12,.6+.12+b,d));
// fix color around the edges
if (d < .72+b && p.y > 0.0) ++i;
break;
}
// which side are we on?
p.y += mix(0.5, -0.5, v = step(0.0,p.y));
// update zoom and position
z *= 2./.6;
p *= 2./.6;
// final coloring
_FragColor = vec4(v*vec3(1.+sin(i+T+i),1.+sin(i+T+1.),1.+sin(i+T+2.)),1.);
}
Win32 look (open in new tab for fullsize):
Aos4 look (open in new tab for fullsize):
In os4 version we can see some distortion (see green quads and squares), and that one not related to the other issues we reported. That kind of bug i can see also in some other shaders (through happen to be very rare), but worth to invistigate for sure.
@kas1e That's some new severe bug introduced in Warp3D Nova 1.70. Check it out, with 1.68 it still renders fine. Apparently the reason now is an "if" not working correctly anymore. In case of this shader it's this one:
// stop if outside
...
if (d < .72+b && p.y > 0.0) ++i;
I checked d, b and p.y, they seem to be valid.
Quote:
and that one not related to the other issues we reported.
I'd not be so sure about that. Looking at all those recent bugs the main broken component of Nova seems to be the register allocator which can result in all kinds of funny stuff. I mean, maybe the above "if" is simply comparing the wrong register.
Edited by Daytona675x on 2020/5/30 8:07:54 Edited by Daytona675x on 2020/5/30 13:28:34
@All Another rendering issue which i find in some shaders, can be called as "colors swapped or reverted". I think (i hope) it can be roots of one single issue, so maybe worth to check them all at the same time. For all images press open in new tab for fullsize. So:
As far as i can see, in all shaders background and color of some objects like swapped. At moment not sure wtf, but probably will be good idea to start from the smallest ones and trying to reduce it, like shader #2 and shader #4
@kas1e I guess it's not a general "and" doesn't work but simply depends on situation, which register used when etc. After all an && in this case here will certainly result in two conditional branches, just like at least the 1st working variant. It's worthless to speculate more, if register allocation is messed up everything is possible.
@all Found 4 more shaders , which we can hope share the same issue. At least i hope its the same issue, because it better to create one bug report with 8 shaders, than 8 bug reprots :)
const float PI = 3.14159265358979; //Probably enough precision?
const float TAU = 2.0 * PI;
//Returns how much coord is within a circle centered at circle_pos. [0, 1]
float circle(vec2 circle_pos, vec2 coord)
{
float circ_rad = 70.0;
float circ_blur = 1.0;
float dist = distance(circle_pos, coord);
return smoothstep(circ_rad + circ_blur, circ_rad - circ_blur, dist);
}
void mainImage( out vec4 fragColor, in vec2 fragCoord )
{
vec4 black = vec4(0.0, 0.0, 0.0, 1.0);
vec4 white = vec4(1.0, 1.0, 1.0, 1.0);
vec2 center = iResolution.xy * vec2(0.5);
float t = iTime;
float d = 70.0*sin(t/PI); //Distance of each circle from the center. (Can be pos/neg)
const float MAX_CIRCLES = 9.0; //Max number of circles.
float num_circles = MAX_CIRCLES/2.0 + MAX_CIRCLES/2.0*cos(t/PI) + 0.01; //Current number of circles.
float circles = 0.0; //The total number of circles this pixel is in.
for (float f = 0.0; f < MAX_CIRCLES; f++) {
if (f < num_circles) { //Wish I could have non-const number of loop iterations :(
float ap = t + f/num_circles * TAU; //Angular position of each circle, [0, tau]
vec2 newCirclePos = center + d*vec2(cos(ap), sin(ap));
circles += circle(newCirclePos, fragCoord); //If this pixel is in the new circle, circles increases.
}
}
circles = (cos(circles*PI)+1.0)/2.0; //Smoothly interpolate between odd and even values.
fragColor = mix(black, white, circles);
}
Question is : is that the same issue everywhere, or they different ones ? Did anyone can see in code of whose 8 shaders something common maybe ? Just the more info we find, the faster/easy it will be to fix for Hans.
At least shaders 4,6 and 7 (those black and white swapped colors) looks very much the same issue at least visually, but it can be of course different issues, just by some luck it looks like swapped.
Bap: initializing vec3 col = vec3(0.0) seems to make it work. By default there are no layers at all.
Yeah, same on 1.71.
Is it mean that Nova need to deal with unitialized variables again ? Like, "vec3 col;" is unitialized, and optimizer fail to see that it used in the "if" later? But then, if should't work at all then, but it works. Just live vec3 have different value ?
Is it mean that Nova need to deal with unitialized variables again ? Like, "vec3 col;" is unitialized, and optimizer fail to see that it used in the "if" later? But then, if should't work at all then, but it works. Just live vec3 have different value ?
Not in the case of that shader. Try setting col = vec3(1.0) on Windows, and see what happens.
The shader is taking advantage of GLSL implementations zeroing uninitialized variables. section 5.9 of the GLSL spec (using version 4.50) says: Reading a variable before writing (or initializing) it is legal, however the value is undefined.
At present, I have no intention of setting uninitialized variables to 0. I'll consider it if too many programs need it.
Not in the case of that shader. Try setting col = vec3(1.0) on Windows, and see what happens.
With vec3(1.0) it the same on os4 and on win32 then : the same effect, with "white" color in. With vec3(0.0), all fine on both win32 and aos4, and with how it originally, we have that difference on os4.
I not sure what is it mean : that unitialized variables on win32 are always set to 0.0 but on os4 random values ?
float theta = 4.+.008*t; // some rotations, not necessary
mat2 m = fRatio*mat2( cos(theta),sin(theta),
-sin(theta),cos(theta) );
// computation of the multiplicative noise
float q = 1.;
for (float i = 0.; i < NbScales; i++) {
if (d<1e-2) continue;
// multiply the amplitude to maintain the total density
float c = (i+1.< NbScales) ? 2. : 1.;
float nn = noise(uv + 10.7*i*i);
for (float j = 0.; j < GazConcentration; j++) {
nn = sin(nn*3.14159265359/2.);
}
#if Mode == 0
float n = c* 0.5*(1.+nn);
#else
float n = nn;
#endif
// compute only the visible scales
float crit = n_tiles_level_1 *q - iResolution.x/LimitDetails;
if (crit < SmoothZone && i >= FirstScale) {
if (crit>0.) { // avoid aliasing
float t = crit/SmoothZone;
n = n*(1.-t);
#if Mode == 0
n += t;
#endif
}
#if Mode == 0
d *= n;
#else
d += n*(0.5);
#endif
}
uv = m*uv; q*= fRatio; // go to the next octave
}
d = clamp(d,0.0,d);
fragColor.xyz = (keyToggle(67)) ? vec3(exp(-d)) :colormap(exp(-d));
}
WIN version:
AOS4 version:
I start to think, that it's all different bugs all the time. I.e. bug the same : wrong content in registers, and their wrong compare/use , and it didn't looks like some single particular issue. Just visually it looks pretty much the same like colors swapped, but it all can be different..
How interesting .. On the the page of that shader i didn't see that iChannel2 is used at all, but, if i start to set there different textures, then i also may have or white, or red colors , depends on texture.
Can it be that implementation of iChannel on our side, somehow different when it come to "iChannel used in the code, but not actually set". Maybe it again some sort of unitialized default values ?
It would be nice to get a warning from compiler about potentially uninitialized variables in cases like this.
This behaviour is not just allowed but also not considered to be worth a warning. Nova is not buggy here, so I have to second Hans that there is no action to be taken. Yes, it would be nice but on the other hand it also will result in unnecessary warnings. And such a analysis is not trivial and not for free. After all there are very valid reasons - unlike in those broken shaders - not to initialize a variable right upon declaration.
@kas1e Quote:
I not sure what is it mean : that unitialized variables on win32 are always set to 0.0 but on os4 random values ?
No, it's just that some (maybe even most, or even all, doesn't matter) Windows OpenGL drivers apparently set uninitialized variables to 0 even though the standard explicitly does not require it. Or to put it simple: the respective shaders are buggy, not Nova. Those shaders rely on something they simply must not rely on. However, since real-life shaders often seem to falsely rely on this behaviour, maybe a Nova feature request for an init-vars-to-zero-toggle (default off like now) is a good compromise.
Quote:
Question is : is that the same issue everywhere, or they different ones ?
Novas register handling is still broken and therefore all sorts of fun can happen. You or I cannot say for sure which exact issue it is. We cannot even say for sure if it has to do with the register allocator, it's likely but we cannot be sure. Maybe it's a different bug with familiar looking symptoms. The thing is: with those Shaderjoy shaders it is natural that whatever is the problem results in pixels being falsely colored, simply because Shadertoy is all about pixel colors and nothing else ;) Anyway, either create one bug-report named "All sorts of pixel garbage" and then extend it with more and more links to shadertoy-shaders - or create one report for each buggy shader, maybe with a not that you somewhat guess that it may be related to bug or report xyz. But don't try to be smart and to categorize further After all you are a reporter. It's Hans job to fix that stuff and it's also his job to analyse and eventually merge or split your bug reports.
Quote:
I start to think, that it's all different bugs all the time. I.e. bug the same : wrong content in registers, and their wrong compare/use , and it didn't looks like some single particular issue. Just visually it looks pretty much the same like colors swapped, but it all can be different.
IMHO a rewrite of the register allocator is due. From what I see things get fixed in lib release A only to reappear in a slightly different form or the fixes cause other problems as sideeffects. And then there is also the missing register spilling etc. For the upcoming ogles2 lib version I threw away and rewrote the whole program introspection system Yes, certainly no fun but sometimes you have to admit to yourself that what you did before was no good and that a rewrite with a fresh head is the far better choice, instead of putting even more patchs on that old rag rug. In my experience this always pays off.
However, since real-life shaders often seem to falsely rely on this behaviour, maybe a Nova feature request for an init-vars-to-zero-toggle (default off like now) is a good compromise.
Imho also not worth , because it mean take manual actions. But then in just case, shader can be changed and that all. From another side, question is : can be unitialized variable set to 0 cause any issues in compare with being random as it now ? I mean, of course, shaders can be buggy and rely on undifened behaviours, but will setting unitialized value to 0 , cause any problems for any other possible shaders ? Imho no ? Then if no, why not have it the same just to cope with some buggy shaders ?:)
Quote:
But don't try to be smart and to categorize further After all you are a reporter. It's Hans job to fix that stuff and it's also his job to analyse and eventually merge or split your bug reports.
Indeed, just tring to help Hans to make less work :) But in end you (and Hans as well answer the same) seems right, it better to made reports for each shader differently. Just there currently :
11 shaders with wrong/swapped colors 15 shaders giving black/white/grey screen 30 shaders with wrong rendering (some with very little issues, some with major ones).
So in summ it mean about 50 bug-reports will be :)
Quote:
IMHO a rewrite of the register allocator is due. From what I see things get fixed in lib release A only to reappear in a slightly different form or the fixes cause other problems as sideeffects. And then there is also the missing register spilling etc.
There were some regression since 1.68 yes, and all probabaly indeed related to registers stuff which need rewriting with having in mind spiling as well.
Quote:
For the upcoming ogles2 lib version I threw away and rewrote the whole program introspection system
Is it that beta of 3.0 version which i had ? Because in that one remaining bugs of 2.11 were fixied, so if it just "proper rewrite" made it better in end, then yeah, that way to go.