Lighting issue

[carlm...@gmail.com]

I'm working on a roguelike and have an issue with my lighting which I hope someone can give me some insight on. I'm using a library to do shadow casting FOV to determine which squares have light falling on them and have an issue with light cast onto opaque objects by light sources on the opposite side from my player.

Here is an example:

X = light source (torch or whatever)
@ = player (obviously)
| = lit wall (obstructs light and FOV)
: = unlit wall (obstructs light and FOV)
+ = lit floor (transparent to light and FOV)
. = unlit floor (transparent to light and FOV)

:|||:::::
X:...++++@
:|||:::::

My player has a light source that extends around 4 squares out from itself but has a FOV that extends much father. The desired result is that from this perspective the player would not be able to see the wall at the end of the corridor but because the X lights the walls the player can see them.

My first attempt to fix this problem was to store a different light value for the light falling on the top/bottom/left/right sides of each tile that obstructs light and using that in combination with the players position relative to the square to determine if that light is visible to the player, this succeeds in fixing the example above but isn't perfect. For example the following state results in the wall at the bottom being lit because the light from the light source is falling on the top of that square and the player (being above that square) sees it as lit even though it should be too far away to be lit by the players light source.

||||:@
|||:+
||:+
|.+
X|+
:.

Hopefully I have made some amount of sense and someone will know of a better way to handle this issue.

Thanks.

[carlm...@gmail.com]

Hmm...looks like the spacing on my examples didnt quite format the same in the actual post as in the preview :(

[carlm...@gmail.com]

The second example is harder to actually come by in my game and didnt get quite as mangled as the first so im gonna hope its clear but heres a screenshot of the first example from my game:

http://imgur.com/T8gJ5Vv

you cant see the other light source because it is on the opposite side of the door but hopefully it is apparent what is going on.

[Gerry Quinn]

In article <b3cd31d9-3780-4921...@googlegroups.com>,
carlm...@gmail.com says...

> The second example is harder to actually come by in my game and didnt get quite as mangled as the first so im gonna hope its clear but heres a screenshot of the first example from my game:
>
> http://imgur.com/T8gJ5Vv
>
> you cant see the other light source because it is on the opposite side of the door but hopefully it is apparent what is going on.

Ah, that makes sense.

Seems a slightly tricky issue. It would actually be worse if there was
no door, just a wall, because one can imaging that light leaking through
a door is reasonable.

Maybe you actually need to have blocking objects record which sides of
them are lit.

- Gerry Quinn

[carlm...@gmail.com]

Yeah like I said that was the first thing I tried but at least my solution didnt quite work because if the player is above and to the left of the wall, and the other light source is above and to the right of the wall then the player sees the light that is being cast on the top of the wall even though that doesnt really make sense.

[David Damerell]

Quoting <carlm...@gmail.com>:
>Hopefully I have made some amount of sense and someone will know of a better
>way to handle this issue.

I have wrestled with something similar in our almost entirely
non-developed roguelike.

The approach I took was not to mark sides of walls as lit - a wall has no
light levels, not even temporary ones, in and of itself. Instead light
sources light non-wall tiles only. The LOS algorithm then, when it finds a
wall, looks back at the tiles that the player might be looking "through"
in order to see the wall; the light level of the wall is the highest light
level of the subset of those tiles that the player can see into (which
implies that they are not walls themselves).

There are some edge cases but I'm afraid I forget what they are.
--
David Damerell <dame...@chiark.greenend.org.uk>
And now, a seemingly inexplicable shot of a passing train.
Today is Mania, March.
Tomorrow will be Aponoia, March.

[Konstantin Stupnik]

On 03/03/14 22:57 , David Damerell wrote:> Quoting <carlm...@gmail.com>:

>> Hopefully I have made some amount of sense and someone will know of
a better
>> way to handle this issue.
>
> I have wrestled with something similar in our almost entirely
> non-developed roguelike.
>
> The approach I took was not to mark sides of walls as lit - a wall has no
> light levels, not even temporary ones, in and of itself. Instead light
> sources light non-wall tiles only. The LOS algorithm then, when it
finds a
> wall, looks back at the tiles that the player might be looking "through"
> in order to see the wall; the light level of the wall is the highest
light
> level of the subset of those tiles that the player can see into (which
> implies that they are not walls themselves).
>
> There are some edge cases but I'm afraid I forget what they are.
>

If you walk along unlit corridor toward corner that turns to a lit
part of a corridor, with that logic corner wall will suddenly become
lit once lit tile next to it become visible.
IMO sudden changes of lightness are even worse that not so realistic
lighting.
I tried to play with proper lightning of walls in wq, but in the
end I left 'lit from the other side' walls as they are.
When you can see as monster with light source walks along the other
side of the wall, it adds something good to atmosphere (IMO) :)