simplify: Improve vertex_lock handling in presence of seams #779
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
Previously, we would only read vertex_lock data for the primary vertex (the vertex with the smallest index among those with the same position). When using sparse mode, this would be the first vertex referenced by the index buffer due to how the sparse remap works. If the input locks were inconsistent between all copies, there could be a situation where a vertex with the wrong index was asked to be locked, and the vertex would still be not-locked and could move. When *not* using sparse mode, this was particularly problematic as the flags would be read from the vertex that might not be referenced by the index buffer at all. We now propagate the locked status into the primary vertex in a separate pass; this requires re-locking the wedges in a separate pass, but all of this is very quick especially when using sparse mode.
This test would fail before, specifically lock2 would not lock the spine because it was using the side of the spine with larger vertex indices; after the previous fix lock2 and lock3 are equivalent.
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.
In the previous implementation from #601, we would only read
vertex_lockdata for the primary vertex (the vertex with the smallest index among those
with the same position). When using sparse mode, this would be the first
vertex referenced by the index buffer due to how the sparse remap works.
If the input locks were inconsistent between all copies, there could be
a situation where a vertex with the wrong index was asked to be locked,
and the vertex would still be not-locked and could move. When not
using sparse mode, this was particularly problematic as the flags would
be read from the vertex that might not be referenced by the index buffer
at all.
We now propagate the locked status into the primary vertex in a separate
pass; this requires re-locking the wedges in a separate pass, but all of
this is very quick especially when using sparse mode. Locking any vertex
copy is now thus sufficient to lock the vertex (when using sparse mode,
locking any copy referenced by the index buffer is sufficient; by design,
sparse mode ignores any data from vertices that aren't referenced by
the index buffer).
This contribution is sponsored by Valve.