Feat: Mountain Region Variability - #95
Draft
scottdraper8 wants to merge 2 commits into
Draft
Conversation
scottdraper8
force-pushed
the
feat/mountain-region-variability
branch
from
June 27, 2026 03:58
14fe72b to
82e47e8
Compare
Owner
Owner
Collaborator
Author
|
Thanks for checking this out, and good catch. I'll be looking into this |
scottdraper8
marked this pull request as draft
July 19, 2026 08:57
Introduces a mountainVariety setting (0.0-1.0) that creates three parameter variants (low/center/high) per mountain algorithm, producing visible height, width, and erosion differences between mountain regions. Uses dual-mode variant selection: hashed cell identity for Voronoi terrain regions (uniform 33/33/33 distribution, no spatial bias) and Perlin noise with coordinate offset for the mountain chain overlay.
Prevents broken terrain generation from hand-edited preset JSON with values outside the valid slider range.
scottdraper8
force-pushed
the
feat/mountain-region-variability
branch
from
August 2, 2026 06:11
9dd4af2 to
8c955b6
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.






Mountain Region Variety (
mountainVarietySetting)Important
Main idea:
This feature adds variability to mountain generation without changing existing settings, user presets, or default behavior. The feature is turned off by default and only takes effect when the user opts in.
The motivation behind this feature is to achieve more realistic variability of mountain shape and scale within the same world.
1. What is this?
A new
mountainVarietyslider (0.0 to 1.0), shown below.Currently, every mountain range in a world shares the same height, width, and erosion profile. With this setting enabled, your other mountain settings become the midpoint of a range, and different regions get different parameter rolls around that midpoint.
For example, if you set$n$ , enabling variety means some regions will generate mountains shorter than $n$ and others taller than $n$ . But the average across the world stays centered on $n$ .
verticalScaleto some value0.0: nothing changes.1.0(max variety): some ranges are shorter and wider with heavy erosion, others are taller and narrower with sharp ridgelines.2. Why add it?
RTF already has three different noise algorithms for mountains (M1/M2/M3), but they all share the same height envelope, feature scale, and erosion character. So every mountain range in a world ends up feeling sort of the same. Real continents don't work that way.
For example, in just the one U.S. state I live in, the mountain ranges themselves vary pretty extremely in shape and scale:
So with the
mountainVarietysetting we get a little closer to emulating the natural world by making mountain settings a range and not a fixed point for the whole world. When building a preset withmountainVarietyin mind, you'd choose:3. How does it work?
Each mountain algorithm (M1/M2/M3) builds three internal variants:
These get wrapped behind a single pool entry so the existing terrain layout stays the same.
Which variant a region gets is deterministic and seed-driven. Its an even one-third split and no spatial bias. The slider simply controls how far apart/extreme the variants are, not which one gets picked. Moving it from 0.5 to 1.0 makes the low variant shorter and the high variant taller, but doesn't reassign which regions get which variant.
Note
The erosion strength row only applies when
fancyMountainsis enabled.fancyMountainsis still just a boolean toggle. But when bothfancyMoutainsandmountainVarietyare toggled on, the erosion pass runs at different intensities per variant, so some ranges look freshly uplifted and sharp while others look heavily weathered.4. How to QA this?
Setup
moutainVariety: 1.0mountainVariety: 0.0Look for:
fancyMountainson: sharp ridgelines vs rounded weathered profilesImportant
33% of mountain regions will land on the "center" variant (the explicit settings the user chose), which means they'll look identical to a world with variety turned off. If you're comparing a varied and unvaried world at the same coords and they look the same, you're probably looking at a region that uses the "center" variant. Just fly to a different mountain range to confirm.
Note
If you look in the RTF Discord, you'll see lots of presets where people are fixating on one specific range to emulate, because that's really all they can do. This setting would allow for different kinds of mountain ranges to simultaneously exist in a world. Similar to how the Wasatch Range and the Uintas can coexisit in the same state.
However, I recognize this setting is not the end-all-be-all for mountain variety in RTF. To vary between something as extreme as the Tasmanian Highlands and the Himalayas, that would require much more extensive changes than this relatively minor addition.
The reason being, if the coded range differences that
mountainVarietygenerates internally were pushed too far, it would become unwieldy. Mountains would clip to world height, or collapse into nothing. The code's spread constants have to stay reasonable for the users that turn it all the way up to 1.0 with already heavily altered presets.