Angband Forums targetting and LOS
 Register FAQ Members List Calendar Search Today's Posts Mark Forums Read

June 24, 2009, 01:38   #121
The Wanderer
Rookie

Join Date: Jun 2009
Posts: 2
Quote:
 Originally Posted by Marble Dice The heart of this issue is that I believe LOS should be symmetric. Consider a door into a room. Stand at that door. You can't see the entire room, just a cone of it. Under a symmetric LOS algorithm, being able to see all room walls from any interior room tile would imply you could see every interior room tile while standing on any door to that room. To phrase it backwards, if, under a symmetrical LOS system, standing in a door yields a cone-shaped field of view, then if you were standing in any of those initially non-visible tiles, you would be unable to see that door to the room.
(This doesn't necessarily have anything directly to do with the above, but it was inspired by reading it.)

I think that the problem is that a door is modeled as a full-size tile, but our intuitive expectations about visibility are based on it being a much narrower object and occupying only the very edge of the tile.

In real life, someone standing in an open door would certainly be visible from within the room, even from a far corner, and would be able to see the corners as well (if looking in that direction, of course). The "door" is only a few inches thick at most, and "standing in the door" means occupying the same space that the door would occupy if it were closed.

However, in Angband, a "door" is actually a square a few feet on a side, and "standing in the door" is in some respects treated as being in the center of that square - and someone in that position would not necessarily be able to see, or be seen from, the corners.

Generalizing from the above: what it means to "see" a wall or a door or an open space, and what it means to "see" a person or monster or item in that wall or door or open space, are not necessarily the same thing.

Seeing a tile requires a direct line from the center of the "seen from" tile to an edge of the "seen" tile (you don't have to see deep into the rock to tell that it's a wall). However, seeing what is in the tile - character, monster, treasure, etc. - requires a direct line from the center of the "seen from" tile to the center of the "seen" tile (just because you can see the edge of the open space doesn't mean you can see the ring lying in the middle of it). Missiles (projectability) require the latter line as well.

If we could separate the two types of visibility, might some at least of the problems not go away?

(Of course, this doesn't fix the problems about the shadows cast by single-tile pillars - if anything it may make them worse - but I hope it might at least lead to improved ideas...)

June 24, 2009, 01:56   #122
buzzkill
Prophet

Join Date: May 2008
Location: Indiana, USA
Posts: 2,939
Donated: \$8
Quote:
 Originally Posted by PowerDiver You misunderstood me. (4) is if you stand 10' from the wall in an *empty* square room with no pillars. Do you think you should be able to see the walls? That's 10' into the interior, not 10' down a corridor.
Well, I kinda did, but you convinced me otherwise. I hope that was your intention.

With your POV 5' from the wall (centered in a 10' grid) and still using only the diamond method, your field of vision would be very similar to this. It looks good to me. Cannot see the doorway or anything occupying the doorway, nor can it see @. In short, I guess you could say that you can see the walls (or doorways, or enemies in doorways) for 20' in either direction while standing adjacent to a wall. It's really just the hockey stick all over again!

EDIT: and of course that pillar in the room should be yellow (visible).
Attached Thumbnails

__________________
www.mediafire.com/buzzkill - Get your 32x32 tiles here. UT32 now compatible Ironband and Quickband 9/6/2012.
My banding life on Buzzkill's ladder.

June 24, 2009, 03:57   #123
d_m
Angband Devteam member

Join Date: Aug 2008
Age: 39
Posts: 1,516
Quote:
 Originally Posted by buzzkill With your POV 5' from the wall (centered in a 10' grid) and still using only the diamond method, your field of vision would be very similar to this. It looks good to me. Cannot see the doorway or anything occupying the doorway, nor can it see @. In short, I guess you could say that you can see the walls (or doorways, or enemies in doorways) for 20' in either direction while standing adjacent to a wall. It's really just the hockey stick all over again!
I think you misunderstand the DFOV diamond method. If a wall blocks your LOS, you get to know that that square was a wall (which blocked your LOS). If there is no blocking wall then you can see the square.

Thus, walls which have terminating lines are seen. In fact, according to DFOV it isn't necessary to connect centers but to connect any points in the diamond in order to see a square.

Maybe you're referring to a different diamond-based LOS algorithm instead? I think Eddie is talking about diamonds in the context of DFOV but I may be wrong.

See the LOS section (Between Two Points) here: http://roguebasin.roguelikedevelopme...implementation

June 24, 2009, 04:19   #124
PaulBlay
Knight

Join Date: Jan 2009
Posts: 657
Quote:
 Originally Posted by PowerDiver The problem is that an expanding cone from one corner moves out to cover well into the interior of the room in the other corner.
I can't visualize that. What cones are there when you're inside the room? Are you talking about the corner square of wall that technically is hidden if you assume all walls completely fill the square they ar in?
__________________
Currently turning (Angband) Japanese.

June 24, 2009, 04:37   #125
Pete Mack
Prophet

Join Date: Apr 2007
Location: Seattle, WA
Posts: 5,751
Donated: \$40
Quote:
 Originally Posted by d_m I think you misunderstand the DFOV diamond method. If a wall blocks your LOS, you get to know that that square was a wall (which blocked your LOS). If there is no blocking wall then you can see the square.
Which brings up still another possibility. A monster is visible if he's in a square where a wall would be visible. He is targetable if he's in a square where the center is visible. (That's very similar to the current model, but with symmetric lines of sight and targeting.)

The benefit is that a non-ESP character usually gets a warning when a (same-speed) monster is about to blast her.

Last edited by Pete Mack; June 24, 2009 at 04:56.

June 24, 2009, 04:49   #126
buzzkill
Prophet

Join Date: May 2008
Location: Indiana, USA
Posts: 2,939
Donated: \$8
Quote:
 Originally Posted by d_m ... If a wall blocks your LOS, you get to know that that square was a wall (which blocked your LOS). If there is no blocking wall then you can see the square.
So maybe it's not the DFOV method (maybe it is?). But the above quote does describe my (adopted, maybe my own little hybrid) method. You can only see a tile, if you can see the center point of that tile, wall or not. When the nearer wall prevents you from seeing the center point of the further wall, then you stop seeing the wall. I seems to work well. Feel free to poke holes in it.

Quote:
 See the LOS section (Between Two Points) here: http://roguebasin.roguelikedevelopme...implementation
Like I said earlier, some of this stuff is a little over my head.
__________________
www.mediafire.com/buzzkill - Get your 32x32 tiles here. UT32 now compatible Ironband and Quickband 9/6/2012.
My banding life on Buzzkill's ladder.

 June 24, 2009, 05:25 #127 Marble Dice Swordsman   Join Date: Jun 2008 Location: Columbia, MO. USA Posts: 405 Buzzkill is not talking about DFOV, it seems like he is talking about exactly the system I referred to as "obstructing diamonds." PowerDiver's problem with this system is that you can't "see" all the wall tiles from the inside of the room, but that is just a trick of the model vs the graphical representation, and understanding what it means to see a wall tile. In the method buzzkill and I have been talking about, a unit standing on a door to a room is considered outside of the room, and has partial cover. Yes, if you stand in a corner, you can't see every wall tile, but all that means is you can't see what lurks behind every entrance to the room you're in. You can still see the entire room (all interior spaces), and the game will still show you the walls of the room if you've seen them - but you'll also have feedback on which wall tiles are "visible" - namely, which tiles you know do or don't have a passwall monster in them, and which tiles you could open with stone to mud and still have LOS on that location. In a sense, wall tiles are more like the 1000 cubic feet of stone beyond the room, not the "between-the-tiles" facade that would of course be apparent to anyone inside of the room. In DFOV, a unit standing on a door to a room is considered inside that room. One tile behind the door is partial cover. A room's wall tiles in this model are like part of the room, except you can't actually move onto them. Both are perfectly fine algorithms that differ in interpretation of the dungeon and implementation. DFOV would probably be easier to implement (especially since it's already got a demo), but obstructing diamonds or whatever you wanna call it has expanding shadows on single pillars. Both models are consistent and incorporate the same notions of partial cover and room interior, albeit the location is shifted one tile. As The Wanderer suggests for obstructing diamonds, you could even add a more permissive "tile visibility" that just requires an unobstructed line to the tile, so you could get a "sneak peak" at tiles you don't actually have (unit) visibility on yet. This would allow you to get a room's wall tiles put into your dungeon memory even from a corner, but you still wouldn't have visibility on the ones you couldn't see a ghost inside of.
June 24, 2009, 07:06   #128
PowerDiver
Prophet

Join Date: Mar 2008
Posts: 2,712
Quote:
 Originally Posted by PaulBlay I can't visualize that. What cones are there when you're inside the room? Are you talking about the corner square of wall that technically is hidden if you assume all walls completely fill the square they ar in?
Take any square W, wall or entrance or door doesn't matter Think of a wall square in a room about 20% away from a corner for starters. A wall X next to W causes visibility blockage, which if expanding goes into the interior of the room. If we assume symmetry, if Z is in the shadow behind X when viewing from W, Z cannot see W.

Most of the examples of people describing blockages describe angles from 30 to 45 degrees for the shadow cast when horizontally adjacent to a #. Even with a 30 degree angle shadow, a char standing in the exact center of a pit will only be able to see 11 squares out of the 19 [IIRC] squares + 2 corners of the long horizontal wall separating the inside from the moat below.

If you want to model pillars that are larger than the @, you should refine the granularity so that they take up more squares than the @ does. When you do not, you should not be surprised if other factors cause thngs you find counterintuitive from the perspective that the column is wider than the @.

Imagine if you will that the interpretation is that squares are 2'x2', and while you are not allowed to move your feet you are allowed to lean 1' in either direction. What is your field of view when directly behind a 2' diameter pillar? This situation is consistent with the @ and pillar taking up 1 square each. People will argue that other behaviors are also consistent, and they will be correct too. Murphy's law takes over to imply that when there are multiple consistent possibilities, the one that falls out of coherent rules is generally the one you were least hoping for.

The solution is trivial. If you want blockages that are guaranteed not to be smaller than the player, make them take up more minimum-granularity squares than the player does, for best results at least one more in every direction. E.g. a 10x10 player centered behind a 12x12 obstruction will see an expanding cone of shadow. When you specify them to take up the same space, you are allowing malevolent forces beyond your control to determine which one ends up as apparently slightly bigger. Your granularity determines your roundoff errors. Roundoff errors should always be assumed to happen in your disfavor. That's modeling 101.

Instead of bitching about single-# columns in large open areas, which doesn't even happen much anyway, people should be applauding how well things appear to work in DFOV. Achieving symmetric LOS could have been a whole lot worse.

June 24, 2009, 09:02   #129
PaulBlay
Knight

Join Date: Jan 2009
Posts: 657
Quote:
 Originally Posted by PowerDiver Take any square W, wall or entrance or door doesn't matter Think of a wall square in a room about 20% away from a corner for starters. A wall X next to W causes visibility blockage, which if expanding goes into the interior of the room. If we assume symmetry, if Z is in the shadow behind X when viewing from W, Z cannot see W.
Yeesh, I think that is a classic example of "a picture is worth a thousand words."
__________________
Currently turning (Angband) Japanese.

June 25, 2009, 00:23   #130
PowerDiver
Prophet

Join Date: Mar 2008
Posts: 2,712
Quote:
 Originally Posted by PaulBlay Yeesh, I think that is a classic example of "a picture is worth a thousand words."
The problem is that I don't know how to draw those pretty pictures. Also, I was trying to make an argument that applied to all forms of expanding cones, not just a particular one, so there isn't a specific example to show.

Code:
```###WXY##########
................
................
............Z...
................
................```
Consider the shadow behind X when you view from W, assuming X is a wall square.
The model needs to cope both with Y being another wall square or an entrance.
Let's say that Z is in that shadow. Then W cannot see Z. Then Z cannot see W.

So a square well in the interior of the room cannot see all of the walls of the room.

 Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 Thread Tools Display Modes Linear Mode

 Posting Rules You may not post new threads You may not post replies You may not post attachments You may not edit your posts BB code is On Smilies are On [IMG] code is On HTML code is Off Forum Rules
 Forum Jump User Control Panel Private Messages Subscriptions Who's Online Search Forums Forums Home Angband     AAR     Vanilla     Development     ToME     Sil     Variants     Competition The real world     Idle chatter     Oook! Obsolete     v4