Shape issue when line is facing "wrong way"

[Forecaster]

https://i.imgur.com/h1JKu30.png

This no doubt happens because FG determines that the "inside" of the line is facing the token, thus it should block sight as if it was in the rear of the shape.

I don't suppose there's a way to avoid it looking like this except making the shape less complicated?

[notrealdan]

I don't think the lines have specific faces, like "inside" and "outside" faces. I think it's simpler logic where (for terrain) one line can be seen through, but a second line cannot. Same result, however.

[Kelrugem]

I don't think the lines have specific faces, like "inside" and "outside" faces. I think it's simpler logic where (for terrain) one line can be seen through, but a second line cannot. Same result, however.

I don't think so, you can see the difference to the "second line blocks vision approach" when a token is inside a terrain: Then the corresponding terrain lines are never blocking any sight regardless of their shape, even when the shape is so meandering as in the image :) when the "second line blocks vision approach" would be true then one should see a blocking of vision by the terrain lines even when standing inside of it, but this does not happen :) but I am only guessing, stainding outside of the terrain indeed works as you say, but I do not know the code. Maybe it is as you say (in sense of coding) and when a token stands inside then the terrain acts for this token as if the terrain would be open for that token :) (But to do this stuff for tokens standing inside the terrain there has to be some definition of "inside" in the code, maybe by looking at the intersection with the area of the terrain? not sure :D)

[Moon Wizard]

LOS crossing the second line within the same blocker on door/terrain does indeed block visibility by design. Basically, a terrain block is something that you can see into, but not out of. So, when the LOS ray crosses the second line leaving the terrain, it blocks LOS. It might work better to break terrain that big into regions, or "smooth out" the exterior LOS, so this doesn't happen.

I'm not sure that this is a problem, per se; as a limit of what you can do with LOS logic.

Regards,
JPG

[pollux]

Moon: Have you folks considered (in the future, post FGU general availability) adding z-indices to terrain and tokens in order to represent height?


Tokens could default to a z-index of 0, representing the lowest ground level on the map. The z-index of each token would be assignable to represent flight... in the combat tracker maybe?
Terrain could default to a z-index of 1, representing maybe 10'. The z-index would be assignable in the terrain editor to allow other terrain heights.
Terrain with a z-index <= to the token casting the visibility rays would be transparent.
Terrain with a z-index > to the token casting the visibility rays would be fully opaque, like a wall. No need for tracking rays across two terrain lines anymore.
When a token steps onto terrain, the token's z-index is automatically set to the z-index of the terrain (or maybe the tokens z-index changes only if the token was previously "on the ground"... aka the token's z-index was zero or equal to the z-index of the terrain that the token was leaving).
This could even allow to cast visibility rays in a limited 3d, so that looking down off the edge of terrain naturally casts a visibility "shadow" in which another token can hide, and which depends on the angle of the viewer. Maybe that gets to be a bit much as it would probably require accounting for token height and so for every token to have a height in the first place.


This introduces the z-index as an additional UI concept, which is a drag... but it seems like it solves A LOT of weird edge-cases with the current terrain model in a way that's purely additive a user-interface perspective. All the current stuff people are making will continue to work pretty much as they expect it to in most cases with terrain getting a z-index of 1 by default. But by creating the UX to assign z-indices, all sorts of more demanding terrain topologies can be represented that are somewhere between confusing and impossible with the current 2-traversal model.

This proposal tracks pretty closely with how maps in the original Doom engine faked 3D using 2D maps and I think even 2D collision modeling... but with z-indexes causing to render sections of that 2D map at different heights.

[Forecaster]

LOS crossing the second line within the same blocker on door/terrain does indeed block visibility by design. Basically, a terrain block is something that you can see into, but not out of. So, when the LOS ray crosses the second line leaving the terrain, it blocks LOS. It might work better to break terrain that big into regions, or "smooth out" the exterior LOS, so this doesn't happen.

I'm not sure that this is a problem, per se; as a limit of what you can do with LOS logic.

Regards,
JPG

I appreciate that it's not a major issue, but it does look kind of bad when this happens, and unless you have an even shape that doesn't fold in on itself this is going to happen at certain angles, but maybe it would be possible to make it so when the "shadow" attempts to pass into the same shape it could be blocked by the next "outside"?

See the line marked red in this segment of the previous image:
https://i.imgur.com/bxsh8Vf.png

It would be nice to not have to create multiple shapes, but it'll probably work as a workaround.

[ddavison]

Thanks Forecaster.

This isn't really the intended use of the Terrain feature at this time. The LOS for terrain features works best for areas where you can only see a limited amount of the way into an area or in cases where we want to reveal the entire contents of an area while blocking the vision beyond it. We will have lots of examples in finished products you can reference that show Best Practices for the application of terrain. If you haven't checked it yet, we also have some tips and suggestions on the Map Line of Sight Style Guide. We will expand upon this over time to provide more examples.

In your particular example, it will only ever be abstract. By breaking that area up into multiple terrain pieces, it would be possible for you to simulate it where someone on the SE corner wouldn't be able to see clear across to the NW corner of the forest. I would also recommend making the areas so that they didn't have any inward angles.

https://fantasygroundsunity.atlassian.net/wiki/spaces/FGU/pages/327681/Map+Line+of+Sight+Style+Guide

[Forecaster]

I hate the "create multiple shapes" idea. That's just more work for a worse solution. I'd much rather just create a smoother oval shape covering the forest instead as a workaround. But if sometime in the future it's made smarter as to not cast shadows on itself that would be ideal.

And I do "want to reveal the entire contents of the area while blocking vision beyond it".

[ddavison]

It's possible we might come up with alternate types of occluders in the future that behave differently, but it's probably going to work in this same fashion for the foreseeable future. A different style blocker would likely be a new type entirely.

I kind of like the idea of a type of polygon with a different peek-through amount. If you play any tabletop miniature war games, it is not uncommon to have a 2" or 3" vision into or out of terrain, for instance.