Render bug, large black box occluding screen

[nbohr1more]

Pretty strange.

I think non-lit textures are handled by the "old stage" part of the renderer. I believe @duzenko emulated that via a dedicated glprog... oldstage.fs \ vs

If I look at the code, there is an unprotected divide xy by w operation:

 

void main() {
    vec4 tex;
    if (u_screenTex == 1.0) {
        tex = var_TexCoord0;
        tex.xy /= tex.w;
        tex = tex * 0.5 + 0.5;
        tex = texture(u_tex0, tex.xy);
    } else
        tex = textureProj(u_tex0, var_TexCoord0);
    FragColor = tex*var_Color;

We can try:

void main() {
    vec4 tex;
    if (u_screenTex == 1.0) {
        tex = var_TexCoord0;
        tex.xy /= max(tex.w, 0.0000001);
        tex = tex * 0.5 + 0.5;
        tex = texture(u_tex0, tex.xy);
    } else
        tex = textureProj(u_tex0, var_TexCoord0);
    FragColor = tex*var_Color;

@stgatilov @cabalistic ?

[nbohr1more]

@AluminumHaste try these clamped glprogs:

oldStage.fs

bloom_upsample.frag.glsl

bloom_downsample.frag.glsl

Note: Make sure to place them in glprogs after you compile since compiling will overwrite the contents of glprogs with the default versions

[AluminumHaste]

Better, don't get the full squares around windows, but the windows in black mage flicker blue still

[nbohr1more]

So the texture itself is flickering blue and this does not happen if it is "diffuse"?

What happens if you change the material to blend add:
 

{

blend add

map textures/darkmod/window/diamond_pattern02_moonlit

}

 

[AluminumHaste]

Already tried changing it to blend add, but now that you gave me the other stuff hang on.

[AluminumHaste]

Didn't help.

[nbohr1more]

Try one more clamped glprog:

gaussian_blur.frag.glsl

[AluminumHaste]

Hang on, just realized I'm using an slightly older exe. Re-compiling

 

[AluminumHaste]

Ok, went through all the those again with correct exe, still doing it.

[AluminumHaste]

Interesting, the flickering is per frame, it's not constant like it was before.

 

[nbohr1more]

AFAIK The only other shader that can be involved is the fullscreen_tri.vert.glsl shader but clamping the first term in the coordinates results in the render occupying a quarter of the screen.

[nbohr1more]

Hmm... does the flicker pattern change if you set tdm_lg_interleave to something higher like 6 ?

[AluminumHaste]

It doesn't seem to matter no. However, I can't get it to always stay in that flickering state. Most of the time it flickers as I move the mouse around.

It doesn't seem to be based entirely on view but also camera movement direction.

My work shift is done so I have to log off for now. If you have any other suggestions I'll try them tonight or tomorrow.

[nbohr1more]

Nothing much more from me now.

Perhaps set tdm_lg_interleave_min to 1 so you can lower the FPS again and check the flicker pattern below the default 40FPS value?

[nbohr1more]

I guess I should unpack a little of the previous trouble-shooting:

1) If you remove my clamped glprogs, does the latest SVN still render those boxes ?

2) If so, can you cure the boxes with just the bloom upscale and bloom downscale glprogs ?

( I really don’t like guarding against divide by zero with an arbitrary high precision float, so I hope that only the max 0 fixes are beneficial. )

 

[stgatilov]

6 hours ago, AluminumHaste said:

Interesting, the flickering is per frame, it's not constant like it was before

That's because the issue in bloom implementation was fixed by added clears.
My hypothesis was true: that's the special floats (Inf or Nan) with unprotected blending that caused it to stick.

Now that we got rid of the sticking, the core problem of getting special values still persists. And it can be generated by absolutely anything in our shader park.

[AluminumHaste]

14 minutes ago, nbohr1more said:

I guess I should unpack a little of the previous trouble-shooting:

1) If you remove my clamped glprogs, does the latest SVN still render those boxes ?

2) If so, can you cure the boxes with just the bloom upscale and bloom downscale glprogs ?

( I really don’t like guarding against divide by zero with an arbitrary high precision float, so I hope that only the max 0 fixes are beneficial. )

 

1) Yes it does.

2) The blue boxes around the windows goes away, but then the windows flicker blue every frame.

[nbohr1more]

20 minutes ago, AluminumHaste said:

1) Yes it does.

2) The blue boxes around the windows goes away, but then the windows flicker blue every frame.

Thanks. I'll commit those two to SVN tdm_src and hopefully we will track down whatever is causing the blue data elsewhere.

[AluminumHaste]

Not to be a negative Nancy, but......AMD Radeon Drivers.

[stgatilov]

5 minutes ago, nbohr1more said:

Thanks. I'll commit those two to SVN tdm_src and hopefully we will track down whatever is causing the blue data elsewhere.

Ehm... and what is the fix exactly?

[stgatilov]

7 hours ago, nbohr1more said:

I think non-lit textures are handled by the "old stage" part of the renderer. I believe @duzenko emulated that via a dedicated glprog... oldstage.fs \ vs

Without something like "blend add", this becomes ambient stage, which is probably processed by ambient interaction shader.

[AluminumHaste]

Added blend add to the material def, but still getting the flickering blue color in the window texture.

[nbohr1more]

2 minutes ago, stgatilov said:

Ehm... and what is the fix exactly?

Both the bloom_downsample.frag.glsl and bloom_upsample.frag.glsl accumulate a "sum" variable.

Some of the operations done on the sum variable are subtractions.

My fix is to ensure that the minimum value for sum is 0

void main() {
    // query previous mipmap level by a full-pixel offset (corresponds to half-pixel in our output framebuffer)
    vec2 offset = vec2(1, 1) / textureSize(u_sourceTexture, 0);
    vec4 sum = sampleTexture(vec2(0, 0)) * 4;
    sum += sampleTexture(-offset);
    sum += sampleTexture(offset);
    sum += sampleTexture(vec2(offset.x, -offset.y));
    sum += sampleTexture(vec2(-offset.x, offset.y));
    FragColor = max(sum, 0) / 8;

 

[AluminumHaste]

Well.....I noticed that there's no specular map stage in the mat definition so added one.

specularmap textures/darkmod/window/diamond_pattern02_moonlit

problem gone....

 

Quote

textures/darkmod/window/diamond_pattern02/diamond_pattern02_moonlit
{
    glass
    noselfshadow
    noshadows
    qer_editorimage    textures/darkmod/window/diamond_pattern02_moonlit_ed
    {
        //blend add
        map    textures/darkmod/window/diamond_pattern02_moonlit
        rgb 1
    }
    specularmap textures/darkmod/window/diamond_pattern02_moonlit
    bumpmap textures/darkmod/window/diamond_pattern02_local
    {
        if ( parm11 > 0 )
        blend    gl_dst_color, gl_one
        map        _white
        rgb        0.40 * parm11
    }
    {
        if ( parm11 > 0 )
        blend    add
        map        textures/darkmod/window/diamond_pattern02_moonlit
        rgb        0.15 * parm11
    }

 

}

 

[AluminumHaste]

Did the same for

textures/darkmod/window/diamond_pattern02/diamond_pattern02_moonlit_soft
{
    glass
    noselfshadow
    noshadows
    qer_editorimage    textures/darkmod/window/diamond_pattern02_moonlit_soft_ed
    {
        
        map    textures/darkmod/window/diamond_pattern02_moonlit
        rgb 0.6
    }
    specularmap textures/darkmod/window/diamond_pattern02_moonlit
    bumpmap textures/darkmod/window/diamond_pattern02_local
    {
        if ( parm11 > 0 )
        blend    gl_dst_color, gl_one
        map        _white
        rgb        0.40 * parm11
    }
    {
        if ( parm11 > 0 )
        blend    add
        map        textures/darkmod/window/diamond_pattern02_moonlit
        rgb        0.15 * parm11
    }

 

}

 

And in Flakebridge the issue is gone also.