Comments on: Screenspace vs. mip-mapping

By: Real-Time Rendering · 7 Things for February 10

Real-Time Rendering · 7 Things for February 10 — Wed, 10 Feb 2010 13:24:21 +0000

[...] Pranckevičius has a worthwhile post on deferred rendering and mipmap bugs, along with some good follow-up [...]

By: pixelmager

pixelmager — Tue, 12 Jan 2010 11:03:44 +0000

Slide 32 of the following presentation mentions the same problem, using tex2dlod to manually set the mip-level using the screen-space size of the projected light.

http://cmpmedia.vo.llnwd.net/o1/vault/gdceurope09/slides/TKlajnscek_Programming_BattletestedDeferredRendering.ppt

By: Aras Pranckevičius

Aras Pranckevičius — Tue, 12 Jan 2010 09:09:13 +0000

Then in the distance your light will illuminate all pixels it touches. Which can be ok if you render light as tight bounding shape in screen space, but not that ok if you render it as 2D bounding quad.

By: Sergei M

Sergei M — Tue, 12 Jan 2010 08:48:11 +0000

What if you just blur the low mip maps, so the lowest ones would be complete solid color white?

By: Aras Pranckevičius

Aras Pranckevičius — Fri, 08 Jan 2010 07:03:14 +0000

@sean: right, I got the near/far texture coordinate stuff backwards. Updated the post, thanks for the correction!

By: Daniel

Daniel — Fri, 08 Jan 2010 04:14:27 +0000

Thanks a lot for sharing this, I’m sure it will save me some time in the future =)

If the incorrect mip selection only happens when there’s a large depth difference, it might be possible to render the light in depth layers, controlled by depth bounds test. That would require rendering the light geometry multiple times but pixel shader work will be unaffected.

By: sean barrett

sean barrett — Thu, 07 Jan 2010 23:15:20 +0000

The problem actually occurs not when the texture coordinates are near each other, but when the texture coordinates are far from each other, right? (A simple way to imagine it is to draw a bounding box around adjacent samples and then consider which mipmap texel best approximates that box. If the samples are near each other, it will try to magnify, not minify.) Naturally it’s *very common* for the texture coordinates on unrelated objects to be very far from each other.

I actually first saw a related scenario happen with mipmapped light maps on terrain in 2001 or so… you have a triangle that ought to be in shadow, but it’s at an extreme edge-on angle that forces the mipmap sample to sample from very far outside the triangle, and it suddenly pops bright.

But discontinuous pixel shading is definitely a much more common way to get this effect; it happens with the naive implementation of trilinear virtual texturing pretty much everywhere on page boundaries.

By: William Nilsson

William Nilsson — Thu, 07 Jan 2010 19:49:33 +0000

Haha, cool!
I had the exact same issue 6 months ago! What I found worked resonably well is to cut off a few of the lowest mip levels. The penalty wasn’t that bad and it (mostly) fixed the issue. It depends what your texture looks like though, in your example you should get away with removing 1 or 2 levels to get the same result as you have in the top picture.

Say hi to Mircea :)

By: pixelmager

pixelmager — Thu, 07 Jan 2010 15:34:13 +0000

Getting dx/dy for uv/w, clamping them and feeding them into the tex2D/tex2Dgrad will limit the issue, but is, as you say, not necessarily supported on older hardware. Forcing lod0 always is though :p