black blocks appearing out of nowhere

Hi all,

I’ve been toying around with a project in which I have a very texture memory consuming pipeline.
In a specific post-processing effect (which combines 6 textures) I get big almost-random large white blocks. When I try to render the output the blocks become black.
And the blocks have a specific preference for my terrain (all of them are centered on terrain interior or edges).
What could be going on?
I used smaller textures for everything but the problem remains.

Many thanks,

Even the rest of the image is… strange. :slight_smile: is all this stuff just sprites?
What happen if you disable texture mapping and set just colors?

Come oon it’s not that strange! it’s just an overglowing HDR failure :smiley:

Disable texture mapping?? I don’t think that’s a viable manual debugging solution :slight_smile:
Hmm I think that you think that the black blocks are rocks, but aren’t.

One new weird thing :
If I reduce the terrain size to just 2 triangles, the problem vanishes.

I’ve been using the same code for the simple terrain, and really, it is fine. It has been working flawlessly for some months.

Update :
I am monitoring the light pass in the app with glIntercept.
-> The normals are great
-> The light direction is great
-> If I output NdotL then some jittered-noise pitch-black points appear, sometimes in line patterns (& the rest correct)
If I clamp the same NdotL to (0,1) it’s white
(probably that’s the same with the blocks -> NaN or sth?)

The jittered points … ‘become’ large blocks if I apply a specific post-process (mix of 6 blurred outputs of the problematic line output).

Ok for the proof of concept :

pic1: no post-proc other than a fullscreen directional light pass
Some black points appear sometimes in line patterns (I’ve circles the areas of interest)

pic2 : the same with the blur-and-combine post proc

Ok the blocks are actually the natural extension of the problem if I blur and combine Nan/Inf points (Nan is viral in blurring)

But still… where could the points come from??

Ok I found it.
It was an arithmetic inaccuracy issue.

my screen space normal was computed in the light pass as :

vec3 n = vec3(gbuf_normal.x,gbuf_normal.y,
              sqrt(1.0 - gbuf_normal.x*gbuf_normal.x - gbuf_normal.y*gbuf_normal.y));

and apparently sqrt got a negative argument sometimes.

…so I clamped it to (0,1) & now works :slight_smile:

The funny thing is that I normalize the screen space normals
before I store them. That’s probably the great 16F accuracy! :slight_smile:

a quick python check indeed qives a negative value for extreme (but valid) value of the normal :

1.0 - math.cos(math.pi/4.0) * math.cos(math.pi/4.0) - math.cos(math.pi/4.0) * math.cos(math.pi/4.0)

So even with 32F it can happen.

Actually Python operates with 64F, so this also happens with doubles.

…Don’t you just hate floating point errors? :mad:

No I don’t :slight_smile:
I am pragmatic, and I know that infinite precision has a performance cost.