Is this normal / can this be avoided?

Minecraft 1.21
Java 21
Fabric 0.16.5
Distant Horizons 2.1.2-a
MC Render Distance: 20
CPU: i9 11900K
GPU: RTX 4080
RAM: 32gb (8|12 set in the launcher for MC)

I'm running into several problems.

• The isolated chunks floating around in the unloaded areas.

This happens at DH Render 128 / 256 / 512 / 1024

• The hard LOD cut off exactly at the MC render distance (This might be normal I'm just not super familiar with DH)

I tried playing around with the overdraw, it didn't really seem to have any effect.

• If I move at normal creative flight speed after about 10-15 seconds, even in previously loaded chunks, a band of empty space starts happening at roughly the MC render distance, and LODs completely disappear behind me so if I turn around everything behind me appears completely unloaded.

This happens from the lowest quality preset all the way up to the highest.

Solution

For the band at the edge of vanilla chunks you can do 3 thing:

tune vanilla and DH fog:
It will hide the problem especially on higher vanilla RD, you need a separate mod to tune the vanilla fog
tune noise texture:
Helps only on solid terrain, so grass, leaves, etc. It will make the transmition less noticable.
Here you can see the result of the above 2: https://discord.com/channels/881614130614767666/1238244368260010047/1238814378057404498
update to nightly that adds a bit of blending between vanilla chunks and DH LODs

Jump to solution

Samalando (ping on please)•10/5/24, 8:33 AM

For the isolated chunk issue: this is normal as LoDs look different than vanilla chunks, the latest nightly has smoother merging but somehow chunks are censored in it

Samalando (ping on please)•10/5/24, 8:34 AM

The hard cutoff: do you have rendering on? If so then I have no clue

Samalando (ping on please)•10/5/24, 8:35 AM

The weird empty stuff: /overdraw

Samalando (ping on please)•10/5/24, 8:35 AM

/overdraw

YAGPDB.xyz•10/5/24, 8:35 AM

Hole at the edge of vanilla Render Distance, especially during movement:

This is caused by either vanilla terrain not loading in fast enough, or shader's incorrect overdraw prevention implementation or configuration (if you use one)
Some world gen speed improvement can be found when adding these two mods, but the affect will be minor:

Noisium
Faster Random
There is another mod that may help:
```
C2ME
```
```
C2ME
```
. However, it can decrease DH generation speed by up to 35%.
The easiest fix is to move slower and/or ignore it. This hole is most visible while moving over not generated (by vanilla) terrain. Moving over that terrain every subsequent time may not create the hole. And moving slower will give MC more time to load the chunks as you go.
If none of that helped, you can also tune the overdraw prevention, look at the third section to know how.

### Low quality full blocks behind and around non-full block, e.g. fences or ladders:

This is intended behavior, to prevent holes in the world while you move, DH will overlap with some part of the vanilla terrain.
How much of the terrain is covered is determined by the overdraw prevention:

```
1.0
```
```
1.0
```
will mean DH LODs start where vanilla chunks end.
```
0.0
```
```
0.0
```
will mean that DH render everywhere starting from your position.
To fix this, you can either:
Increase your vanilla RD, which will move the DH LODs further from you.
Tune the Overdraw Prevention setting, see the next section to know how.

### Where to edit the overdraw prevention setting?

Overdraw prevention setting can be edited inside the DH config under:

Advanced > Graphics > Advanced Graphics

Advanced > Graphics > Advanced Graphics

But if you use shaders, they will override and take control of the overdraw prevention.
In that case, check the shader's settings, if overdraw prevention is not there, contact the shader devs or change the shader you use.

Solution

Miki_P98•10/5/24, 9:08 AM

For the band at the edge of vanilla chunks you can do 3 thing:

tune vanilla and DH fog:
It will hide the problem especially on higher vanilla RD, you need a separate mod to tune the vanilla fog
tune noise texture:
Helps only on solid terrain, so grass, leaves, etc. It will make the transmition less noticable.
Here you can see the result of the above 2: https://discord.com/channels/881614130614767666/1238244368260010047/1238814378057404498
update to nightly that adds a bit of blending between vanilla chunks and DH LODs

MMiki_P98 For the band at the edge of vanilla chunks you can do 3 thing: - tune vanilla an...

JaceTheGrayOneOP•10/5/24, 10:27 PM

Thank you for this! This genuinely solved all of these issues almost entirely.

JaceTheGrayOneOP•10/5/24, 10:28 PM

The only changes I made here are I brought the render distance down to 512, set Noise Steps to 8, Noise Intensity to 16 and Noise Dropoff to 2048.

SSamalando (ping on please)The hard cutoff: do you have rendering on? If so then I have no clue

JaceTheGrayOneOP•10/6/24, 12:16 AM

I figured this out by turning on debug mode, and completely disabling the MC internal renderer.

TLDR:

Turns out the LOD renderer is much slower, and far less symmetrical than the internal renderer, that's not a negative thing, I 100% understand why this is. It's just very difficult to realize this is what is happening as it is possible to move in range for the internal renderer to render a chunk, pass through that chunk, and move out of render range of that chunk before the LOD renderer can build an LOD for that chunk which results in the chunk vanishing the moment it is outside of the internal render range. Increasing CPU load (if you can afford it) helps a lot but even on my 11900K it maxes out my CPU quickly.

Turns out the LOD renderer is much slower, and far less symmetrical than the internal renderer, that's not a negative thing, I 100% understand why this is. It's just very difficult to realize this is what is happening as it is possible to move in range for the internal renderer to render a chunk, pass through that chunk, and move out of render range of that chunk before the LOD renderer can build an LOD for that chunk which results in the chunk vanishing the moment it is outside of the internal render range. Increasing CPU load (if you can afford it) helps a lot but even on my 11900K it maxes out my CPU quickly.

Unecessarily lengthy explanation:

I get that from an inside perspective this might seem extremely obvious but from an outside perspective it's not very obvious. That being said, given how many of the #help-me posts are about this or very similar issues that I believe are being caused by this, I dunno... "misperception", it might be worth adding this info somewhere. 

The issue seems to be that the LOD renderer doesn't render at anywhere near the same speed as the MC internal renderer. It's easy to have the misconception of "This chunk is loaded in game so the LOD for it must be good" and then leave that chunk and have it just disappear with no LOD and be confused about why that is.

With all normal rendering on I basically cannot outrun the MC internal renderer at 32 chunks which means there is no way to tell what is happen but disabling the internal renderer revealed I was outrunning the LOD renderer much sooner than I was outrunning the internal renderer so it was essentially skipping large areas of chunks behind me resulting in them disappearing the second they were out of internal render range. I assume this is due to a combination of deferred loading, priority scheduling, and frustrum culling causing LODs for chunks to be created in a discontiguous manner. Particularly the frustrum culling. It makes me curious how the frustrum culling is handled for chunks that move out of the field of view after LOD generation for that chunk has already started. Given what's happening I'd guess it dumps that process and re-prioritizes.

Turning off the internal renderer makes it extremely obvious what is happening though. Props to whoever decided to keep the debug settings exposed, thank you for that.

I get that from an inside perspective this might seem extremely obvious but from an outside perspective it's not very obvious. That being said, given how many of the #help-me posts are about this or very similar issues that I believe are being caused by this, I dunno... "misperception", it might be worth adding this info somewhere. 

The issue seems to be that the LOD renderer doesn't render at anywhere near the same speed as the MC internal renderer. It's easy to have the misconception of "This chunk is loaded in game so the LOD for it must be good" and then leave that chunk and have it just disappear with no LOD and be confused about why that is.

With all normal rendering on I basically cannot outrun the MC internal renderer at 32 chunks which means there is no way to tell what is happen but disabling the internal renderer revealed I was outrunning the LOD renderer much sooner than I was outrunning the internal renderer so it was essentially skipping large areas of chunks behind me resulting in them disappearing the second they were out of internal render range. I assume this is due to a combination of deferred loading, priority scheduling, and frustrum culling causing LODs for chunks to be created in a discontiguous manner. Particularly the frustrum culling. It makes me curious how the frustrum culling is handled for chunks that move out of the field of view after LOD generation for that chunk has already started. Given what's happening I'd guess it dumps that process and re-prioritizes.

Turning off the internal renderer makes it extremely obvious what is happening though. Props to whoever decided to keep the debug settings exposed, thank you for that.

JaceTheGrayOneOP•10/6/24, 12:20 AM

Sidenote: while it seems like turning the internal renderer back on while in game doesn't work, it creates a really amusing/neat effect.

JaceTheGrayOneOP•10/6/24, 12:27 AM

Also... apparently ~~the cloud layer has a higher strata than the LOD textures.~~ I never noticed this before cause I almost always use shaders.

Edit: In hindsight this is likely because the MC internal renderer handles sky layer culling when underground so there's no reason for DH's LOD renderer to bother.

JJaceTheGrayOne I figured this out by turning on debug mode, and completely disabling the MC int...

BackSun•10/6/24, 1:08 AM

When you talk about "rendering" here, do you mean "generating"?

Rendering is the process of drawing something to your screen, which happens 100+ times a second.
Generating is the process of creating new data (in this case either converting MC chunks into LODs or generating new LODs from scratch).

Also what do you mean by "symmetrical"?

And to answer one of your questions:
Frustum culling only disables rendering, it doesn't affect LOD building/generating.

BBackSun When you talk about "rendering" here, do you mean "generating"? - Rendering is t...

JaceTheGrayOneOP•10/6/24, 2:07 AM

Eh, sort of. I was actually talking about both processes, that and I am probably in the habit of using "render" incorrectly from a software perspective. I work as an engineer in satellite communications and in that realm the term "render" is used to reference output signal generation because the word generate is often used to refer to the initial power signal used to "generate/render" intermediate frequency and primary output signals. It would be confusing to use "generate" for both circumstances as base signal generation is just a power amplification process but output signal "rendering" is the tuning/mixing/encoding/interleaving of multiple base signals.

That being said,
I don't know how contiguous the actual world generation is, only how it is presented to the player on final rendering so when speaking about MC chunk rendering I was referring to how that rendering process is contiguous as in each chunk is rendered at the boundary of an already rendered chunk.

DH on the other hand doesn't appear to render LODs this way. If I turn off the internal renderer and let DH generate/render its LODs it doesn't appear to render LODs with each new LOD being rendered directly connected to or adjacent to an already rendered LOD. I often see DH LODs rendering in isolated empty spaces "seemingly" randomly until the render range is filled with LODs. I was guessing that was due to however DH prioritizes LOD rendering.

The reason I attributed this to the actual LOD generation and not rendering is that ultimately what this results in is some MC chunks being fully rendered without DHs LODs for that chunk being generated yet. I was able to confirm this is happening by loading into a new world, allowing the MC renderer to render out to the internal render range and then setting it to show only the DH LODs which revealed a lot of holes and empty spots within the internal MC render range. This suggests that DH is not generating the LODs contiguously. The consequence of this is that MC chunks can be rendered faster than their LODs are generated by DH and as the player moves away from that chunk since there is no LOD for it yet it disappears as soon as it leaves the MC internal render range. That is the only thing that seems to make sense because I can consistently reproduce this effect and seemingly keep DH from actually generating any LODs by simply moving in the same direction long enough. As soon as I turn around the entire gap between the spot I original left and the spot I am now will be completely unrendered. No LODs at all even though I just passed through all of those chunks and MC rendered them completely. <- this specifically is what was causing the issue I was experiencing when I said LODs were disappearing at a hard edge of the exact internal render range of MC.

I was able to completely eliminate this by simply standing still for 1-2 minutes after MC fully rendered out to the render distance before moving again. I verified this was due to DH LODs not being generated as quickly as MC chunks are being rendered by setting it to show only LODs after I could see the MC chunk rendering was complete for the given internal render range.

The only reason I mentioned Frustrum Culling is because I've seen games that use cull state as a reference for certain things like whether or not lighting should be rendered behind a surface or something like that so I thought it might be possible that DHs LOD generator takes that into account to avoid expending resources generating LODs for chunks that were already out of visible range of the player and would be immediately culled by the frustrum culling process anyway. Again I have zero knowledge about how DH works lol I could be completely wrong about all of that, it's just what seemed to make sense given what I could see happening.

I hope I explained that clearly enough. I apologize for the small dissertation. I just wanted to make sure I accurately and sufficiently described what I was experiencing.

JJaceTheGrayOne Eh, sort of. I was actually talking about both processes, that and I am probably...

BackSun•10/6/24, 3:17 PM

Ah, gotcha.

Yes DH’s process to convert MC chunks into LODs generally lags behind MC chunk generation/rendering. In older DH versions this could cause holes in the LODs, although in newer DH versions the worst that should happen is the LODs will just be a bit delayed behind the MC chunks (I know the nightly build has this feature, I forget if the latest stable does).

CreepermeYT•10/6/24, 3:42 PM

Also, you could try setting your 'CPU Load' in the DH config to 'I paid for the whole CPU'
It will ensure DH runs as fast as possible to render LODs and not fall behind MC
Although if it causes stuttering set it to something lower like 'Aggressive'

CCreepermeYT Also, you could try setting your 'CPU Load' in the DH config to 'I paid for the ...

JaceTheGrayOneOP•10/6/24, 10:52 PM

I usually have it on Agressive and setting it to max does help like I said above but you're absolutely right it does cause stuttering, nothing crazy but definitely noticable.

Turns out the LOD renderer is much slower, and far less symmetrical than the internal renderer, that's not a negative thing, I 100% understand why this is. It's just very difficult to realize this is what is happening as it is possible to move in range for the internal renderer to render a chunk, pass through that chunk, and move out of render range of that chunk before the LOD renderer can build an LOD for that chunk which results in the chunk vanishing the moment it is outside of the internal render range. Increasing CPU load (if you can afford it) helps a lot but even on my 11900K it maxes out my CPU quickly.

I get that from an inside perspective this might seem extremely obvious but from an outside perspective it's not very obvious. That being said, given how many of the #help-me posts are about this or very similar issues that I believe are being caused by this, I dunno... "misperception", it might be worth adding this info somewhere. The issue seems to be that the LOD renderer doesn't render at anywhere near the same speed as the MC internal renderer. It's easy to have the misconception of "This chunk is loaded in game so the LOD for it must be good" and then leave that chunk and have it just disappear with no LOD and be confused about why that is. With all normal rendering on I basically cannot outrun the MC internal renderer at 32 chunks which means there is no way to tell what is happen but disabling the internal renderer revealed I was outrunning the LOD renderer much sooner than I was outrunning the internal renderer so it was essentially skipping large areas of chunks behind me resulting in them disappearing the second they were out of internal render range. I assume this is due to a combination of deferred loading, priority scheduling, and frustrum culling causing LODs for chunks to be created in a discontiguous manner. Particularly the frustrum culling. It makes me curious how the frustrum culling is handled for chunks that move out of the field of view after LOD generation for that chunk has already started. Given what's happening I'd guess it dumps that process and re-prioritizes. Turning off the internal renderer makes it extremely obvious what is happening though. Props to whoever decided to keep the debug settings exposed, thank you for that.

Is this normal / can this be avoided?

Hole at the edge of vanilla Render Distance, especially during movement:

Similar Threads

Similar Threads

Hole at the edge of vanilla Render Distance, especially during movement:

Similar Threads