3
\$\begingroup\$

I'm trying to create shadows in a 2D game in such a way that I can have an arbitrary number of lights in a scene, all of which can cast shadows. To do this I think I have to generate a mesh for each light that models where the light can come (e.g. where there is no shadow).

In this tutorial: http://youtu.be/4BtjcH-iLR0?t=4m40s (at 4 minutes 40 seconds) Chris Molini does exactly what I want describing it as 'a polygon clipping pass' for each edge that intersects with the light. However I don't understand what kind of polygon clipping he is refering to here. I have tried to mimick his technique on my own but without success. (I get lost in corner cases and radial+distance ordering around the light).

Screenshot from the vide

Here's a screenshot from the video. The square is the light's mesh (basically an AABB containing the light's sphere of influence). Which is gradually adjusted for each edge that intersects with the light's mesh.

\$\endgroup\$
4
\$\begingroup\$

I've implemented a similar method in the past, and it can be quite tricky to get it right. The best resource I've seen is on Amit Patel's fantastic site:

http://www.redblobgames.com/articles/visibility/

There are quite detailed explanations of each step, lots of good demos, and some code samples.

To briefly answer your question directly, the "polygon clipping" seems to refer to casting rays from the light source through each end of the shadow-casting edge. If the rays hit the border of the light's mesh AFTER passing the edge, then the section of the border between the hit points must be edited. Remove any vertices of the border that are between the endpoints. Add the first hit point, then the endpoint of the shadow-casting edge that corresponds to that point, then the other endpoint of the shadow-casting edge, then the second hit point.

Hope this helps.

\$\endgroup\$
  • \$\begingroup\$ Hey Victor, that explanation is a bit vague still but the article seems extremely helpful. I'll check if I can implement it tonight and let you know the results. \$\endgroup\$ – Roy T. Feb 18 '14 at 15:03
  • \$\begingroup\$ After a night of puzzling the sample code from that blog made it work for me :) \$\endgroup\$ – Roy T. Feb 19 '14 at 14:45
0
\$\begingroup\$

isn't there a more "raster"-like method for 2d shadows ?

like a shadow map, except it would only be a 1D texture. The difficult part would be to render proper distances because of sprites being rectangles of pixels, there would be some pixel perfect collision detection to make, using grid marching for example. Not trivial. (but your geometrical solution also requires that anyway)

but then with a shader the presence of shadows would just be determined by a bit of projective maths and a lookup.

the scaling for multiple lights would work like any 3d engine, either using classic forward (all for all) shader, or defered (multi pass) shading.

\$\endgroup\$
  • \$\begingroup\$ I guess this could work in theory but I wouldn't be able to get this working without a proper source I'm afraid :). \$\endgroup\$ – Roy T. Feb 18 '14 at 15:05
  • \$\begingroup\$ It's certainly possible to do shadow-mapping in 2D. I implemented it once and had some trouble dealing with the artifacts. There are some interesting "wins", such as being able to store a large number of shadow maps in one texture. \$\endgroup\$ – Victor T. Feb 21 '14 at 21:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.