Tags
Creators
Details
1.0.2+26.2
Compatibility
Required content
Changes
Render distant players' terrain live on real Voxy geometry, far past its render sphere
Stream and draw the terrain around a viewed player thousands of blocks away, updating live, well past Voxy's own render sphere — with real lighting.
Four pieces make this work:
-
Far-node injection (VoxyFarNodeInjector): Voxy only draws a camera- centred LOD sphere, so streamed columns beyond it never render. Instead of enlarging the sphere (cost grows with its area), inject just our streamed columns as extra top-level render roots via AsyncNodeManager, and lift the traversal shader's distance cull for them by forcing its sectionRenderDistance uniform past any streamable range. Occlusion and LOD are unchanged — same traverser and screen-space detail, more roots. Terrain then reaches Voxy's projection far plane (~48k blocks).
-
Real-light ingest (VoxyIngestBridge): Voxy's tryAutoIngestChunk reads the client light engine, which never lights a chunk past render distance, so it silently wrote nothing and terrain showed only VSS's stale cache. Run Voxy's own convert -> mip -> insertUpdate pipeline directly, feeding the chunk packet's real block+sky light (captured by ClientPacketListenerMixin/FarChunkLightCapture), so torches, lava, and shadows are correct. Falls back to a heightmap sky approximation if a chunk ever arrives without light data.
-
Deferred re-mesh (VoxyFarNodeInjector.tick): Voxy won't re-mesh a far node live on its own, so after the async node add settles, force it with WorldEngine.markDirty on a client tick.
-
Dirty-tracked re-send (FarChunkStreamer, ChunkHolderMixin): the streamer sent each far chunk once. Mark a streamed chunk dirty on broadcast (scoped to chunks we actually stream — never vanilla's) and re-send the whole chunk on the update interval, so the client re-ingests and Voxy re-meshes it. Full re-send because a client can't apply incremental deltas to an out-of-range chunk it never cached.
Optional dependencies
Projects on Modrinth are automatically available through a Maven repository for use with JVM build tools such as Gradle. To learn more about the Modrinth Maven API, click here.
Note: When available, you should use the creator's maven repo instead as it will have transitive dependency information that the Modrinth Maven API does not. You may also end up with duplicate dependencies if you use a mix of Modrinth and non-Modrinth Maven repositories for your dependencies, because the group identifier will be different when served through the Modrinth Maven API.
Maven coordinates:
Version ID:
build.gradle:
repositories {
exclusiveContent {
forRepository {
maven {
name = "Modrinth"
url = "https://api.modrinth.com/maven"
}
}
// forRepositories(fg.repository) // Uncomment when using ForgeGradle
filter {
includeGroup "maven.modrinth"
}
}
}
// Standard Gradle dependency
dependencies {
implementation "maven.modrinth:IM0DFLOO:ayGRykNZ"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:IM0DFLOO:ayGRykNZ"
}

