Add two-way VBL/terrain walls

[adyoungblood]

Is your feature request related to a problem? Please describe. When setting up new maps with Fog of War enabled, I am always forced to choose between obscuring the art of the walls with accurate VBL, or creating VBL that approximates what should be there, while showing as much of the actual walls as possible. Also, I have to put an X across objects such as pillars or tall boxes, which gets the job done, but looks ugly.

Describe the solution you'd like Terrain walls, straight out of Foundry.

Describe alternatives you've considered

• Doing what I've always done (which works, sorta)
• Allowing players to simply see the whole map
• Manually removing the FoW from the walls I wish the players to see (time consuming)

Additional context Let's say I have my test subject Agatha the hag standing in the Yawning Portal, looking towards the bar wall. In the GM view, I can see the wooden wall that blocks her vision. However, in the player view, the wall is simply a fog-colored rectangle: I would rather she (and by extension, my players) be able to see the nice wall art underneath.

Additionally, on a map such as this one it's rather difficult to place VBL that is accurate to the map. but also reveals what's back there (specifically, the place where the outer wall merges with the inner wall).

[emmebi]

A few things which you can try here:

1. use a VBL/MBL in the middle of the wall to block the movement and the line of sight
2. put a VBL on the whole wall, and then reveal it using the Fog of War tool; this requires some effort, but provides some good results.

[adyoungblood]

I've typically gone with the first method, although the second method does seem rather appealing now that you mention it. Nevertheless, I believe that terrain VBL (and perhaps more advanced VBL in general, although that's a separate topic) could be useful to most users.

[adyoungblood]

Well, nevermind. According to Craig's message, the codebase is too tightly coupled with Swing to make this possible. Plus, no one wants to work on the Swing code anyway, least of all me! If anything, this just made me a firm supporter of the web-based client. Closing this issue now.

[rkathey]

In my opinion, this should be reopened. Just because we're not doing it today doesn't mean we're not doing it. :)

[thelsing]

I think so too.

[cwisniew]

I agree

[kwvanderlinde]

I made a proof-of-concept for terrain VBL on this branch. The defining feature of this implementation is that vision can "enter" terrain VBL but can't "leave" it. It is by no means complete as it just treats all VBL as terrain VBL.

A few more things would need to be done to get this fully and properly implemented:

• Storing terrain VBL separately from VBL.
• A GUI method for drawing terrain VBL separately from VBL.
• New macro functions for drawing terrain VBL like the ones for drawing regular VBL.
• Implementing token terrain VBL, if that is desired.
• Merging terrain VBL with VBL during pathfinding, for when AI is configured to pathfind around VBL.
• ... ?

I also haven't spent any time optimizing the implementation, so performance isn't great in some situations. But it is plenty usable in simple cases.

[cwisniew]

I made a proof-of-concept for terrain VBL on this branch. The defining feature of this implementation is that vision can "enter" terrain VBL but can't "leave" it. It is by no means complete as it just treats all VBL as terrain VBL.

Welcome to the Hotel California...

A few more things would need to be done to get this fully and properly implemented:

• Storing terrain VBL separately from VBL.
• A GUI method for drawing terrain VBL separately from VBL.

This is where being able to select VBL and modify its attributes would come in handy as well, but that is probably more of a pipe dream for phase 2 or 3 of this. But if you are looking at storing these VBL types separately and need to make some changes to how its stored then its worth keeping this in mind.

• New macro functions for drawing terrain VBL like the ones for drawing regular VBL.

Since the VBL macro functions accept their arguments as a "JSON" string it will be easy enough to add this as a parameter so new functions would not needed.

• Implementing token terrain VBL, if that is desired.

I think that it would be desired as that would allow people to see more of the token doing the blocking. It would probably make sense for token VBL to be this new see into but not out of type by default too. Although I that can wait as its worth getting the rest in even without that as a first step.

• Merging terrain VBL with VBL during pathfinding, for when AI is configured to pathfind around VBL.
• ... ?

I also haven't spent any time optimizing the implementation, so performance isn't great in some situations. But it is plenty usable in simple cases.

What sorts of situations does performance suffer?

[kwvanderlinde]

Here is an example I simpified: 2755-simple-slowdown (copy).rpmap.zip

On 1.9.3, dragging and dropping the token anywhere is a snappy operation. But on my feature branch there is a noticable though small delay when dropping. I'm also now realizing the delay is there whether or not I have terrain VBL enabled, so this is probably just due to some poor handling of geometry on my part.

[kwvanderlinde]

I've udpated the toolbar with a toggle for terrain VBL vs regular VBL. The icons are reused from another toggle as creating new icons is beyond my skill set.

Terrain VBL is stored separately from regular VBL and has its own associated topology trees used for FoW calculations. Each island in the topology tree also stores a flag for whether it is terrain VBL or regular VBL, and FogUtil uses this flag to determine its behaviour. This way, if we somehow change it to a single topology tree for both kinds of VBL, FogUtil will continue to work with minimal changes to calculateVisibility()

I also spent some time on performance and found that I was using JTS quite suboptimally. That's been fixed, thankfully wasn't too hard. Next steps are updating the VBL functions, adding token terrain VBL, and updating pathfinding to account for terrain VBL.

Here's what it looks like right now. There's the new toggle button. When selected, terrain VBL can be drawn and erased: Terrain VBL is cyan to distinguish it from the blue VBL: Vision enters the terrain VBL but not the regular VBL. Note the white border is at the back of the terrain VBL but at the front the regular VBL: Both types of VBL can overlap: In this case, regular VBL effectively takes precedence since it always blocks vision:

[kwvanderlinde]

My first take on token terrain VBL is implemented. I decided to have tokens only have either regular VBL or terrain VBL. Or rather, that the token itself should either count or not count as terrain when it comes to VBL. New tokens will default to being terrain, while existing tokens (including existing imports) will not be counted as terrain. This is controlled by a checkbox in the VBL tab of the Edit Token dialog. If this is undesirable, I can separate regular VBL from terrain VBL at the cost of some more code duplication.

And for a showcase, here's a simple room with a pillar and a rock acting as terrain. Please mentally fill in something fancier.

Macro functions for token and non-token terrain VBL are yet to come. If anyone wants to try it out, my feature branch is up-to-date with everything I've showcased so far.

[kwvanderlinde]

Support for terrain VBL has been added to macro functions now. And with that, I think it is complete in terms of functionality, though there are still some loose ends to take care of.

I've opened a draft PR for some better visibility into the changes and to accept some early feedback. There are a few specific questions I have at this point:

1. Is there a better name than "terrain VBL"?
   • I like the term itself, especially for users familiar with Foundry's terrain walls, but it could potentially be mixed up with other things.
   • From a user perspective, it may be that it is mixed up with terrain modifiers as found on tokens. Especially if talking about terrain token VBL.
   • In the code, MBL is often called "terrain topology". Using "terrain VBL" may be a source of confusion and be a maintenance burden.
2. Is there a better interface for drawing/erasing terrain VBL vs regular VBL?
   • Considering that terrain VBL is basically a third independent kind of topology, maybe it makes sense to incorporate it into the existing selector somehow? Might be a little unweildy as there would be five states (MBL only, MBL/VBL, MBL/terrain VBL, VBL, terrain VBL).
   • Perhaps we could go the other way and split the topology mode toggle into one selector for VBL (off/regular/terrain) and another one for MBL (off/on)?
3. Any desire for tokens to carry both regular and terrain VBL at the same time?
   • Implication of supporting both would be that token could not be categorized as terrain tokens or a non-terrain token, but all tokens can have either kind of topology.
   • Personally I don't see a need for this, but I'm open to being disagreed with :smile:
4. (relates to question 3) Is it good to handle VBL transfers as described in feature (4)? I.e, the token must match the type of VBL being transferred to/from the map.

[kwvanderlinde]

I've managed to answer some of my own questions after actually trying to use the features for a while.

1. Still an open question.
2. Having a separate selector for terrain vs regular VBL is not very enjoyable. For now I've instead added to the existing VBL/MBL selector so it also now supports terrain VBL and combined MBL/terrain VBL.
3. Yes. E.g., for a background token that represents an entire building, or floor of a building, it would be useful to have all kinds of topology. Relates to #2730.
   • This could involve more serious GUI changes in addition to storage of multiple topologies on tokens.
4. Basically answered by (3). If we treat terrain VBL and VBL and entirely distinct topologies, each will have its own option for transfers independent of the others.

[cwisniew]

I've managed to answer some of my own questions after actually trying to use the features for a while.

1. Still an open question.

I think it needs a better name as when I read "Terrain VBL" I am certainly not thinking about using it for nice walls/doors as newish user... But I am not sure what name "see into VBL" sounds even more terrible. One Way VBL? Single Direction VBL?

2. Having a separate selector for terrain vs regular VBL is not very enjoyable. For now I've instead added to the existing VBL/MBL selector so it also now supports terrain VBL and combined MBL/terrain VBL.

It sounds like that is probably the best way of doing it as it sounds like it would be less painful to jump between the two

3. Yes. E.g., for a background token that represents an entire building, or floor of a building, it would be useful to have all kinds of topology. Relates to Allow tokens to carry MBL, like they can with VBL. #2730.

   • This could involve more serious GUI changes in addition to storage of multiple topologies on tokens.
4. Basically answered by (3). If we treat terrain VBL and VBL and entirely distinct topologies, each will have its own option for transfers independent of the others.

[kwvanderlinde]

I think it needs a better name as when I read "Terrain VBL" I am certainly not thinking about using it for nice walls/doors as newish user... But I am not sure what name "see into VBL" sounds even more terrible. One Way VBL? Single Direction VBL?

Not walls/doors, but perhaps pillars and other obstacles. Which is really what it is for. There are real downsides to using terrain VBL for walls (at least interior walls) as players can see down the entire length of any such wall. VBL generally remains the best tool for interior walls.

Here's my attempt at brainstorming some other names:

• semi VBL
• permissive VBL
• posterior VBL
• partial VBL
• penetrating VBL
• passive VBL
• viewable VBL
• transparent VBL
• revealing VBL
• perceivable VBL
• examinable VBL

I'm kind of partial to something like "perceivable VBL", but not sure how to make that sound more natural.

[Azhrei]

I'm partial to "One Way VBL", as it's the most descriptive (although not really accurate, since if you're on the other side of it, you can see out — it's not really "one way" in that regard. (Unless you think driving the wrong way on a one way street is okay because you're only going "one way". 😉)

I'm also a little concerned about picking a name that implies how it should be used. For example, 1WVBL is no good for a large hill. As you point out, it's really for smaller objects, such as pillars, columns, or items in which the GM wants the players to see the great art work involved, but which should otherwise be considered solid.

I'm also wondering about tokens placed next to 1WVBL — can the artwork of the token pierce the solid VBL? If so, a player could see into a pillar and tell there's another token on the other side.

[kwvanderlinde]

I'm also wondering about tokens placed next to 1WVBL — can the artwork of the token pierce the solid VBL? If so, a player could see into a pillar and tell there's another token on the other side.

Yes it can: . But I don't see this as really any different than piercing a thin VBL wall:

[FullBleed]

I can't believe this feature is sneaking in under the radar... this has been desired for a very long time!

Perhaps we could go the other way and split the topology mode toggle into one selector for VBL (off/regular/terrain) and another one for MBL (off/on)?

I personally quite dislike the selector as it is now... and adding more toggle states to it makes me cringe. I actually like the above suggestion since MBL isn't vision related at all. It is its own thing and I think it should be treated as such.

I'm actually cool with Terrain VBL, but it's not entirely accurate (I just don't see characters and monsters as being "terrain".)

1-way/2-way VBL, brings up syntax debates. i.e. :

A one-way mirror, also called two-way mirror (or one-way glass, half-silvered mirror, and semi-transparent mirror), is a reciprocal mirror that appears reflective on one side and transparent at the other.

Reciprocal VBL seems too technical.

But I think "Hollow VBL" is decent. As in having the VBL toggle be : Off/Solid/Hollow.

[Phergus]

Merged PR #2976 into feature branch feature-terrain-vbl.

Running from the branch and I don't see the new toggle button. Haven't investigated further.

[kwvanderlinde]

Merged PR #2976 into feature branch feature-terrain-vbl.

Running from the branch and I don't see the new toggle button. Haven't investigated further.

I've changed it to use the existing VBL/MBL toggle. So it's now a 5-state instead of 3-state button.

[Phergus]

Okay. I see. Was kind of expecting to use unfilled polygons for defining the terrain VBL areas but given that the auto-generated Token vbl uses solid VBL I guess it's better to be consistent.

As the Is Visible over FoW and Visibility Tolerance setting are related it's odd to see Is Terrain checkbox in between them. Especially as the Is Terrain checkbox is indented which would normally indicate that it is dependent on Is Visible over FoW. Maybe put it after the Visibility Tolerance?

[FullBleed]

Man, a five toggle state is going to be pretty annoying. I can hardly distinguish between the 3 as is.

And since it looks like there isn't enough support for breaking out MBL, why don't we just put all 5 states on the bar and only allow one to be active at a time (like the shapes)? There is plenty of room for that.

[kwvanderlinde]

Okay. I see. Was kind of expecting to use unfilled polygons for defining the terrain VBL areas but given that the auto-generated Token vbl uses solid VBL I guess it's better to be consistent.

Way back I actually envisioned a similar thing, but found it tricky to think through the implementation, which is why I implemented it the way that I did. But in the process of implementing it, I've also discoved all sorts of ambiguities which makes me think it wouldn't be feasible to define terrain VBL in terms of thin boundaries. This is just a side effect of representing topology as solid areas rather than ideal thin walls.

As the Is Visible over FoW and Visibility Tolerance setting are related it's odd to see Is Terrain checkbox in between them. Especially as the Is Terrain checkbox is indented which would normally indicate that it is dependent on Is Visible over FoW. Maybe put it after the Visibility Tolerance?

A couple notes on this:

1. I agree that this is an odd placement (actually, I fully admit it's pretty terrible). But I don't expect this checkbox to survive to the final product anyways. As I mentioned up in my answers to my own questions, it can be advantageous for stamps to carry both terrain VBL and regular VBL (in addition to MBL once implemented). So flagging a token as either terrain or not terrain isn't the way to go. I think what this UI actually needs is a toggle of some sort, similar to the main toolbar, that controls whether the user is manipulating the token's VBL, terrain VBL, or MBL at any given time.
2. It seems to me the "Token Visibility" section doesn't really belong in the VBL tab. I envision it moving elsewhere (perhaps the Config tab). Then the VBL tab would be renamed to something more generic and would be dedicated to manipulating token VBL/terrain VBL/MBL.

Man, a five toggle state is going to be pretty annoying. I can hardly distinguish between the 3 as is.

I should be clear about this: I am absolutely terrible at UI stuff. So all such changes I have made are solely about getting a working prototype that allowed me to experiment with the implementation. It's certainly not because I think the UI should actually be this way. The 5-state toggle is a prime example (though it's better than the original interface I made :smile:) It only exists right now to reflect the current implementation.

And since it looks like there isn't enough support for breaking out MBL, why don't we just put all 5 states on the bar and only allow one to be active at a time (like the shapes)? There is plenty of room for that.

I am actually in favour for breaking out the MBL selector from the VBL selector. So a 3-state VBL toggle and a 2-state MBL toggle. Radio buttons like you suggest also sound fine to me, though I would be more sold on the idea if we had higher-level names for topologies with corresponding icons (e.g., "walls", "windows", etc). To be clear, I'm not suggesting a change in terminology, just pointing out my opinion on the radio buttons. Regardless, if we end up with multiple controls for selecting the topology type, I think we should also visually distinguish this group of controls somehow from the group of shape selectors.

[Phergus]

As I mentioned up in my answers to my own questions, it can be advantageous for stamps to carry both terrain VBL and regular VBL (in addition to MBL once implemented). So flagging a token as either terrain or not terrain isn't the way to go. I think what this UI actually needs is a toggle of some sort, similar to the main toolbar, that controls whether the user is manipulating the token's VBL, terrain VBL, or MBL at any given time.

The Token VBL tab definitely needs to have a better method of selecting the VBL mode.

I'm not seeing a use for having both VBL and Terrain VBL on a token. What's the use case you have in mind?

In the case of objects on a map, Terrain VBL pretty much serves the same purpose as the existing Token VBL plus VoFoW. Here's the player view. One rock has regular VBL and the other terrain VBL.

And this is the GM view of it.

The lower troll has a weird slice out of it. It makes sense when you think about it but is visually jarring. The upper troll is just hidden behind the rock (VBL + VoFoW) which matches the GM view.

re: UI for selecting topology mode

Something better is needed but I'm not sure where to go with it. Radio buttons perhaps. Or just 3 buttons to enable VBL, MBL, and TVBL individually. My thinking is that the VBL & TVBL buttons would be mutually exclusive. You would be in one mode or the other but not both. MBL would be optionally enabled along with the others or by itself.

[Azhrei]

Something better is needed but I'm not sure where to go with it. Radio buttons perhaps. Or just 3 buttons to enable VBL, MBL, and TVBL individually. My thinking is that the VBL & TVBL buttons would be mutually exclusive. You would be in one mode or the other but not both. MBL would be optionally enabled along with the others or by itself.

A common approach for something like this, particularly where the UI needs to remain fluid, is to use a drop down list. The amount of space required (and the look of the UI) is consistent even as new elements are added to the list in the future.

I don’t know if individual entries can have their own tooltips to explain them, however.

[Phergus]

A drop-down would be better than a 5-state button and has the added benefit of being somewhat self-documenting instead of trying to guess what the symbols mean.

I don’t know if individual entries can have their own tooltips to explain them, however.

Would probably end up being confusing if it did.

[Azhrei]

A drop-down would be better than a 5-state button and has the added benefit of being somewhat self-documenting instead of trying to guess what the symbols mean.

If you expect additional changes later and want to keep the fields organized, then multiple drop downs (VBL, MBL, TVBL) are also an option. (However, when the mutually exclusive combinations get tricky, a single drop down is the way to go.)

[kwvanderlinde]

I'm not seeing a use for having both VBL and Terrain VBL on a token. What's the use case you have in mind?

An existing map used as a background token. Interior walls would be marked as VBL while statues, pillars and such would be terrain VBL. This could also be done by setting the map's image and using map VBL/terrain VBL, but there are cases where a token is better.

[FullBleed]

I should be clear about this: I am absolutely terrible at UI stuff. So all such changes I have made are solely about getting a working prototype that allowed me to experiment with the implementation. It's certainly not because I think the UI should actually be this way. The 5-state toggle is a prime example (though it's better than the original interface I made 😄) It only exists right now to reflect the current implementation.

Gotcha. I just wanted to voice an opinion before something went in and then stuck around for a couple years. ;)

We really need to find some people who are more comfortable with working on the UI side of things so you back-end guys don't need to bother with it. I know I don't want you pulling your hair out over UI stuff when you can be creating features like this! Maybe we can get an Announcement put up enlisting UI specific coders? @wolph42 I know that there are a number of graphic designers that just need prompting to produce icons...

I am actually in favour for breaking out the MBL selector from the VBL selector. So a 3-state VBL toggle and a 2-state MBL toggle. Radio buttons like you suggest also sound fine to me, though I would be more sold on the idea if we had higher-level names for topologies with corresponding icons (e.g., "walls", "windows", etc).

I think this is a really good idea. The terminology is less important to most users than knowing what to use with particular elements they are trying to add to their maps.

I think we should also visually distinguish this group of controls somehow from the group of shape selectors.

Absolutely. Separators are usually good enough but there is no reason we can't use color to differentiate, too.

[FullBleed]

A common approach for something like this, particularly where the UI needs to remain fluid, is to use a drop down list. The amount of space required (and the look of the UI) is consistent even as new elements are added to the list in the future.

Not pushing back on this (since I can't say that I've studied this specific thing outside an psychology based ergonomics class way back when)... but why is a drop-down preferred? It requires clicking to open the drop down, visually scanning for selection (potential vertical scroll), and then selecting choice. If space was a concern I'd see the merits... But it seems to me that newer, UI's tend to go with "prettier" selection methods. Drop-downs just seem so... utilitarian. The appeal favors people who process text information (whereas a great number of people prefer visual/graphic processing... i.e. a pie chart over a paragraph of data.)

[adyoungblood]

The lower troll has a weird slice out of it. It makes sense when you think about it but is visually jarring. The upper troll is just hidden behind the rock (VBL + VoFoW) which matches the GM view.

One idea I had for this problem (which I also found unintuitive) would be to expose vision inside terrain VBL as if it were in soft fog, i.e. the player can see the terrain but not any tokens inside of it. There could be an issue when trying see a token stamped with terrain VBL, as the token may not be visible in soft fog.

[FullBleed]

The lower troll has a weird slice out of it. It makes sense when you think about it but is visually jarring. The upper troll is just hidden behind the rock (VBL + VoFoW) which matches the GM view.

What if the z level draw of objects with Terrain VBL were drawn based on distance so that the closest object was always drawn over those behind?

[FullBleed]

Sorry to spam the thread... but I thought of something else that I think should be seriously considered.

The background color of the buttons relating to the different types of blocking (and combined blocking options) should match the color of the blocking. That will help people to understand what they are seeing more quickly.

And I know this might be a FREQ, but being able to set those colors ourselves might be very useful... I don't know how safe the current choices are for color blind people.

[Azhrei]

A common approach for something like this, particularly where the UI needs to remain fluid, is to use a drop down list. The amount of space required (and the look of the UI) is consistent even as new elements are added to the list in the future.

[...] why is a drop-down preferred? It requires clicking to open the drop down, visually scanning for selection (potential vertical scroll), and then selecting choice. If space was a concern I'd see the merits...

It has essentially the same number of clicks as a menu option, but because it's in the toolbar, it's visually highlighted. (I would hope we'd have menu options for these as well, although we don't currently.)

There won't be any scrolling needed (the list isn't long enough).

The main advantage is that should the list change (items added or removed), the visual layout stays the same. That may not be important, but there's a lot of value to have components be consistently placed. If radiobuttons or the like is used, adding or removing entries will cause other parts of the UI to move. If that's not acceptable, then a drop down might be a good choice.

Drop downs also make it pretty clear which option is currently selected, particularly when there are a lot of options (doesn't apply right now). Other advantages don't really apply in this instance (like typing into the drop down and having it jump to the entry that has matching text).

[...] But it seems to me that newer, UI's tend to go with "prettier" selection methods. Drop-downs just seem so... utilitarian. The appeal favors people who process text information (whereas a great number of people prefer visual/graphic processing... i.e. a pie chart over a paragraph of data.)

There's no reason a drop down item cannot contain both an image and text, btw.

Honestly, either drop down(s) or radiobuttons would work fine.

[Phergus]

An existing map used as a background token. Interior walls would be marked as VBL while statues, pillars and such would be terrain VBL. This could also be done by setting the map's image and using map VBL/terrain VBL, but there are cases where a token is better.

As we currently can't put mixed topology types on a background stamp the point is somewhat moot but I'm guessing that one use would be if the structure portrayed by the map could change dynamically and so you would be swapping back and forth between the different forms. That has implications for the exposed/unexposed FoW tracking.

[Phergus]

What if the z level draw of objects with Terrain VBL were drawn based on distance so that the closest object was always drawn over those behind?

Well in the example given it wouldn't matter as the rock is on the Object layer while the Troll token is on the Token layer. Because the one rock is designated as VoFoW it is actually rendered above the token layer and thus the top troll. Beyond that if a rug object was closer to the viewer than a table object that sat on one end you wouldn't want the rug being automatically put on top.

[FullBleed]

Not sure I follow, why would a rug have terrain VBL on it?

I thought the problem was that with the rock and troll both having terrain VBL on it, MT defaulted to normal z order rendering and showed the troll token over the rock even though it was "behind" the rock. If two objects (regardless of layer) both have terrain vbl, rendering the closest one over the others would seem to fix most of the issues of something being behind a terrain vbl object/token.

[Phergus]

Only the southern rock has terrain VBL and none of the troll tokens have VBL of any kind.

[FullBleed]

Ok, not sure if we're talking past one another because I'm just back to my original suggestion: What if the z level draw of objects with Terrain VBL were drawn based on distance so that the closest object was always drawn over those behind?

And by "objects" I mean anything on the object layer or token layer with terrain vbl.

In the bottom rock troll combo:

• Can we agree that the rock should be rendered over the troll because it is in front of it and terrain VBL is designed to render the object and block what is behind said object?
• Can we agree that the above condition is failing because the current z-order methodology (be it layer order or order of object on map) does not realize that the rock is "in front" of the troll?
• Leading to the conclusion that in order for it to be rendered properly, MT needs to render closer terrain VBL object over objects that are further away.

Otherwise... it seems to me that we're going to see a lot of the above scenarios with objects behind terrain vbl objects being partially rendered above them.

[kwvanderlinde]

The problem with any z-order solution is that it's specific to token terrain VBL. One of the alluring aspects of terrain VBL is that one can draw it on a pre-rendered map that has terrain in it, without needing to cut the terrain out into tokens. So imagine that same situation with the troll, but where the rock is part of the map instead of being a token, and has map terrain VBL drawn over it. It's the same oddities, but z-order isn't going to help us there.

I quite like @adyoungblood's suggestion to treat this like soft fog (though ideally without the shading). Nice thing about soft fog is that Background and Object tokens remain visible, while Token tokens are hidden based on current vision. I'm not so concerned about revealing Token tokens that carry terrain VBL as this case seems more niche to me and can be done similarly using VoFoW.

[Phergus]

* Can we agree that the rock should be rendered over the troll because it is in front of it and _terrain VBL is designed to render the object and block what is behind said object_?

I believe that is overstating the intent. My understanding is that Terrain VBL is meant to allow visibility into the area enclosed by it and to stop vision at the "far" edges of the TVBL area. The hiding of objects that are partially behind a Terrain VBL area was not part of the design. That a token with regular VBL on it and set as VoFoW hides a token partially behind it is more of a happy accident than intentional design.

* Can we agree that the above condition is failing because the current z-order methodology (be it layer order or order of object on map) does not realize that the rock is "in front" of the troll?

Not really. As he said above, that could only apply for tokens with TVBL and even then what if the token behind it was a 20' tall giant or a 3' tall halfling? Do both get hidden? MT doesn't know the height of tokens.

In any case, it's easy enough to get the same situation as seen in that example using regular VBL when you are just using X's to put VBL on baked in pillars and the like on maps.

[FullBleed]

Not really. As he said above, that could only apply for tokens with TVBL and even then what if the token behind it was a 20' tall giant or a 3' tall halfling? Do both get hidden? MT doesn't know the height of tokens.

Height is a completely separate issue so I don't know why you'd even bring it up. We'd have to use this in a way that does not entertain or factor in height just like we do regular VBL. If a rock is to show itself but block what's behind it put tvbl on it, if it's not, don't. The question is what happens when a monster token comes up to the object and shows "through" it... that breaks the whole point of putting tvbl on the object in most cases (so I guess the advice will be, "Don't do that.")

At any rate, I'll gladly just use this on the background and not on tokens. I almost never use token objects like columns, trees, and rocks anyway (probably because I don't do much improvisational map building)... and this behaviour will only reinforce that choice.

[adyoungblood]

When I wrote the FREQ, I hadn't even considered putting terrain VBL on tokens, which is why I suggested soft fog style rendering (without the shading, for sure).

Z-ordering is a good choice for rendering, although it could potentially become rather unintuitive to users without much benefit (an invisible boundary of over vs under, for one). It would certainly solve the issues/edge cases brought up in this thread. Though as a solution, soft fog vision would (hopefully) be easier to implement as well as more intuitive to use.

[FullBleed]

When I wrote the FREQ, I hadn't even considered putting terrain VBL on tokens,

I suppose I hadn't either since I use very few objects... but having prepared objects with the tvbl already applied does have an appeal for improvisational and piece-meal map building.

I also figured doors would be a good use-case for tvbl. Now doors tend to be cut in half by the vbl I apply, which means that people only see half of a door depending on which side they are standing. Putting tvbl on them would mean we could show the entire door... but not if a token behind the door could be overlapping it because MT doesn't know that the door is in front of the token.

[Phergus]

Moving this to 1.11 for more user feedback and evaluation. A alpha/test build will be put out for that purpose after the release of 1.10.

[kwvanderlinde]

I've altered the 5-state toggle button into a group of 5 toggle buttons, and the experience has so far been quite nice. I think that's the way to go for the toolbar.

I'm also thinking that it may make sense to split things up at this point into a few separate feature requests with their own discussions:

1. Map TVBL. This was the original feature request here. Requires minimal GUI changes, and is basically ready to go. Just need to settle on a good name for Terrain VBL. Getting this in would put TVBL at the same level of support as MBL is right now.
2. Token TVBL. The backend code is relatively easy, but the Edit Token dialog UI could use an expert's touch. I'm really not the person to try guess a good layout for things. This could be combined/associated with #2730 since token MBL would require similar UI changes, and would mean VBL/TVBL/MBL all have the same level of support.
3. Obscuring tokens that overlap with TVBL. I haven't done any work on this yet, but I do see the value in not having creature tokens poking into terrain.

If it sounds agreeable, I can pare down the existing changes to just implement map TVBL and then open new issues for the other features.

[adyoungblood]

Sounds good. Each item in your list should definitely have their own (GitHub) issues for discussion, and I know my D&D group would love to see the basics of TVBL as soon as possible.

[kwvanderlinde]

I've created two new feature requests:

• 3052

• 3053

[melek]

I'm extremely excited about these changes.

More than ever, as we add blocking layer types the onerous issue of the non-accessible blocking layer colors is rearing its head.

Right now, we have:

• VBL - Blue
• MBL - Pink
• VBL + MBL - Purple
• Object VBL - Yellow
• Object VBL + All the above VBL/MBL combinations - Indiscernable messiness

I think that two changes can be considered for sanity when editing/viewing these layers:

1. Players need to customize these colors, maybe even use patterns to differentiate them. This is really important for our colorblind community members. Existing request: #1623
2. A way to select which VBL/MBL is visible. Maybe a toggle board like the one you're designing for this feature would work, I'm not sure yet. No feature request yet, wanted to throw it out there before charging ahead with yet another FReq.

Generalizing the display for these also helps these feature scale and may work towards a more generic/configurable blocking layer system down the road if we ever want that.

[Phergus]

Going back to the original post there were two basic complaints:

1. Covering walls with VBL meant that the art of the walls could not be seen by the players
2. Using Xs on pillars or similar areas of a map is ugly.

One-way (or Terrain) VBL can address both of these but also adds some more complications and visual artifacts to the mix as can be seen in the discussion above about the troll behind the rock. As currently implemented you can also get situations like this:

A simple keep (click for fullsize):

The Mystic's view.

While the walls are now revealed in all their glory to the player there is too much revealed as the player can see details of walls in surrounding rooms that they would not be aware of.

Likewise the Hero walking down the outside can now see extra details. If this map had been created with walls of a more appropriate thickness even more details would have been revealed that shouldn't have been.

This can be mitigated by adding regular VBL to problem areas but that adds more complexity to the map preparation process.

Compare to more typical VBL usage on the same map:

The individual player views no longer reveal details about interior parts of the building that aren't in direct view while still showing the relevant details of walls that are visible to the tokens.

Using one-way VBL on areas of maps where vision-blocking elements like pillars are baked into the image makes sense as does putting it on tokens as alternative to using VoFoW + VBL. It may not make sense as a general replacement for regular VBL.