Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Populate chunk margins #41

Closed
Ralith opened this issue Apr 8, 2020 · 5 comments · Fixed by #379
Closed

Populate chunk margins #41

Ralith opened this issue Apr 8, 2020 · 5 comments · Fixed by #379
Labels
enhancement New feature or request performance Something's slower than it should be visuals Something should be prettier

Comments

@Ralith
Copy link
Owner

Ralith commented Apr 8, 2020

Chunk data sent to the GPU is wrapped in a one-voxel margin that should be, but is not currently, populated with the data from neighboring chunks. If supplied, this data would produce correct AO and hidden face detection for voxels on the face of a chunk, improving both visuals and performance.

There are two exceptions:

  • Chunks which are otherwise void do not benefit from having margins set, as they have no faces to hide or occlude. Setting a margin might also interfere with efficient sparse representation of such chunks.
  • Chunk faces which face graph nodes that don't yet exist, i.e. outside of the graph, cannot be populated, as their chunks are sensitive to parameters that have not yet been computed. Fortunately, we can make up whatever values we like for them: a camera within the graph cannot possibly observe any potentially exposed voxel faces along such a chunk face, and ambient occlusion errors will be difficult to see, especially in the presence of distance fog.
@Ralith Ralith added enhancement New feature or request performance Something's slower than it should be visuals Something should be prettier labels Apr 8, 2020
@Ralith
Copy link
Owner Author

Ralith commented Jun 5, 2020

A fix here will likely have a massive benefit to terrain rendering performance, as right now the overwhelming majority of rendered triangles are hidden.

@Ralith Ralith mentioned this issue Jun 7, 2020
@patowen
Copy link
Collaborator

patowen commented Feb 26, 2023

For the second bullet point, as more chunks are generated, surface extraction has to be repeated for chunks with new neighbors. @Ralith, do you have a recommended optimization for this, or should this be figured out by the person who tackles this issue?

@Ralith
Copy link
Owner Author

Ralith commented Feb 26, 2023

Off the cuff, I think it would be reasonable to mark chunks generated with incomplete margins, and regenerate them when new margin data becomes available. We could also just perform no surface extraction for a chunk unless its margins are fully known; that would require more data to be held in memory to achieve a given view distance, but that memory usage might not be the limiting factor anyway.

@patowen
Copy link
Collaborator

patowen commented Feb 26, 2023

That makes a lot of sense. I think the second option would be simpler for an initial implementation, so once we've done some profiling, we should be able to make a better decision here.

@Ralith
Copy link
Owner Author

Ralith commented Jan 18, 2024

mark chunks generated with incomplete margins, and regenerate them when new margin data becomes available

Simpler approach: whenever voxel data for a chunk is first populated, invalidate surface extraction for any previously surface-extracted chunks. The same mechanism can be applied when edits touch a chunk face.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request performance Something's slower than it should be visuals Something should be prettier
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants