Looks like I kind of inverted the polarity of the raycasting with regard to the player and the level geometry.
The algorithm doesn’t raycast in the full 360° circle around player–that would be too costly. Instead, it takes advantage of the fact that the level’s ground collision geometry is stored in a grid.
Given the player’s location, there is a small list of collision geometry in the 8 or so grid cells surrounding the player.
The lighting algorithm raycasts from the corners of the level geometry to the player, instead of from the player out to the geometry.
Then, to prevent the lighting from looking too triangular, the algorithm adds a few more raycasts out from the player to the geometry in between the other raycasts.
That’s actually all there is to it
The algorithm I originally envisioned was naive and costly. But, it’s nice to hear that I wasn’t far off–I simply inverted the solution. It was also nice to learn about a benefit of storing level geometry in a grid that I previously failed to appreciate.