Jump to content

  • Log In with Google      Sign In   
  • Create Account

FREE SOFTWARE GIVEAWAY

We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter.


Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running!


Shadow Volume Generation Precision


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
4 replies to this topic

#1 Geometrian   Crossbones+   -  Reputation: 1601

Like
0Likes
Like

Posted 28 April 2014 - 12:50 AM

Hi,

So I have reimplemented my old shadow volumes algorithm--mainly for completeness. This implementation uses a geometry shader to generate depth-fail (read: two-ends capped) geometry.

All works well, except that for some glancing angles, the geometry is extruded out from where it shouldn't. This results in artifacts. This seems to happen particularly where a triangle's edge that should be shadowed actually thinks it's a silhouette edge.

Here's a simple example. All seems well:
correct_zpsd924d49f.png
But rotate it, and an artifact develops:
incorrect_zps5369bf7c.png
Here's a closeup of such an artifact:
close_zpsc51a382d.png
The dark face at the bottom should be completely shadowed, and therefore should not generate an edge along the bottom-left. It generates one anyway, screwing up the render.

The normal used to compare to the light direction is generated from the cross product of the geometry itself, so it's not an interpolation issue. Also, the artifacts seem to only happen in a narrow range of glancing angles. The same face will correct itself if turned further.

My question is, is this a common thing? The only thing I could think of is a precision issue, but the error is really quite large. I realize I haven't given much information about the implementation, but does anyone seen this sort of thing with volume extrusion before?

-G

Edited by Geometrian, 28 April 2014 - 12:55 AM.

And a Unix user said rm -rf *.* and all was null and void...|There's no place like 127.0.0.1|The Application "Programmer" has unexpectedly quit. An error of type A.M. has occurred.

Sponsor:

#2 radioteeth   Prime Members   -  Reputation: 1146

Like
2Likes
Like

Posted 28 April 2014 - 08:00 AM

How are you performing your silhouette detection? It looks as though you are just translating the back-faces of the geometry away from the light source, which seems simple enough but might be causing the complication which manifests as a graphical artifact.



#3 Geometrian   Crossbones+   -  Reputation: 1601

Like
0Likes
Like

Posted 01 May 2014 - 05:35 PM

In the geometry shader (input GL_TRIANGLES_ADJACENCY):

--A vector L from the triangle's first vertex to the light is computed.
--The normal N is computed by a cross product of the vertices.
--L is then dotted with N
--The sign of the dot product is checked. This determines the side facing the light.

This formula is computed for each of the four triangles. If any of the three adjoining edges jumps from a facing to a non-facing value, then the edge is extruded. To avoid double extrusion, the extrusion only happens if the center triangle is facing the light.


And a Unix user said rm -rf *.* and all was null and void...|There's no place like 127.0.0.1|The Application "Programmer" has unexpectedly quit. An error of type A.M. has occurred.

#4 Geometrian   Crossbones+   -  Reputation: 1601

Like
0Likes
Like

Posted 01 May 2014 - 06:20 PM

Update: I have modified the geometry shader to show the output more carefully. It seems that the computation of whether an adjacent triangle faces the light is incorrect in some cases.


And a Unix user said rm -rf *.* and all was null and void...|There's no place like 127.0.0.1|The Application "Programmer" has unexpectedly quit. An error of type A.M. has occurred.

#5 Geometrian   Crossbones+   -  Reputation: 1601

Like
4Likes
Like

Posted 01 May 2014 - 06:31 PM

Update: I found the problem. I was using a light direction from a vertex on the center triangle to compute facing values for all four triangles, but this only works for three. Ensuring that the light direction is computed from a vertex within each triangle fixes the problem.


And a Unix user said rm -rf *.* and all was null and void...|There's no place like 127.0.0.1|The Application "Programmer" has unexpectedly quit. An error of type A.M. has occurred.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS