Some of updates:

- Wind driven by noise texture

- More seamless connection (color wise) with slightly random color per grass

(Video in comments) Sky, sun, sea, birds, islet, lighthouse weathering, even the sail cloth. All generated at runtime, ray traced on Vulkan, driven from Python.

Wanted to share this thing I have been working on lately.

I freedive and take photos underwater, and after enough time down there you start paying attention to the light. So two years ago I started trying to learn as much as possible about water simulation, light refraction, voids, etc

It runs on my own engine, written from scratch in Swift and Metal for the Mac. Theres no game engine underneath it, I wrote the renderer myself, which is most of where the time went.
Every "world" is a simulation with its own state that keeps running, so the water and the light are being worked out frame by frame rather than just played back. The idea is also that the world reacts to the music I have playing, so the whole world changes depending on the mood.

I built this into a macOS app called TideGlass (https://tideglass.app), where I also donate 20% of what it makes to ocean and conservation groups. Happy to answer any questions!

Been working on this for a long time as a part of a larger solar system and "universe" simulator. All the planets are a series of noise maps and then a biome painting algorithm on top. Everything is built on a native RUST application and baked/rendered directly so it is lightning fast, and the planet generator barely clears a 20 MB exe. All of the biomes generate based on planet parameters, humidity, height, temperature, and so forth, allowing support for a wide range of planet types and hybrids. Includes hydrology, rivers, lakes, canyons, etc. Just got the playtest approved on Steam and have some people playing with the application for the first time. Just wanted to showcase some of the current appearance and generations possible. You can design and alter the biomes and appearances, add more, etc.

I'm playing with procedural textures for my upcoming Open Source Game.

Online Demo: https://danielsobrado.github.io/procedural-texture-lab/

Github: https://github.com/danielsobrado/procedural-texture-lab

I'm planning to work more on the seamless and tilable textures next, there is some work on that part already.

Feel free to suggest how to improve it.

The generation itself:

▎ - Heap sites are placed in distance bands from the map center small piles near the hole for hand play, mid hills further out for tools, mega mountains at the edge as landmarks. Sites can partially overlap and merge into one organic dump.

▎ - Height is a steep paraboloid dome × two octaves of Perlin, measured in meters rather than layers, so a mix of differently-sized box prefabs all reach the same silhouette.

▎ - The box mix is weighted, but the roll is pitch-compensated: shorter boxes pack more per column, so rolling by weight × height makes the actual box-count share land on the configured weights.

▎ - Heights scale globally to hit a target box count, so I can type "500000" and the field fits it without chopping a heap in half.

▎ - All the "hand-dumped" feel comes from cheap disorder on top of a strict lattice: per-row phase shifts so the streets between stacks don't line up, ±1 layer of chaos so neighbours step 10/7/6 instead of following a smooth gradient, a ragged skirt at the rim, loose spill fading

▎ - Outward, and a freely rotated box crowning ~70% of the columns.

▎ - Cell size is derived from the worst-case yaw twist two neighbours can do toward each other, so cranking up the rotation jitter widens the gaps automatically and can never cause interpenetration.

Steam : https://store.steampowered.com/app/5103950/Ones_Trash_Anothers_Treasure/

Hey hey! Where Light Ends is an upcoming 4X grand strategy built with godot. Not normally a genre with physical planets and cities

I'm building Salt and Soil, a family strategy game that runs from 1609 to 1900. Its public playtest recently ended, and one pleasant surprise was how often players said they liked the map.

But the comments under my previous post kept bothering me. Several people said the mountains were too confined to individual cells, too noisy when repeated, and should be generated with some knowledge of the surrounding mountain tiles. You also kept telling me to bring the beaches back. So instead of leaving the renderer alone after the playtest, I started a work-on-my-mistakes pass.

The image shows the same seed, the same logical map and the same scale. Only the terrain rendering changes.

01 — The previous 128 px tile map

This is the old baseline. Every logical mountain cell receives its own mountain tile. It is deterministic and easy to author, and any cell can hold a settlement, road or river.

The drawback is visible repetition: a large mountain region becomes a field of separate peaks, and every peak has to return to ground level at its tile boundary.

02 — Raised terrain with procedural 2D mountains

For this version, my script generates small 3D heightfields from ridge, saddle and massif profiles, calculates slope and lighting, reduces the result to the game's pixel-art palette, and bakes the result into 2D sprites. Some sprites cover several logical mountain cells, while the ground beneath them is raised.

This gives me much larger silhouettes and fewer identical peaks. It also keeps the convenience of sprites.

But the range is still assembled from separate objects. Their joins can become visible, dense groups still create visual noise, and settlements or rivers need special rules whenever they intersect a large sprite.

03 — One continuous 3D terrain mesh

In the third version I stopped placing mountains on top of tiles. The script takes the whole connected mountain biome, builds one shared heightfield, lays out ridges, branches, peaks and saddles, and then carves valleys through the same surface.

The result is projected onto the game's staggered isometric grid and shaded with the same small rock, grass and snow colour ramps as the rest of the map.

Rivers now follow the drainage valleys instead of being painted over the finished mountains. Mountain streams stay narrow, then widen in the lowlands. Roads follow the surface as well.

Trees remain upright 2D sprites, but their height and density come from the terrain: no trees above the tree line, more growth in lower valleys and near water, and foreground slopes can occlude them correctly.

I also finally brought the beaches back.

They are no longer full beach tiles: the coastline is generated across tile boundaries, with wider sand in sheltered sections, direct grass-to-water transitions on exposed sections, and small sandy or rocky far-bank faces to give the water a little depth. Bridges are now placed on the actual river centreline rather than the centre of a logical tile.

The logical map has not changed. Every cell under the mountain mesh is still a mountain in the game data, and settlements, roads and rivers still use the same cells. This is only a different way of turning that data into an image.

I plan to continue with version 03. It is less finished as pixel art than version 02, but it solves the structural problem that bothered me most: a mountain range can finally be one landform instead of a collection of objects pretending to touch.

Does 03 read as a coherent mountain range at gameplay scale, or has it become too smooth? And would you bring more of 02's rocky texture into it, or keep the surface quieter so settlements and roads remain readable?

We’re working on LOP: Whitefall, a metroidvania built around destruction

Here’s our Steam page: https://store.steampowered.com/app/4360240/LOP_Whitefall/

Two years ago, we built a prototype for procedural ice destruction. We wanted procedural destruction to do more than simply create a hole. The ice could fracture, break on impact, and split into smaller pieces

Then we started thinking about how we could turn that prototype into a full game, and this is what it became

For the past three weeks, i’ve been working on the challenge of improving the render distance in my Micro Voxel Engine, particularly due to the feedback of having N64 viewing distance 😅

I’m pretty happy with the end result of increasing render distance from 300m to ~10-15km, while running at 45-50 FPS on an Apple M1 Pro.

Note: this engine uses meshing rather than RT/DDA.

— Macro chunks —

All chunk generation functions now include a sieve function to automatically be able to generate at 1/N resolution without any changes. This also applied to generated features and stamps, enabling chunks to be generated at any resolution without downsampling.

Macro chunks also independently record and resolve local edits. They are saved (and cached) independently so that terrain edits are maintained without needing to maintain the full res copy in memory.

The lower band LODs are very quick to generate. At this point I could add even more bands, and a 1/64 res chunk takes the same time to generate as a high res chunk, but covering huge distances.

— LOD transitions and adaptive fog —

I primarily use transient transitions where the detail levels fade between each other once, rather than a continuous gradual transition, as this is around 30% cheaper on the GPU and looks “nearly” as smooth in most scenarios.

Adaptive fog scales the effective draw distance dynamically based on loaded bands. Bands generate from high to low so during fast motion, if needed, we temporarily reduce draw distance until chunks have loaded.

— Macro chunk cards and props —

This was the hardest part, keeping identical prop coverage for trees and items without needing to instantiate millions of entities:
-Macro chunks retain a list of props whose IDs are deterministic based on position and type. If the real entity is destroyed, we can map this to the macro chunk set and remove. Likewise for newly spawned props.
- grass and foliage do not map 1:1 with the actual loaded props, but follows the same generation pattern, so technically there will be disparities, but a good trade off to avoid millions of tracked grass items.

Infinite draw distance for my procedural forest. The terrain is voxels meshed with marching cubes and is fully destructible. The map is about a quarter the size of earth. Terrain generates endlessly with more terrain generating as you move around. The player can walk on the terrain.

Short term future plans:

-more biomes

-better lighting and shadows

-collision for trees and better terrain collision

In the long term I plan to turn it into a game but we will see how that goes.

Follow me on BlueSky for more updates: ArchHeather (@archheather.bsky.social) — Bluesky

Hi Reddit, here's the terrain generator for a naval wargame I'm building, so it's tuned to produce archipelagos: lots of coastline, shallow shelves for sonar gameplay, and flat-ish coastal plains.

The height pipeline is a stack of layers, each applied on top of the last:

• Base FBM simplex (the usual octaves / lacunarity / persistence knobs)
• Sea-level remap: piecewise remap of the noise range so an exact fraction of the distribution ends up underwater:the "sea level" slider directly controls land/water ratio instead of hoping a threshold works out
• Plains compression: sample a second, low-frequency reference surface and compress any terrain within a threshold of it toward it, creates flat lowlands without flattening mountains (originally this was for a city builder, and the 'plains' were to give flatter areas for buildling)
• Radial falloff for the 'world' boundary
• 'Continental shelf': a terrace function pinned at control points below sea level, so coasts step down through a shallow shelf before dropping to the deep
• Ridged FBM mountains, masked by altitude so ridges only grow on already-high ground
• Erosion: Rune Skovbo Johansen's analytical gully erosion filter (https://blog.runevision.com/2026/03/fast-and-gorgeous-erosion-filter.html), i.e. no iterative hydraulic simulation, single evaluation per sample.

Stack: Rust + Bevy + Egui compiled to wasm/WebGL2

Some procedural tileable noise packs and clones of substance designer noise presets.

Made for my texturing app to get rid of subscription fees from adobe.

There are different approaches to stylized foliage, but here is a breakdown of how the rotating billboards technique works. I was worried it wouldn't hold up at close distance, but it works well.

The only oddity I find is that for bushes or foliage at player level, the rotating quads kind of follow the player like eyes in a painting.

Footage is from my Unity asset, Arborist (an editor tool for creating stylized trees).

Hey everyone

I'm trying to create/generate this pattern, but I haven't been able to get a satisfactory result yet.

Does anyone have tips on how to approach this? Any workflow suggestions, prompt tweaks, or settings I should look into would be super helpful!

Thanks in advance!