LÖVE

(See this post onward instead)

I'm currently trying to code a lightning system and I first tried using kikito's bresenham lib to detect which coordinate can be light and then, well, I'd light them. Here's the ouput:
(Warning: You might find dead pieces of code in there) It looks nice but the thing is that map is only 19x19 and since the algorithem checks every possible pixel it runs 361 times in one frame, if I use a bigger map, 1920x1080, it'd run 2073600 (minus not visible pixels) times and that'd consume lots of resources possibly decreasing the FPS so I decided to explore the net for a better lightning system.

I found this which explains quite a few ways of how to code light, I think that wall tracking'd be the best option and since it uses triangles to draw the light I thought about the newMesh function which creates polygons out of triangles, and since the light polygons are made out of trinagles centered on one point I could use the "fan" mode, (first question) what do you guys think, will this work ?
(Next questions)

(...) we want to find the nearest wall (...). Our strategy will be to sweep around 360° and process all of the wall endpoints.

and

How do you figure out which wall is nearest? The simplest thing is to calculate the distance from the center to the wall. However, this approach doesn’t work well if the walls are of different sizes, so the demo uses a slightly more complicated approach, which I won’t explain here.

With that I don't know how to "sweep around 360º" and how to calculate neither the nearest wall and the endpoints of walls.
Do any of you know a good way to do that with a map built with walls made out of rectangles like: Or maybe better way to code light ?

-snip-

I haven't seen monocle's source yet because I remember a few months back I tried but I didn't understand any of it, I'm going to try again though

EDIT: Still no luck, too many functions . I'm going to read some more articles on this, if you know the answer to any of my questions or you just have an advice feel free to post.

I would suggest this one: deepnight and also these notes on how to implement lighting effect using Monaco LOS algorithm.

Roland_Yonaba wrote:I would suggest this one: deepnight and also these notes on how to implement lighting effect using Monaco LOS algorithm.

Thanks for the links, I had already seen both of them, but I'm going to try the second one again.

Ranguna259 wrote: It looks nice but the thing is that map is only 19x19 and since the algorithem checks every possible pixel it runs 361 times in one frame, if I use a bigger map, 1920x1080, it'd run 2073600 (minus not visible pixels) times and that'd consume lots of resources possibly decreasing the FPS so I decided to explore the net for a better lightning system.

Yes, as mentioned in other thread, bresenham is good for drawing pretty lines in a canvas, but it is not ideal for vision/light. Definitively it is not the best took for casting cones of light.

The facebook monocle article explains what it does very well, but you will need some math yourself to do the intersections between segments and lines. Try reading it and come up with your code, instead of trying to use its code as a base.

I remember playing with a LÖVE demo someone made (maybe vrld?) about a flame jumping arond and casting shadows on several platforms while a passive-aggressive narrator printed messages on the screen. But I could not find it.

Yup, vrld
Here it is, by the way

(I'll just revive this thread as I didn't want to create another one with the same topic)

So far I think my lightning system is good but I've come to a dead end, here's what I've done: First I put all edges and all side of all reactangles into two (sometimes huge) tables, then I make two other tables to sort which edges and side are visible:

This only needs to be done once or everytime the light moves over a certain threshold so if the light is static then the system will only do this action once.
Next, the code runs a for loop to every visible edge and "runs a raycast" from the light source to that edge to check if a line of sight existes, if there's a LOS then the code runs, once again, a raycast to do the actual side of the shadow.

And that's all, after writing all this into LÖVE and by adding offscreen "border" rectangles I got this:


And now my problem is that I can't organize all the points into one "fan" Mesh, I've read that I needed to do a "360º swepping" and then I'd just need to connect all points as the swepping goes but I realy don't know how to do that. (play the first demo on the Wall Tracking section on this link to see an exemple of a 360º swepping)

Can any of you help me out here, what I have:
- All visible edges (with LOS) of the rectangles.
- All raycasted end points of all visible edges.
- Basicly I have all yellow, blue, red and green points shown in the last image.

Monocle was very difficult for me, and I'm sort of surprised I even got it working. The process laid out in that blog post is fairly straightforward, but I ran into edge case after edge case.

The problem you're having with the 'sweeping' was the hardest part and took most of the work. I had to keep track of the 'previous' and 'next' edge for each edge, which gets complicated fast when you are casting the rays and splitting the edges into new ones, or when your projection hits a corner.

If you want to implement something like this, I really suggest trying to use Monocle. It took me dozens of hours to get working. Germanunkol's version cleans up the callbacks very nicely and makes it easy to use.

If you want, I could help you understand the code. But there's really no way to unravel the add_projection_edge function. All the complexity in there is due to special cases.

EDIT: I just read the Red Blob article. This method does seem a bit simpler, but I haven't looked very hard at the code.

Amit (the author of the redblob article) is a terrific article writer and library implementor. His articles are usually top quality.

Don't mis his post about the blog post, in which he lists similar techniques that he's found.