Distant Horizons•2mo ago

Issue determining correct biome in BukkitWorldInterface

Thread context: https://discord.com/channels/881614130614767666/881614131877269586/1395922606061785270 So, in the plugin version of DH, we often get minecraft:custom as the returned biome, and have to resort to using bukkit's RegionAccessor through reflection. The problem is, we always do these calculations at sea level:

    @Override
    public String getBiomeAt(int x, int z)
    {
        NamespacedKey key = this.getChunk(x, z).getBiome(Coordinates.blockToChunkRelative(x), this.getSeaLevel(), Coordinates.blockToChunkRelative(z)).getKey();

        // If the server just reports "custom" and we have access to getBiomeKey, try to get the correct biome name.
        if (key.toString().equals("minecraft:custom") && this.getBiomeKey != null) {
            try {
                key = (NamespacedKey) this.getBiomeKey.invoke(this.unsafeValues, this.world, x, this.getSeaLevel(), z);
            } catch (IllegalAccessException | InvocationTargetException exception) {
                throw new RuntimeException(exception);
            }
        }

        return key.toString();
    }

    @Override
    public String getBiomeAt(int x, int z)
    {
        NamespacedKey key = this.getChunk(x, z).getBiome(Coordinates.blockToChunkRelative(x), this.getSeaLevel(), Coordinates.blockToChunkRelative(z)).getKey();

        // If the server just reports "custom" and we have access to getBiomeKey, try to get the correct biome name.
        if (key.toString().equals("minecraft:custom") && this.getBiomeKey != null) {
            try {
                key = (NamespacedKey) this.getBiomeKey.invoke(this.unsafeValues, this.world, x, this.getSeaLevel(), z);
            } catch (IllegalAccessException | InvocationTargetException exception) {
                throw new RuntimeException(exception);
            }
        }

        return key.toString();
    }

In the attached image, all the trees should be teal due to a datapack. However, notice how chunks containing trees on the peaks signifigantly above sea level are miscolored. I think it has to do with an issue on how we probe the biome when generating the lod. I'm not quite sure on the details, but I would imagine this is a good start for investigation.

18 Replies

hjk321OP•2mo ago

Another angle for reference

hjk321OP•2mo ago

A small island, curiously there is some incorrect leaves there even close to sea level, so I could be off base about the cause of the issue. I think it's pretty clear though that the function to grab the biome needs to be more robust.

hjk321OP•2mo ago

@Jckf (since you wanted to be kept in the loop)

hjk321OP•2mo ago

Here's a floating island significantly above sea level where leaves were colored correctly, alternating between two tree types. So I don't know what's causing inconsistency in some cases and having it be fine in others.

Miki_P98•2mo ago

DH LODs do not have any biome blending so if a tree happens to be in a vinegar block big different biome you will see it In vanilla the biome blend would hide such “errors” Can you check if the DH miss-coloured trees aren’t miss-coloured in vanilla if you disable biome blending?

Jckf•2mo ago

I'm creating a debug command to dump all the detected biomes in the area the player is standing in It will also double check if biome at sea level and at player level is different, and warn if it is Aight, grab the latest nightly build, then go to an area that has biome problems and issue /dhs biomes If you suspect that vertical position is relevant, then you should stand at a level different from sea level when issuing the command.

hjk321OP•2mo ago

Thanks! Will try soon

hjk321OP•2mo ago

Tried this, and it doesn't seem to be a biome blend issue. The datapack map also shows it as a pretty unabiguous single biome area.

hjk321OP•2mo ago

All right, it looks like the issue is that lush caves are slightly peeking above sea level.

hjk321OP•2mo ago

It looks like my initial assessment was accurate, but I can't think of a decent robust solution to this besides taking multiple samples above sea level and making a more educated guess In this specific instance, the underground biome starts at 67 which is above sea level I think a majority vote between sea level, build height, and a midway point might be sufficient. I'm assuming the DH lod format doesn't support true 3d biomes (you're unlikely to see long distance underground anyway)

Jckf•2mo ago

The data format supports a separate biome per data point, which effectively means per block. I am only sampling once per column simply for performance reasons, but could just as easily sample per block Let me test how much that matters

hjk321OP•2mo ago

could potentially be configurable, with the optimized overworld builder only checking every 32 blocks or so by default although an argument could also be made to keep this setting internal

Jckf•2mo ago

If the performance difference is negligible, then I'll just always sample every block Benchmarking now Looks like there's a ~15% performance penality for sampling every block Not insignificant I'll make a config option for it then

Jckf•2mo ago

@hjk321

hjk321OP•2mo ago

I'll give it a test! Thanks

hjk321OP•2mo ago

Success. Thank you!

hjk321OP•2mo ago

Out of curiosity, does the 15% penalty apply only to the initial generation, or to propagated updates as well?

Jckf•2mo ago

All LOD generation, so initial generation and updates triggered by changes to the world It was 15% with 4 threads on my 3700x, but the exact number might differ between servers More exactly, generation speed dropped from 140 cps to 120 cps

Gaming

Programming

Issue determining correct biome in BukkitWorldInterface

Did you find this page helpful?