Re: [Algorithms] Second layer shadow mapping to avoid acne?
Tom Forsyth <tom.forsyth <at> eelpi.gotdns.org>
2007-11-02 16:24:05 GMT
The polygonalisation of the object can still cause light to bleed around to
the back (interpolated gouraud shading, or slightly wonky interpolation on
the normal), and shadows to bleed around to the front. And then you can
still see the sharp terminator.
The best solution I've found is to bend the normals towards the light a bit.
That way the clamp(N.L) terminator moves around and puts slightly more of
the hard shadow terminator in the shade.
This obviously doesn't work with hemispherical/wraparound lighting models.
One way is to separate the hemispherical model into frontface and backface
components and only shadow the frontface stuff, but then it's twice as
expensive.
To the general question, I use frontface shadowbuffers and an offset for
self-shadowing, and then I use an ID buffer (not a depth buffer) for
shadowing between objects. Once you find a suitable intra-object offset
(MUCH easier than finding an inter-object offset), I found the artifacts
from backface rendering to be more objectionable than those from frontface
rendering.
TomF.
From: gdalgorithms-list-bounces <at> lists.sourceforge.net
[mailto:gdalgorithms-list-bounces <at> lists.sourceforge.net] On Behalf Of
Richard Schubert
Sent: Friday, November 02, 2007 8:16 AM
To: Game Development Algorithms
Subject: Re: [Algorithms] Second layer shadow mapping to avoid acne?
Usually shadowmaps are applied to a specific light term. On the back side of
an object there is no light, hence there is no shadow.
----- Original Message -----
From: Willem H. de Boer
To: erich <at> acm.org ; Game Development Algorithms
Sent: Friday, November 02, 2007 3:57 PM
Subject: Re: [Algorithms] Second layer shadow mapping to avoid acne?
Wang & Molnar works under the premise that it's generally quite dark on back
faces,
but this situation breaks down in a multiple-light situation. Imagine an
object being lit
by a light on one side, and another light on the other side.
I too would be very interested in hearing about what other people have used
in their games
engines to battle surface acne. I'm currently working on the same problem
and would love
some input :)
Willem
----- Original Message -----
From: Eric Haines
To: Game Development Algorithms
Sent: Friday, November 02, 2007 2:23 PM
Subject: [Algorithms] Second layer shadow mapping to avoid acne?
So a classic problem with shadow mapping is self-shadowing, "surface acne",
where the receiver shadows itself. There are various fixed and plane
gradient biases that can be set to avoid the problem, though nothing's
foolproof.
One old trick (Wang & Molnar 1994, though I'd seen it before then) is to
simply do frontface culling when making the shadow map. Now the receiver is
(usually) nowhere near the depth of the occluder and self-shadowing is
avoided.
My question: is this what game developers using shadow maps usually do? I
was talking with someone at NVIDIA and he maintains most do so. Also, are
there any fatal flaws I'm missing? (see list below)
I was a little surprised that backface culling would be the norm, as this
method has its own problems:
1) double-sided objects: the backface == the frontface, so the surface acne
problem is back. This happens for things like palm fronds or other cutout
textures. I'd solve it by simply offsetting the fronds a fair bit when
written into the shadow map (more than solid objects).
2) thin objects: similar problem.
3) near silhouette edges: again with the acne. All these could be helped by
traditional biasing techniques, but then that makes the next problem worse:
4) light leaks at point of contact: a cube is on a plane, you're looking at
an edge on the plane in shadow. Light leaks through the cube (since the
backfaces are very close to the plane) and there's a streak of random light
blobs on the plane where the cube is. My NVIDIA contact says "move the cube
off the plane, no one will notice". Fair enough - a little Peter Panning,
but otherwise OK.
5) if objects interpenetrate you'll get the same light leaking at the points
of contact. Solution: don't let objects interpenetrate for any appreciable
amount of time.
Really, none of these problem are insurmountable, and so "draw the
backfaces" does seem like a pretty good solution overall as it avoids
self-shadowing headaches 95% of the time by default.
Comments? I'm writing about this in "Real-Time Rendering" and would like to
get "best practices" across.
Eric
________________________________________
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
________________________________________
_______________________________________________
GDAlgorithms-list mailing list
GDAlgorithms-list <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
________________________________________
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
________________________________________
_______________________________________________
GDAlgorithms-list mailing list
GDAlgorithms-list <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
GDAlgorithms-list mailing list
GDAlgorithms-list <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
Actually, I did something that was neither of those options. I bucketed
all my triangles by some regular point feature (centroid is fine). This
gives me unambiguous splitting planes because I can split on exactly the
median every time. During traversal, I run through all triangles in the
leaf to check distance to the actual triangle, not the associated
point. The traversal is slightly altered as well, I (to oversimplify a
bit) find the closest triangle in the current cell, but if the splitting
plane is closer than that point, I search the other side of the plane as
well and early out if nothing over there is closer than what I've found
already. The devil is in the details, because it requires projection of
the query point into the opposing cell, yet the distance check must be
from the original query point...
As a caveat, I also know that the mesh is preconditioned to have
triangles that are generally the same size. Were this not true, a large
triangle on the other side of the splitting plane might be missed as the
collision point. For my purposes, this is an acceptable risk, since the
results aren't used for rendering or collision, and any error will be a
RSS Feed