Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

My own approach to this problem would be to consider each tile as a square polygon, then simply project the vertices outward from the light source. Then you take the resulting triangles and rasterize them on to an image scaled such that each pixel represents a tile and use antialiasing (or simply rasterize them on to an image 8 times as large as you need it and scale down, which is essentially the same thing). This gives you roughly the same end result, but would allow you to hardware accelerate almost every single aspect and avoids all the artifacts of shadowmapping. Notably, by restricting each polygon to a square, the projection could be done entirely as a vertex shader, without requiring geometry shaders. This would likely be vastly more efficient due to taking advantage of hardware acceleration.


Depends on how much of this algorithm you can heft onto the hardware. I'd like to see a polar coordinate textures and operations on graphics cards in the future. Thanks for reading!


Even if you moved the polar coordinate shift to the hardware, you're doing pixel ray operations on the texture, followed by rasterization. I do vertex operations only, which are vastly fewer in number even in a worst case scenario, and then rasterize that. I'm willing to bet that even if we implemented this on the CPU, my algorithm would still be significantly faster and more accurate. Furthermore, your algorithm would struggle to take into account soft shadows, which actually become a noticeable problem in certain situations in large tilemaps when you have very large light radii.

I think the polar coordinate transformation trick is really cool, but I feel like this is the wrong use for it. This is essentially a solved problem using polygons in 2D lighting engines already - to make it work for tiles, you simply scale down and back up to map to tiles.

I have to admit I'm sorely tempted to implement this in WebGL just to see what happens.


I don't deny that simple 2d operations would be faster nor do I claim this to be a fast solution, I simply wrote the idea as it came to me and I have taken no time to implement it yet nor to compare it with other techniques in any detail. As always, thank you for reading and for your thoughts.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: