Tags
Creators
Details
1.0.3+26.2
Compatibility
Required content
Changes
Extend far render to a slider-tied bound past Voxy's 48k projection plane
Terrain and distant players were both clipped at fixed limits — Voxy's hardcoded 48,000-block projection far plane cut off injected far columns, and the managed-entity far plane was capped at 16,384, so a viewed player would vanish while the ground under them kept drawing (or vice versa).
Lift both to a single shared, live-computed bound:
-
Raise Voxy's far plane: an @ModifyConstant mixin on VoxyRenderSystem.computeProjectionMat swaps its 48,000 constant for the shared bound. Voxy is an optional client dependency and its classes are absent on a vanilla client / dedicated server, so the mixin lives in its own config (iseeyourchunks.voxy.mixins.json) gated by an IMixinConfigPlugin that only applies it when Voxy is loaded — matching the reflective-only pattern used everywhere else Voxy is touched. Nearly free on depth precision because computeProjectionMat is reverse-Z.
-
Tie the bound to the slider: ClientEntityVisibility.farRenderPlaneBlocks() returns the visibility-distance slider clamped to a 48,000 floor (never below Voxy's own render sphere) and a 1,024,000 ceiling. Both the Voxy far plane and the managed-entity far plane read it, and both projections rebuild every frame, so moving the slider extends terrain and players together, immediately, with no reconnect. The entity ceiling is no longer a separate 16,384 constant. The 1,024,000 ceiling is a deliberate "more than enough" cap, not a technical limit — reverse-Z means it could go further at no real cost.
-
Stop calling the slider max "Infinite": rendering reaches at most 1,024,000 blocks, so the top stop now reads "Maximum (1,024,000 blocks)" and the README reflects the real limit.
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:n1lWBw6h"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:IM0DFLOO:n1lWBw6h"
}

