Noise in deferred renderer

Started by
19 comments, last by Bow_vernon 13 years, 4 months ago
Hi sorry if I keep asking questions (Im learning).. Lately I've finished my deferred renderer demo. I asked my friends to run the demo on their PC. I saw it ran pretty well. Until a friend of mine told me that there's a "little" noise that really annoying, like this:

Artifact

And this is what it normally looks like:
Normal

Anyone can shed a light on this??I dont know what caused this. I thought that maybe some of you ever experienced a situation like this. I thx you for any help.

Best Regards,
Bow Vernon
Advertisement
That can be more things imho, I'd try if it is not precision (using 16-bit depth buffer and reconstruct positions is not a good way to do it ... or rgba8 for normals ... they also need sign, so rgb10a2 should be minimum for normals).

Also it can be come wrong clamping/normalizing when computing light, or issue in self shadowing parallax occlusion mapping.

My current blog on programming, linux and stuff - http://gameprogrammerdiary.blogspot.com

Wow, I use 24bit depth buffer for position reconstruction, and I use viewspace normal, so the z buffer is not stored (calculated manually). any suggestion?? Should I use R16G16 format?? I'll try to use that and see if it gets better but while Im at it please share your knowledge about this problem....thx
This sort of thing is usually a division by zero or square root of a (just barely) negative number in the pixel shader. E.g. if you are calculating your normal view space z via sqrt(1 - x^2 - y^2) and that sum of squares is just barely greater than one, badness ensues.
#0xffffffff (btw. nice nickname ;)) - True, if it's that you can solve it the way 0xffffffff (= 4294967295 if you want him in dec instead of hex :D ... sorry for that, I had to do this joke :P) wrote, or maybe it might be better to store all 3 directions (x, y, z) of normals in rgb10a2 buffer. There are few reasons:
1) if you're using rg16f buffer - you have same storage as rgb10a2, but you use expensive sqrt operation on every pixel that wents through the normal reconstruction shader
2) if you're using otherwise - you probably have little less storage needed, but unless you're fillrate limited I think you should avoid that sqrt ... but it is up to you - someone would like to avoid it, someone not (probably based upon what are you going to add to rendering in the first case and if you're storage limited or computational power limited in the second case ... I'm mostly second case, so I would rather go without sqrt).

My current blog on programming, linux and stuff - http://gameprogrammerdiary.blogspot.com

I read somewhere that sometimes with deffered rendering similar artifacts are created by wrong mipmapping
oh well thx for the info. anyway, I use simple linear filtering, although the texel match the pixel (1:1 ratio). that is, I dont use power of two texture. but I guess that's no prob. I'll try ur suggestion. anyway, does fallout3 use deferred shading?
I don't exactly know what kind of renderer do Fallout 3 use - but I think it use deferred rendering (lack of transparent surfaces) mixed with forward rendering pass (grass and vegetation leaves ... not sure about trunks), although I'm not sure.

My current blog on programming, linux and stuff - http://gameprogrammerdiary.blogspot.com

well cause fallout3 ran just fine without artifact on my friend's laptop. and it has come to my surprise that the artifact only showed up at my friend's laptop. How come? I cant take any meaningful explanation about these...please help...
Can you post your friends specs?

I also can look on your shaders (and I might see the mistake in them and try to fix/explain what is not working), I also might test it (On two laptops I have at home and on some (four currently) desktops also) - if you upload app or shaders source somewhere.

My current blog on programming, linux and stuff - http://gameprogrammerdiary.blogspot.com

This topic is closed to new replies.

Advertisement