Issue 2755 terrain vbl #2976
Merged
Issue 2755 terrain vbl #2976
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is not a feature-complete implementation. It simply treats all VBL as terrain VBL depending on the value of `FogUtil.USE_TERRAIN_VBL`. A full implementation requires some way to distinguish aras of terrain VBL and regular VBL, as well as some way in the GUI to draw each independently of each other. Some implementation details have changed to support this: - `AreaTree.getOceanAt()` always returns an ocean for valid topology, even if the point is within an island. - `VisibleAreaSegment` can either be created from the front side or back side of an `AreaContainer`. Which side gets used depends on whether terrain VBL is in use and whether the point is within a given `AreaContainer`. - `GeometryFactory` instances are shared between `FogUtil` and `VisibleAreaSegment` in order to enforce consistent precision models. This is important as the default precision is far too prone to slight differences between what ought to be equal points. At the same time, we don't want to be too lax or else obviously distinct points can appear the same. We currently use 10e-6 at the precision. - `net.rptools.maptool.client.ui.zone` package had the classes `AreaData`, `AreaMeta`, and `AreaFace`. These are redundant analogues to the classes under `net.rptools.maptool.client.ui.zone.vbl`. They were also unused except in some expository tests, and thus have been removed. The high-level idea of terrain VBL is that vision is able to enter terrain VBL but not leave it. Unlike Foundry, our vision blocking is represented as solid regions of VBL rather than ideal lines acting as wall. Thus, while Foundry terrain walls affect vision based on the number of crossings (1st crossing is allowed, 2nd and higher is blocked), our terrain VBL affects vision by checking whether we are entering or leaving the VBL. This approach even works for line VBL since our lines of VBL are not ideal lines but are 1-unit-wide rectangles. Do not buffer geometry as much as it hurts performance Buffer shadow geometry to make sure it is valid. This seems to fix all other errors meaning we do not need the expensive collection buffer at the end buffer(1) rather than buffer(0) Add timings; try figuring stuff out Try keeping vision as JTS Geometry and convert that back Various tweaks 1. Build shadows into a geometry collection which can be buffered with zero distance. This is the only buffering we do. 2. Only union the buffered geometry collection and nothing else. We don't bother unioning indvidual shadows. 3. Go back to using `Area.subtract()` instead of `Geometry.difference()`. This has less overhead (in small cases at least) and avoid some cases of non-noded line segments. TEMP Needs to be reverted Split out some timers; simplify redundant variables Include notes about future integration of GeometryFixer to avoid buffering: no net gain Renable expose visible area timer Code format Invert conditions so that terrain VBL check is done per-island Move terrain determination to AreaIsland Allow drawing terrain VBL; digest terrain VBL as its own topology tree; note that calculateVisibility() can handle intermixed terrain and non-terrain VBL, but it is more convenient to keep them as separate trees Remove USE_TERRAIN_VBL constant Implement terrain VBL erase; invalidate terrain VBL tree on change; backwards compatibility for zones with no terrain VBL Add missing selection tool Remove stats
… not mitigate the need for the union since the geometry remains all funky. I think it is not ready for primetime
…functions and the GUI to allow for it.
…ead mark the token as terrain or not
…rue, but existing tokens will have it be false
… the Is Terrain? checkbox rather than the value stored in token. This is important as the token is not updated until the dialog is successfully closed
…nsfer the same type of VBL as the token represents
…rameters to control whether is terrain VBL or not
… different numbers of parameters
…s a separate parameter; spotlessApply
… depend on topology mode or VBL type.
kwvanderlinde
force-pushed
the
issue-2755-terrain-vbl
branch
from
664f798
to
aed238c
Compare
|
Merged to branch feature-terrain-vbl for testing. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Implements #2755. Intentionally leaving as a draft for now as there is remaining work to do.
This change implements "terrain VBL", a new kind of VBL that allows vision into but not out of the area. Using terrain VBL allows players to see walls, pillar, landscapes, etc., while still not allowing them to see behind the VBL.
This PR has the following features:
drawVBL(),eraseVBL(),getVBL()) now accept/return both regular and terrain VBL."terrain": 1in the shape JSON."terrain": 0in the shape JSON, or if the"terrain"key is missing.getTokenVBL(),setTokenVBL(),transferVBL()) respect whether the token is a terrain token.transferVBLrespects the rules in (4). So it only operates on terrain VBL if the token is a terrain token. Otherwise, it only operates on regular VBL.setTokenVBL()is given a shape with a"terrain"key, then it will only apply terrain VBL if the token is a terrain token, and will only apply regular VBL if the token is a non-terrain token.This change is