-
Notifications
You must be signed in to change notification settings - Fork 20
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
Implement accurate margins between adjacent chunks #379
Conversation
I don't believe the CI failure is related to this PR. I'm willing to look into it a bit more closely, but the PR should still be ready to review as-is. |
I ran some very crude benchmarks, and it seems like any performance costs for margin computation is likely insignificant enough that we don't need to put much effort into optimizing it for now. I added a few extra temporary metrics to add an additional crude benefit to measure the performance of the code in --- a/client/src/graphics/voxels/mod.rs
+++ b/client/src/graphics/voxels/mod.rs
@@ -99,9 +99,14 @@ impl Voxels {
for chunk in frame.drawn.drain(..) {
self.states.peek_mut(chunk).refcount -= 1;
}
+ let populate_chunks_started = Instant::now();
+ let mut num_chunks_populated = 0;
while let Some(chunk) = self.worldgen.poll() {
+ num_chunks_populated += 1;
+ let populate_chunk_started = Instant::now();
let chunk_id = ChunkId::new(chunk.node, chunk.chunk);
sim.graph.populate_chunk(chunk_id, chunk.voxels, false);
+ metrics::histogram!("populate_chunk").record(populate_chunk_started.elapsed());
// Now that the block is populated, we can apply any pending block updates the server
// provided that the client couldn't apply.
@@ -112,6 +117,9 @@ impl Voxels {
}
}
}
+ if num_chunks_populated != 0 {
+ metrics::histogram!("populate_chunks").record(populate_chunks_started.elapsed());
+ }
// Determine what to load/render
let view = sim.view(); With a view distance of 90, where I load up the game with On
On
To make this easier to read, here's the same thing but with numbers reduced to 2 significant figures and
I'm not sure how much faith can be put in these numbers, as the benchmarks I ran were very crude, likely also depending on difficult-to-reproduce factors like route taken, speed, etc. As margins are things that ought to have been done, I think this level of benchmarking is probably fine for this PR, but when we start actually working on optimizing the game, it would definitely be worth reworking how we measure performance. EDIT: I'm also not sure if we can appreciably increase render distance until #52 is completed. To figure out the extent of performance left on the table, one option would be to generate a certain range of terrain offline, send it all to the GPU (probably still separated by chunks), and see how fast it is. I'm not sure if we're at the stage yet to optimize this much, though. |
I looked into the CI failure, and I believe the root cause is rust-lang/jobserver-rs#87, I think that hopefully, once rust-lang/jobserver-rs#88 is deployed (which should be in version 0.1.31), this PR will be able to pass the CI checks. I believe the breakage was introduced in 0.1.29 (and continued onto 0.1.30 after 0.1.29 was yanked), and 0.1.29 was released on April 11th 2024, 10 days ago. EDIT: 0.1.31 was released today (April 22nd, 10 hours ago as of this edit), and CI now succeeds! |
eef3272
to
7738b0f
Compare
Fixes #41 (Although ambient occlusion won't be 100% accurate due to ignored edge
and cornermargins)Fixes #330 (Necessary to avoid noticeable z-fighting after this change)
This PR ensures that the chunk margins that affect which surfaces are extracted are accurate, ensuring that no surfaces between two solid voxels are rendered, which should result in better draw performance and a clearer view when no-clipping beneath the terrain.
After a chunk is ready to be added to the world (which could be from terrain generation, loading saves, or downloading chunks from a server), the margins of that chunk and its adjacent chunks are modified to be consistent with each other. Then, whenever a block update occurs, margins in adjacent chunks are updated to be consistent with that block update.
To help facilitate this feature, a few additional chunk-coordinate-related math functions have been added to make it easier to reason about how adjacent chunks interact with each other, especially given that different vertices have (necessarily) inconsistent orientations.
A small change has been made to the "extract.comp" shader to prevent the wrong chunk from rendering a particular surface.