Skip to content

Experimental Data-Driven Biome Classifier Rewrite#178

Draft
JonaldJohnston wants to merge 5 commits into
xandergos:1.21.1from
JonaldJohnston:1.21.1
Draft

Experimental Data-Driven Biome Classifier Rewrite#178
JonaldJohnston wants to merge 5 commits into
xandergos:1.21.1from
JonaldJohnston:1.21.1

Conversation

@JonaldJohnston

Copy link
Copy Markdown

When I initially found this project, I had the thought of what it would take to add a ton of biomes from different biome mods, such as Oh The Biomes We've Gone. Turns out, working dozens of biomes into the existing if tree is not fun at all. I then began to think about what a better approach might be, and that's what this PR aims to address.

How this works, currently, is each biome that you want to add gets a call to addBiome, which looks like

addBiome(builder, [biome ID],
                [array of elevation flags],
                [array of temperature flags],
                [array of slope flags],
                [array of tree coverage flags],
                [array of moisture flags],
                [has snow] (also an array, dont worry it's for a reason)
        );

There's more examples starting at line 168 in BiomeClassifier.

Each array in the parameters describe the conditions at which the biome can appear, multiple conditions present in a single array are treated as an OR condition, for example, {temperature.TEMPERATE, temperature.WARM} would signal that this biome appears in temperate or warm regions. Passing in null is treated as a "dont care".

in the background, addBiome looks at every possible combination of the given conditions and adds them to a hashmap (builder in the args), with the condition flags used as the key. classify then calculates the flags at whatever position it's processing and looks up the corresponding biome(s) in the hashmap. If multiple biomes correspond to a particular condition, cell/voronoi noise is used to randomize the output into discrete regions.

Ultimately, my goal is to have this input as a config file that the user can toy around with easily.

Current considerations:

  • The current cell-noise regions look kinda weird, I need to mess with the parameters more but I think it's something I can make look right.
  • My current biome list was kinda hacked together without much scrutiny, so there might be some problems.
  • A "priority" flag for biomes to define rarity when there's multiple candidates for a condition might be nice
  • I have an idea for auto-patching conditions that don't get any biomes associated to them by copying the "nearest" (in condition space), but I'm not sure that's desirable.

@ThatDamnWittyWhizHard ThatDamnWittyWhizHard added priority: high Important issue or feature needed for an upcoming release. status: in progress Work is currently in progress. type: feature New feature proposal or request. env: dev Issue related to the development environment. type: refactor Internal cleanup, restructuring or code improvement without major behavior changes. and removed type: feature New feature proposal or request. priority: high Important issue or feature needed for an upcoming release. labels Jun 13, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

env: dev Issue related to the development environment. status: in progress Work is currently in progress. type: refactor Internal cleanup, restructuring or code improvement without major behavior changes.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants