Skip to content

Modify Chunk Loading to Support Significantly Larger World Sizes#54

Closed
Digitalfear117 wants to merge 1 commit intosmartcmd:mainfrom
Digitalfear117:Larger-World-Sizes
Closed

Modify Chunk Loading to Support Significantly Larger World Sizes#54
Digitalfear117 wants to merge 1 commit intosmartcmd:mainfrom
Digitalfear117:Larger-World-Sizes

Conversation

@Digitalfear117
Copy link

Pull Request

Description

Allows for significantly larger world sizes by decoupling render list allocation from total world size.

Previously, increasing the world size caused the renderer to reserve command/display list storage for every possible chunk position in the world, even if most of those chunks would never be active at the same time.

image

Changes

Previous Behavior

The renderer used a fixed mapping between a chunk’s global index and its render list storage. Even though only a limited number of chunks can actually be rendered around the player at once, the engine still reserved render resources for the entire possible world footprint.

Root Cause

The rendering resources were allocated based on maximum possible world size, not active chunk usage.

New Behavior

Render list storage is now allocated dynamically for active chunks and released when those chunks are no longer referenced. This allows world size to scale much further without requiring render resources to scale with the full world bounds.

Fix Implementation

Replaced the fixed global render list mapping with a dynamic allocation model. Active chunks now acquire render list storage on demand and release it when no longer referenced.

I have set the current limit to 32*64 but feel free to try larger values. Just note that the game may use a lot of ram if you set it to something crazy like 512x64 lol

@void2012
Copy link
Collaborator

void2012 commented Mar 1, 2026

I'm worried about the concurrency problems this may cause. Needs deep testing?

@void2012 void2012 marked this pull request as draft March 1, 2026 20:21
@Digitalfear117
Copy link
Author

That's fair, and honestly there is still more work to be done here to make this truly useful. Mostly just wanted to get this out there since I have been working on this for like the past 15 hours lol. However it does work. I think it's time for me to get some sleep though

@void2012 void2012 added performance Performance bottlenecks and bugs or maybe a room for optimizations world generator Bugs and problems with the world generator ABI Anything related to libraries (both static and dynamic) and ABI breaks priority: low labels Mar 2, 2026
@kubune
Copy link

kubune commented Mar 2, 2026

i tested a bunch of forks merged together

the more chunk patch pr (default is 32727 max coords x or z) has a bug ig

i was flying from 0, 0 to the world border without closing and the more i traveled the more the debug screen (the f3 one that shows version and structure like stronghold location) when i opened it was lagging eventually making me have 3 fps when opened.
after reopening the world after saving the fps goes back to normal

@void2012
Copy link
Collaborator

void2012 commented Mar 2, 2026

Thanks. This is why we should test stuff before merging.

@Digitalfear117 Digitalfear117 closed this by deleting the head repository Mar 3, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ABI Anything related to libraries (both static and dynamic) and ABI breaks performance Performance bottlenecks and bugs or maybe a room for optimizations priority: low world generator Bugs and problems with the world generator

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants