Distant Horizons for Your Mod Project: Render Distance, Test Setup and Shader Limits

What You Need

Setup Step by Step

1. 01

   Back Up Your Own Instance

   Note down Minecraft, loader, graphics mods, and shader. Back up the instance configuration so you can return to the starting state if rendering errors occur.

2. 02

   Start Distant Horizons Alone

   First install only the matching DH file along with its required dependencies. Test a known world without a shader so rendering errors can be attributed more easily.

3. 03

   Keep the Normal View Distance Moderate

   Let Minecraft render the nearby landscape normally and use DH for the distant area. An extremely high normal render distance in addition to a high LOD range makes troubleshooting harder.

4. 04

   Increase the LOD Range Step by Step

   Start with a moderate value. Wait at a fixed position until data has built up, and observe frame rate, frame times, memory usage, and visible transitions.

5. 05

   Check Multiplayer Separately

   First test on the client side on the server. If you additionally decide on server support, the version, configuration, and distant generation behavior need to be coordinated separately.

6. 06

   Add a Shader Last

   Only enable an explicitly compatible shader after a stable test. Compare the same scene and don't change range, quality profile, and several graphics mods at the same time.

Our Distant Horizons Setup and Its Limits

The graphics setup from 10 September 2026 contained Minecraft Java 1.21.1, NeoForge 21.1.248, Java 21.0.7, Distant Horizons 2.3.4-b, Sodium 0.6.13 and Iris 1.8.8. Complementary Unbound r5.8.1 was loaded as a separate shader variant. These versions describe the historical trial, not a generally recommended current graphics stack.

The gameplay check ran at 1280 × 800 pixels with normal render distance 8, simulation distance 5, a 60 FPS cap and VSync off. The saved DH configuration contains a 256-chunk LOD radius, MEDIUM horizontal and vertical quality and enabled distant generation. These are recorded settings, not performance recommendations: a fully built radius was not demonstrated, and 60 is the configured frame cap, not a measured performance result.

Without shaders, entering the world, a DH database and a gameplay image were recorded. With shaders, an image was captured at the same position, time of day and resolution; DH generation was still running and Iris reported unknown uniforms BIOME_PALE_GARDEN and endFlashIntensity. This is neither a controlled before-and-after benchmark nor confirmation of error-free shader compatibility. A dedicated-server comparison is also missing.

For your own project, start without shaders and wait for data to build at a fixed viewpoint. Only then increase the distance and compare the same scene. Do not copy 256 chunks without checking: if your computer becomes sluggish, reduce the distance or CPU load before adding more graphics mods.

LOD Range Is Not Simulation Distance

Distant Horizons renders simplified distant data. As a result, a mountain can be visible far beyond the normal chunk boundary, even though no full nearby rendering and no correspondingly large active game simulation is running there.

For farms, mobs, redstone, and other active mechanics, the server rules and the respective mod or game version are decisive. A higher LOD range is therefore a visual setting, not a promise of a larger tick range.

How Distant Data Is Generated in Multiplayer

With Distant Horizons only on the client, LODs remain saved between sessions, but they need to be built up through exploration or received world data. Already known landscape therefore appears sooner than an area that has never been visited.

If a compatible current version runs on both server and client, the server can deliver LOD data to connected users, provided remote generation is enabled. This option should be planned deliberately, because data generation and transfer can cause additional work.

Comparing Performance With a Fixed Scene

For comparisons, stand at the same position, look in the same direction, and wait out any noticeable loading. Then change only the LOD range or only one quality profile. A single FPS value right after teleporting isn't a reliable statement.

Testing Shaders in the Right Order

The official project description mentions shader support, but points to compatible combinations. In Iris-based setups, DH, Iris, and the shader need to match each other. The mere fact that Minecraft starts with all the files doesn't yet prove correct LOD rendering.

Test Distant Horizons without a shader first. Then add exactly one shader and check the horizon, water, fog, shadows, and the transition between normal chunks and LODs. If there's an error, you'll have a clear reference state to compare against.

Separating Stutters, Empty LODs, and Graphics Errors

An empty horizon immediately after entering a world is not yet evidence of a performance problem. Check whether Distant Horizons already knows the region and whether data generation is still running. If the view remains empty after a reasonable wait, test the same location without shaders and with the default profile. If LODs appear then, the cause is more likely the graphics combination than missing world data.

Short load spikes during generation differ from a permanently low frame rate. Stay in the same position for comparison, wait until visible building has finished, and then observe movement and camera turns. Reduce only the LOD range or only the CPU or quality setting first. If normal render distance, shaders, resolution, and multiple DH values all change together, the result cannot be attributed to one cause.

For hard edges, incorrect fog, flickering water, or broken shadows, capture the same scene with and without the shader. Record the DH, Iris/Oculus, shader, and graphics-driver versions. Then check compatibility notes for the exact releases. A modpack name alone does not describe this graphics stack precisely enough because individual instances may contain additional or differing files.

Introducing Server Support in a Controlled Way

If you initially use Distant Horizons only on clients, adding it to the server later changes the data path. Back up the world, server configuration, and one test user’s client-side LOD data first. Enable server support in a copy or maintenance window and use a normal account to check whether the connection stays stable and distant data actually arrives. High visible range must not be confused with broader gameplay simulation.

Start without aggressive distant generation. Observe server tick time, CPU, memory, and network together with client frame time. Increase one value only after the previous state remained stable through movement, teleporting, and reconnecting. If problems occur, restore the documented baseline instead of changing server range, LOD quality, and shaders at the same time. This keeps it clear whether the bottleneck is the server, data transfer, or client rendering.

Backing Up, Limiting, and Rebuilding LOD Data

Distant Horizons stores its simplified world data separately from normal Minecraft chunks. Treat this store as a valuable cache, not as a replacement for a world backup. Before changing versions, back up the instance and identify the DH data belonging to the tested world or server. Do not delete all data indiscriminately when only one region appears broken; that also removes correctly generated distant landscapes from other worlds.

If storage use grows sharply, first check which worlds and servers are still used and what LOD range is actually useful. A higher value can mean more data generation, local storage, and longer validation times. Change the limit gradually and observe growth after a comparable exploration route. This produces a setting suited to your computer instead of merely maximizing a number.

For a controlled rebuild, use a world copy or back up the existing DH store first. Start without shaders, remain at a known position, and wait until generation visibly completes. Compare the same viewing direction with the previous state. If the error disappears, add graphics components back one at a time. If it remains, logs, a version list, and a reproducible location give project support more useful information than a general report of “broken distant view.”

With multiple servers using similar world names, make sure you associate the correct data store. Use an unmistakable position and verify after joining that the displayed landscape belongs to the current server. Stale local data, a changed world state, and a real rendering bug can look similar. After a world reset or map change, back up the old store and keep it separate before testing a clean rebuild.

Frequently Asked Questions

Editorial review method

The MCRedstone editorial team checks version and compatibility details against the official project sources linked below. Dated observations from isolated Minecraft test instances are listed in each article. Other control steps are instructions for your own checks; multiplayer, persistence, and troubleshooting claims are limited to what those tests and primary sources support. We review the article again when relevant details change and update the review date.