Re: [Supertuxkart-devel] Future of lightmaps

[Lauri K. <ca...@gm...>]

On Wed, 17 Jul 2013 22:22:11 +0200
Lionel Fuentes <fu...@gm...> wrote:

> > It's very annoying to me, but maybe I'm the minority on that. There's
> > two kinds of SSAO flicker: the randomness one, and the temporal one.
> >
> > The randomness flicker is visible even when you're standing still, and
> > it's not there in some implementations.
> >
> > The temporal flicker is visible every time you move. It's there in all
> > SSAO implementations to date. Back-projection and smoothing over the
> > previous frame do not completely remove it. This is the one I mean
> > mainly.
> >
> 
> I don't see what this temporal flickering you're mentionning is. I see the
> thing like this: in the fragment shader, choose a random number depending
> on the fragment's position in screen-space. Have a set of fixed sampling
> texture coordinates on a disk, such that for each point P of that set, the
> nearest other point P' of that same set is at distance d=dist(P, P') (in 2D
> screen-space). For each point P and nearest point P' of the set, dist(P,P')
> = d = constant.
> Then use the random number to rotate the disk around its center, and use
> the distance to the camera (from the depth buffer) to scale the disk.
> Sample using those positions, and compute ambient occlusion using that.
> In this implementation, I only see one source of flickering, which is the
> random number used for rotating the sampling disk. That's what I refer to
> as "randomness flickering". As this random number is the same for any given
> pixel, independently of the time, I don't see any "temporal flickering".
> How would you implement SSAO, and what do you consider the source of
> "temporal flickering"?

In some implementations, the randomness comes from another source than
the pixel position, in which case it will change over time even as you
don't move. Obviously if the randomness comes from a source that only
changes when you move, that flicker is not there when standing still. I
should've been more clear.

As to the exact source of the temporal flicker, I don't know. My best
guess is the inability to do a perfect ray trace: first, the number of
samples may not cover all the pixels needed, and even if it does,
whether that pixel is representative is not guaranteed.

Every time there's sub-pixel detail, or more than one mesh in one
pixel, the pixel is not fully representative of the scene on that
point, and it may randomly change as you move.

> How would you implement SSAO?

TBD this biweek ;)

For the low version, there would be no randomness at all, a lower
number of steps than 16, a simple blur, and stencil optimization. No
poisson sampling, disc rotation, edge-blur, etc. all of which slow it
down.

Whether there's enough time to add niceties to the high version I don't
know; if not, it's simply a higher resolution variant.

Smoothing over the previous frame's SSAO may be added, depends on if
it's needed. Back-projection won't be, as in my experience it's not
useful enough.

> > Texture resolution is my point. Full-resolution SSAO is impossible for
> > most cards in use by the STK user base, usable only by mid-to-high end
> > due to the performance hit. The default I was planning was quarter
> > resolution SSAO, which would be usable by a majority of the user base,
> > but it can't represent small creases due to the resolution.
> >
> > (There would be a tri-state option toggle: SSAO off, low, high; low =
> > quarter, high = full res)
> >
> What about half-res? I'm curious about what the feeling is, comparing these
> resolutions. I think I would only keep quarter res for all variants, but I
> don't know how much the difference is noticeable.
> When that's done, maybe you could post comparative screenshots for the same
> scene on your next blog post? That would be great :)

Sure, will do comparison shots.

- Lauri