Perspective-Based Visibility Data Selection #3297
Draft
Conversation
This file contains hidden or 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
douira
force-pushed
the
directional-vis-graph
branch
from
b80f3d1 to
3bdf281
Compare
…g when above the world. This was caused by the above-world init adding every section of the top of the world to the queue at once, resulting in some sections being visited too early such that they are not traversed through with all potentially incoming directions but marked as finished.
…R on the direction index propagate symmetry into the number of visibility data sets needed, reduce stack size to 3*16 since paths can no longer fold back in on themselves use symmetry to avoid doing half the work in generating visibility data use bitfield index based neighbor traversal instead of conversion to coordinate triplets in vis graph construction, skip origin directions that are opposite the allowed step directions since they cannot lead to any visibility Remove debug code, undo unnecessary changes, delete unused code Avoid continuing the search if all possible destination faces have already been reached Don't generate full visibility data arrays if they're just the same everywhere Fix crash when initializing air chunks and they have no visibility data Perspective based occlusion culling Improve accuracy of visibility data by not allowing the traversal to go backwards
douira
force-pushed
the
directional-vis-graph
branch
from
3bdf281 to
cc4e254
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Performs the generation of visibility data for a set of 8 perspectives, which each enable a different set of 3 allowed traversal directions through the chunk, and then combines them based on the camera's relative position to each chunk. As a side effect, this also prevents visibility paths through sections that contain opposing step directions from being accepted. Such paths are always invalid since they can never contain a straight view ray.
This implementation has some optimization potential, but I have also not measured the performance of the visibility data generation so I don't know how necessary it is. Feel free to review and suggest (or make) improvements. I'm going to keep this as a draft until we've tested and discussed it more thoroughly.
See discussion of my recent ideas on valid and invalid paths here. This is the implementation of this concept I suggested last year.
In my brief test, this reduced the section count from 4820 to 4512 in a simple overworld scene. More testing of its effectiveness and correctness is required.
A demonstration of how it can cull sections behind this section where no view ray is possible, which was previously not culled. (with all non-air blocks turned "opaque" for visualization)
Prerequisite: #3484