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,
Babis
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?
Come oon it’s not that strange! it’s just an overglowing HDR failure 
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).
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
The funny thing is that I normalize the screen space normals
before I store them. That’s probably the great 16F accuracy!
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)
-2.2204460492503131e-16
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
I am pragmatic, and I know that infinite precision has a performance cost.