Talk:Precise Permissive Field of View

From RogueBasin
(Difference between revisions)
Jump to: navigation, search
(advertising my new algo)
Line 3: Line 3:
 
I dare to question the fact that point "d" should always be visible from "s" in a Kuo corridor. It makes intuitive sense to me that the field of view should be blocked by the wall cell directly due east from "s" and create an appropriate slice of unlit area behind it. Thus, the FOV should actually end somewhere in the middle of the corridor, without ever reaching "d". [[User:Dominikmarczuk|Mingos]] 16:34, 22 August 2010 (UTC)
 
I dare to question the fact that point "d" should always be visible from "s" in a Kuo corridor. It makes intuitive sense to me that the field of view should be blocked by the wall cell directly due east from "s" and create an appropriate slice of unlit area behind it. Thus, the FOV should actually end somewhere in the middle of the corridor, without ever reaching "d". [[User:Dominikmarczuk|Mingos]] 16:34, 22 August 2010 (UTC)
  
I think the definition of "permissive" used here is: "A destination square is visible from a source square if there is any unobstructed line from '''some point''' in the source square to '''some point''' in the destination square." And in the case of the Kuo corridor, there exists such a line.--[[User:Kusigrosz|Kusigrosz]] 21:06, 22 August 2010 (UTC)
+
* I think the definition of "permissive" used here is: "A destination square is visible from a source square if there is any unobstructed line from '''some point''' in the source square to '''some point''' in the destination square." And in the case of the Kuo corridor, there exists such a line.--[[User:Kusigrosz|Kusigrosz]] 21:06, 22 August 2010 (UTC)
 +
 
 +
Hi! I have a variant of this algorithm, with the general structure borrowed from Recursive Shadow Casting. Seems simpler (especially the DFOV variation of it) and does not inspect tiles behind obstacles, so should be much faster on maps with long corridors. It's coded in Haskell. Please have a look and point flaws in it at https://github.com/Mikolaj/LambdaHack/wiki/Fov-and-los. --[[User:Mikon|Mikon]] 02:29, 15 December 2010 (UTC)

Revision as of 03:29, 15 December 2010

I'm currently hosting the images at my own website (anotbnotornot.com) and linking them here because uploading images is disabled on this wiki. I'd prefer to just upload them. Let me know if there is a way to do this. -Duerig 09:34, 24 Mar 2007 (CET)

I dare to question the fact that point "d" should always be visible from "s" in a Kuo corridor. It makes intuitive sense to me that the field of view should be blocked by the wall cell directly due east from "s" and create an appropriate slice of unlit area behind it. Thus, the FOV should actually end somewhere in the middle of the corridor, without ever reaching "d". Mingos 16:34, 22 August 2010 (UTC)

  • I think the definition of "permissive" used here is: "A destination square is visible from a source square if there is any unobstructed line from some point in the source square to some point in the destination square." And in the case of the Kuo corridor, there exists such a line.--Kusigrosz 21:06, 22 August 2010 (UTC)

Hi! I have a variant of this algorithm, with the general structure borrowed from Recursive Shadow Casting. Seems simpler (especially the DFOV variation of it) and does not inspect tiles behind obstacles, so should be much faster on maps with long corridors. It's coded in Haskell. Please have a look and point flaws in it at https://github.com/Mikolaj/LambdaHack/wiki/Fov-and-los. --Mikon 02:29, 15 December 2010 (UTC)

Personal tools