Original Post
Comments for the article Walls and Shadows in 2D
🔒 Locked
Walls and Shadows in 2D
Advertisement
This is one of the most awesome articles I've ever read, kudos for going into such detail! I've been wanting to try some similar ideas, it's nice to see such a thorough treatment; also those maps look pretty cool.
A couple comments:
1) You could probably smooth the edges of the visible/hidden region by simply calculating visibility at triangle vertices instead of centroids, and then having adjacent triangles share vertices, so that (with smooth shading enabled) the graphics card would interpolate colour/alpha across triangles.
This might not help much however, the boundaries will just be smeared/smoothed versions of what you currently have; it should be just as cheap/fast to compute as your current method though, so it might be worth trying.
2) What is your use case for this visibility/lighting info? When I was researching this sort of thing I had a hard time imagining an application which wouldn't work just as well by separating the graphical and logical queries.
What I mean is that you could use 2D-stencil-shadows to replicate the graphical effect (something like this article) which should produce results similar to using pixel-sized triangles with your method. If you then need visibility/lighting information for game logic/AI/etc., you can use per-object queries (i.e cast rays or beams between objects and light sources to determine lighting/visibility).
I'm not sure if such a separate graphics/logic approach would be cheaper or not, I suppose it really depends on the specific use case (number of entities requiring visibility info, etc).
Anyway, it's really great to see articles that explain things in-depth. Thanks for writing it!
A couple comments:
1) You could probably smooth the edges of the visible/hidden region by simply calculating visibility at triangle vertices instead of centroids, and then having adjacent triangles share vertices, so that (with smooth shading enabled) the graphics card would interpolate colour/alpha across triangles.
This might not help much however, the boundaries will just be smeared/smoothed versions of what you currently have; it should be just as cheap/fast to compute as your current method though, so it might be worth trying.
2) What is your use case for this visibility/lighting info? When I was researching this sort of thing I had a hard time imagining an application which wouldn't work just as well by separating the graphical and logical queries.
What I mean is that you could use 2D-stencil-shadows to replicate the graphical effect (something like this article) which should produce results similar to using pixel-sized triangles with your method. If you then need visibility/lighting information for game logic/AI/etc., you can use per-object queries (i.e cast rays or beams between objects and light sources to determine lighting/visibility).
I'm not sure if such a separate graphics/logic approach would be cheaper or not, I suppose it really depends on the specific use case (number of entities requiring visibility info, etc).
Anyway, it's really great to see articles that explain things in-depth. Thanks for writing it!
Very interesting read and a lot of great ideas!
While reading it, I however got the feeling that this could be implemented even faster. Using the fact that we are dealing with point lights, we could represent all shadow-casting wall segments as segments dividing a circle around the viewer. Using such a representation, I think answering a visibility query for a single point against the light source could be done in worst-case O( log n ) , with n the number of walls visible from the light source.
I am going to think about it some more tough, before claiming I can do better :D
While reading it, I however got the feeling that this could be implemented even faster. Using the fact that we are dealing with point lights, we could represent all shadow-casting wall segments as segments dividing a circle around the viewer. Using such a representation, I think answering a visibility query for a single point against the light source could be done in worst-case O( log n ) , with n the number of walls visible from the light source.
I am going to think about it some more tough, before claiming I can do better :D
Wow really awesome article.
People are so focused on 3d these days it's nice to see innovative techniques still going on in 2d (:
3d is nice for some kind of games but i think 2d still has a home and isn't going away for the foreseeable future.
GREAT ARTICLE!
People are so focused on 3d these days it's nice to see innovative techniques still going on in 2d (:
3d is nice for some kind of games but i think 2d still has a home and isn't going away for the foreseeable future.
GREAT ARTICLE!
Interesting approach, but the quality is pretty bad.
I mean look at the edges in this shot:
The edges of the shadows are horribly irregular and spiky, yet the underlying triangle mesh should be able to give much smoother results. I think raigan is correct in thinking you should be calculating the visibility at vertices rather than per-triangle.
Also, you've got three repeated paragraphs just after fig 6.
Your final step of calculating which polys are visible also seems overly complicated - since you've already got a set of polys defining the visible regions I suspect that regular rasterisation of the polys onto your mesh would be much faster. With an edge table you'd be able to do whole scanlines at a time with a much smaller per-vertex overhead.
[Edited by - OrangyTang on November 12, 2009 2:50:44 PM]
I mean look at the edges in this shot:
The edges of the shadows are horribly irregular and spiky, yet the underlying triangle mesh should be able to give much smoother results. I think raigan is correct in thinking you should be calculating the visibility at vertices rather than per-triangle.
Also, you've got three repeated paragraphs just after fig 6.
Your final step of calculating which polys are visible also seems overly complicated - since you've already got a set of polys defining the visible regions I suspect that regular rasterisation of the polys onto your mesh would be much faster. With an edge table you'd be able to do whole scanlines at a time with a much smaller per-vertex overhead.
[Edited by - OrangyTang on November 12, 2009 2:50:44 PM]
Quote:
Original post by OrangyTang
Also, you've got three repeated paragraphs just after fig 6.
Grrrrr...
Okay, fixed that, also fixed the printable version that had the footnotes just stuck in the middle of the article (now they're just above the code listing), and made the footnotes on Page 2 small text.
Great article!
But for camera visibility, I would use a BSP tree with all the edges and a front to back rasterization into 1D depth buffer.
During traversal, that BSP tree would be tested versus that depth buffer, so we end up with the nodes that are potentially visible.
For point lights, we could do with the rendering of four views, or try a paraboloid projection.
[Edited by - Zemedelec on November 21, 2009 2:13:08 AM]
But for camera visibility, I would use a BSP tree with all the edges and a front to back rasterization into 1D depth buffer.
During traversal, that BSP tree would be tested versus that depth buffer, so we end up with the nodes that are potentially visible.
For point lights, we could do with the rendering of four views, or try a paraboloid projection.
[Edited by - Zemedelec on November 21, 2009 2:13:08 AM]
Topic Locked
This topic has been locked by a moderator. New replies are not allowed.
Sign in to reply to this topic.
Advertisement