Token with VBL doesn't display at some zoom levels when "Always Visible" is checked

[Azhrei]

This applies to 1418. At some zoom levels (about one out of three when zooming with the mouse) the object was not being drawn on top of the VBL.

[JamzTheMan]

Odd, was this maybe a rounding error? Like a corner clipping vbl so vision on token was just barely 2/9ths?

[Azhrei]

It didn't seem like it. Token in question was a door image that stuck out from the VBL by quite a bit. I'll try to build an example at attach it here. It wasn't my campaign file (and in fact, I'm still playing on that map!), so I don't plan to get it straight from the GM until we've at least finished that area.

[Phergus]

Unable to reproduce. No test case supplied. Closing.

[melek]

I have been able to reproduce this. Sample campaign supplied. Zooming or panning around this map with 'Player View' enabled flickers the two left map tiles which are under hard FoW.

Github Issue 242 Demo Campaign.zip

Observations

• Moving the VBL to the map from the token doesn't change the behavior.
• These tokens are perfectly opaque and square, filling up their entire grid square with VBL precisely.

Edit: Forgot to mention I'm on Windows 10 when I do this. I use an NVidia GTX 1060 if that matters.

[emmebi]

@melek

1. Opened the attached file with the latest build from source
2. Checked the Player Visible under Map menu (is that what
3. Zooming in and out: no flickers
4. Panning int and out: no flickers

Did I reproduce the scenario correctly? If this is the case, can you check the latest Alpha and see if it still shows the issue?

[Phergus]

You can still see it in current develop and 1.5.13.

1. Open campaign.
2. Expose vision for token.
3. Switch to Player view
4. Mouse-wheel to zoom in/out.
5. On my system at 45%, the center one is visible but not the left one.
6. At 69%, the left one is visible but not the center.

[Merudo]

I checked Melek's file, and the most likely explanation is that the bug is caused by a roundoff error.

Depending on the zoom level, the VBL may show up 1 pixel in front of the actual token, hiding the token and preventing Always Visible from taking effect.

The easiest work around is to not fill the entire grid square with VBL. Leave a handful of pixels around the edge free of VBL to guard against unwanted rounding errors.

[Jmr3366]

Just to share it's still there, and some video for clarity. It occurs at specific zoom levels

https://user-images.githubusercontent.com/100969108/190861916-f6c3ccc6-1209-4f3e-a1f6-258463fe21b7.mov

[kwvanderlinde]

The main culprit is the fact that VOFoW only applies to tokens that are partially part of the visible area. I.e., it is not implemented in a way that permits tokens anywhere on the map to become visible if they are still totally covered by hard FoW. This seems to be by design, but the implementation has some precision issues. For reference, ZoneRenderer::renderTokens(), lines 3077-3079. This skips rendering of any tokens that are not at least partially visible (this includes regular tokens covered by hard FoW, but also VOFoW tokens totally covered by FoW). This check has precision issues when the boundary of the token lines up exactly with the boundary of the visible area, as in the example campaign. I.e., this logic may or may not skip token rendering in that case depending on whether the intersection check happens succeeds or not.

Then there is the logic to paint VOFoW on top of FoW if needed: lines 3306-3342. Again, the painting is restricted to tokens that are at least partially visible, which has the same precision issues as above. But also there is a region-based check to see if the visibility of the token exceeds the visibiility threshold. This spits a token up into 3x3 regions and checks each region to see if they intersect the visible area. The intersection has the same precision issues as the other intersections, but also introduces some more precision issues when calculating the bounds of each region because it calculates those bounds rather than using them exactly. So even if the bottom boundary of the token was said to intersect with the visible area, the bottom boundary of any of the regions may or may not intersect it. If the threshold check fails, the token is still rendered, but it is clipped to the visible area which is effectively the same as not rendering at all in these corner cases.

And, finally, there is one more thing going on but I don't have a clue what it is. Even if I force those checks to succeed (i.e., consider these VOFoW tokens as needing to be drawn, they still don't get rendered for me precisely when the zoom level is 100% and not at any other zoom levels as far as I can tell. I hope to look into this further later, but I'm out of time for now.

[kwvanderlinde]

Figured out the last bit: the check for visibility tolerance is duplicated when checking whether the clipping region needs to be used (in ZoneRenderer::isTokenInNeedOfClipping(), lines 3747-3752).