Light of war instaed of Fog of war?

I think this is already in the works, with light sources and fow and such. I thought I'd post here with the issue I have currently with the new, much imporoved, fow.

First, the new fow is very usable. It's quite a deal better than the square based fow previously. It's really very good, and editable, and such, and I feel like it needs very little improvement.

I think if there was improvement, it would simply be to bitmask/use 'or' instead of 'and' for regions that are 'unfogged', so I could define areas that get 'light' when I select them, rather than areas that get 'dark'. That is, right now, if I make two overlapping fow regions, and select one as 'visible', it gets occluded by any other overlapping fow regions.

This makes sense in thinking of fow layer as fog. It makes terrible sense in thinking of fow layer as areas to define based on light sources. Why? Imagine the two overlapping regions theorized above:

In a 'light region' model (not d20pro's current), selecting one or the other overlapping region shows that whole region regardless of overlap. 'This room and some of the hallway are visible to you'.

In a 'fow' model, selecting one or the other region only displays parts not being overlapped. So there's no benefit to overlapping; rather than defining two regions where light /will/ exist, I instead have to define three regions where light /won't/ exist. If I want to define a room and a hallway, where if you stand in the hallway, a little light pours into the room, but not all of it, and if you stand in the room, a little light pours into the hallway, but not all of it, instead of defining the room + some hallway as one region, and the hallway + some room as region two, I have to define the hallway minus room overlap, the hallway's room overlap, the room minus hallway overlap, and the room's hallway overlap; 4 regions instead of 2. Ok, big deal right? Except the more fine grained this gets, the more dozens, then hundreds, of regions stack up instead of a very small handful.

Example of simple rooms defined with fow:


Example of simple rooms with 45 degree shadows:


Partially started example of more complicated shadows:


You can see I've barely begun #3, but already defining all the little pieces by what they can't be rather than what they can gets complicated. My only point is that swapping the 'and' function to 'or' for whether a region overlapping another is shown when 'visible' significantly reduces the amount of regions needing to be defined while allowing fairly complex light-source based regions to be created.

This might all be obsolete if a dynamic fow/light system is implemented anyway, but until then maybe this could be a good stop gap.

 

I think the describe-then-reveal is best actually. I'd never actually make a room like this for a game - I have a life outside gaming. But with the new fow system, it seemed to be so useful to define my own areas, and then my players wanted to peek into a room while in combat and see what they could but I didn't want to reveal my 'dynamically' invisible monsters... so I started thinking about defining areas that let players peek into rooms and well, the above was an example of why that would be tough. So I can send my players to this forum if they want to know why.

Anyway, if layers are involved I think doing anything different would be complicated, and a waste of time if things are going to change at some point in the future anyway. But now I've been able to illustrate for anyone why making lighting angles on the maps would probably be a bad idea usually.