View Full Version : black blocks appearing out of nowhere

11-16-2008, 01:56 PM
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.

http://img136.imageshack.us/img136/2294/blockyfr2.th.png (http://img136.imageshack.us/my.php?image=blockyfr2.png)http://img136.imageshack.us/images/thpix.gif (http://g.imageshack.us/thpix.php)

Many thanks,

11-16-2008, 02:41 PM
Even the rest of the image is... strange. :) is all this stuff just sprites?
What happen if you disable texture mapping and set just colors?

11-16-2008, 03:12 PM
Come oon it's not that strange! it's just an overglowing HDR failure :D

Disable texture mapping?? I don't think that's a viable manual debugging solution :)
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).

11-16-2008, 03:26 PM
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)

http://img374.imageshack.us/img374/5364/lineprobdr5.th.png (http://img374.imageshack.us/my.php?image=lineprobdr5.png)http://img374.imageshack.us/images/thpix.gif (http://g.imageshack.us/thpix.php)

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

http://img208.imageshack.us/img208/9416/blockprobnp0.th.png (http://img208.imageshack.us/my.php?image=blockprobnp0.png)http://img208.imageshack.us/images/thpix.gif (http://g.imageshack.us/thpix.php)

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??

11-16-2008, 06:04 PM
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 :)

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

11-17-2008, 01:58 AM
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.

11-17-2008, 03:19 AM
Actually Python operates with 64F, so this also happens with doubles.

11-17-2008, 06:25 AM
..Don't you just *hate* floating point errors? :mad:

11-17-2008, 06:52 AM
No I don't :)
I am pragmatic, and I know that infinite precision has a performance cost.