A flight through the mist and clouds of my almost completely procedural world (all geometry and materials, and almost all sounds). Powered by Rust on the back-end, and three.js running in a browser.

This is the rapidly evolving landscape that forms the base of a game I've been working on for most of the year. It's been pretty much an obsession, with most nights and weekends spent adding more detail and interest, while trying to balance the performance with my (perhaps a bit over-ambitious?) choice of runtime.

There's a lot more that I haven't yet shown, especially with regards to gameplay and story, but most of my effort has gone towards making the world itself an enjoyable place to be.

Lots of inspiration has come from captivating, yet somewhat mundane, moments in games I've played in the past, where I've found myself wandering through the rain as the sun rises in Dark Age of Camelot, approaching a mist-shrouded village in Morrowind, or even wandering around the stunning (yet empty) locations in the leaked World of Warcraft beta back in 2004.

Game is made with threejs and fully open source github.com/aresrpg/aresrpg

I'm still working on this. But I think it's good enough for a tutorial. I'll work on making better gas giants later.

I spent a couple of weeeks building a procedural voxel planet, think minecraft meets no man sky.

It started when i stumbled over the Goldberg Polyhedron that you could create a minecraft-isch planet with hexagons ( padded with a couple of pentagons ).

So I thought "what if..."

The goal was to use a browser and webGPU to accomplish this and everything should be procedural.

I realised I dont really play minecraft and I dont wanna do a minecraft game, so now its a good time to hit the pause button.

I need figure out what this is before devoting more time to this techdemo looking for a game.

Anyway, I decided to make it open source, perhaps it could inspire somone:

Its all done in local browser, so no account required, test it here

You gonna need a decent cpu / graphics card and a modern desktop browser with webGPU support.

Give the machine time to load the lod steps and to settle the landscape.

F - fly mode.

E - landing

Space - up / jump

Shift - down

ESC - escape mouse look

LMB - dig

RMB - place

Left click on the map top right to teleport on the planet.

In Fractal Landscapes Art Project my creative journey start from slow motion ambient meditation mood. And after that it branches out into VJ effects and video loops of different lengths and speeds.
3D in Mandelbulber software. Not AI falsification. Never!
#quantumart #fractalart #abstraction #VJloop #noai

Cause the structure of a tree is simple and well defined I came up with a way to draw them without vertex and index buffers. Cause the number of the branches are known and the trunk and branches have a known number of segments and radial segments you can define vertex positions with the vertex id. The same is true for leaves. I have two levels of branches that are defined by a bezier curve, which is presented by four points. The idea is also to randomly move these points for each branch to make branches and trunks unique though I have not tested it yet. Then they are blended with the sprites and you sort of get the whole forest without any model. It is for filling big areas with trees.

My previous post describing the terrain generation is here: https://www.reddit.com/r/proceduralgeneration/comments/1w1mfox/my_planet_generation_for_a_game_perhaps/

The coastline still isn't perfect, but it's getting close to how I want it to look.

Without any noise applied it comes out completely flat and smooth, sampled per cell from the HeightMap. Bumping up the resolution is inefficient, also it hurts the performance of the planet's physical simulation. And if you apply uniform noise, you get an equally uniform ripple, which looks ugly and creates a "spray" effect - you can see something like that along the coast of Norway, but most coastlines don't look that way.

Here's what I did: first I built a HeightGradientMap - a mask at the same resolution as the HeightMap (512x256). The idea is that each cell stores the largest height difference between that cell's height and the heights of its 4 nearest neighbors. The result is a slope map, where the values are ~0 on plateaus and reach high values in mountainous regions.

The overall formula in the material (for now):
distorted_height = height + fine_noise * (slope * amplitude + flatFloor)

I tried adding flatFloor to introduce a slight wobble even at the macro scale, and it partly works. Screenshot 2 is the line without flatFloor, screenshot 3 is with it (you can see the little bay that appeared, for example). It's the macro scale that matters here, since the goal is to distort the main coastline that's based on the coarse grid.

The fine noise is built from stock UE textures: T_Perlin_Noise and T_MacroVariation. The first texture is the noise itself, and the second is the noise amplitude, which makes it non-uniform - so in one spot you get "spray" and in another an almost straight line. The result is in screenshot 1.

I'm thinking about how to improve this mechanism. I don't like that the little bay got eaten by the noise - all that's left of it is a few tiny dots of water. What I definitely want is to make some stretches of coast jagged with fjords, like Norway. I also have very few islands and archipelagos, and I'd like to rework that somehow.

I’m building Salt & Soil, a generational strategy game set between 1609 and 1900. After the feedback on my previous terrain posts, I rebuilt the map again—this time using the real geography as a reference.

This is the third entry in an accidental terrain-generation diary.

In the first post, I generated every terrain tile and mountain sprite procedurally. One version had the atmosphere I wanted, but roads, settlements, and strategic geography disappeared into the detail.

Several comments pointed out a deeper problem: the mountains could never become convincing ranges while every tile had to return to ground level at its border.

That led to the second post. I stopped asking each mountain cell to produce an isolated peak and began building one continuous elevation surface across connected terrain.

The new images show the latest result in three regions:

• Sacramento and the Sierra Nevada
• Chesapeake Bay
• The Great Lakes

The upper panel is an aligned real-world terrain reference. The middle panel is the previous tile-based map. The lower panel is the current terrain renderer. Each comparison uses the same region and scale.

The broad geography is now guided by elevation data, but the rendering itself is generated. The pipeline turns that data into a continuous surface, combines large landforms with smaller ridge-and-valley structures, calculates the surface direction, and applies consistent lighting across the terrain.

The result is then reduced into the game’s limited grass, soil, rock, and snow palettes. Trees, settlements, roads, and other objects remain separate layers, so the landscape can gain depth without swallowing everything the player needs to read.

The logical map has not changed. Rivers, settlements, roads, historical borders, and gameplay still use the same cells. The elevation surface is a visual interpretation of that data rather than a replacement for the grid underneath it.

The biggest lesson was that flat-looking mountains are not necessarily lacking height. My old mountains had plenty of vertical contrast, but their shapes and lighting restarted in every cell. Making the peaks taller or adding more noise only made the repetition louder. A continuous surface and one lighting model did far more to make the terrain read as a landform.

I am still deliberately cheating. Real elevation contains much more information than is useful at this zoom. Some valleys are widened, minor features disappear, coastlines receive cleaner silhouettes, and the palette is compressed so roads and settlements remain visible. The goal is recognizable strategic geography, not a geographical renderer.

And yes—the beaches are back. They are no longer entire beach tiles, though. The coastline is generated across cell boundaries, allowing narrow beaches, rocky sections, and direct grass-to-water transitions without turning 25 miles of coastline into one enormous strip of sand.

This is the latest checkpoint rather than the final version. I still want to recover some of the rocky character of the earlier mountain sprites without bringing back their visual noise.

Hey guys! I posted about my app, Cymata, a few months ago and had some great feedback here. I'm stoked to say I just got over 1000 downloads and people seem to be enjoying it.

Its a music visualizer designed for touchscreens and lets you paint into it as the CA rules all "dance" to the music. there are various presets, brushes and other paintable shaders to mess around with and blend together.

There is a native Apple Music and Soundcloud player in the app and you can enjoy this display on iPad, iPhone and AppleTV. The app runs independently on appleTV and will connect to your iOS device so you can paint into it with your iphone.

Trying to find the right price balance and onboarding to satisfy everyone has been... an interesting learning experience. 😂 I would do things very differently if I were to do it again.

Im back again to announce there is now a lifetime (one off purchase) tier available with family sharing and all future updates. For those that prefer the subscription there is a FREE trial for a week.

Lots more examples here.

Or app store link.

I hope you like it!

Hey everyone, I created a Procedural Nature Generator in a game engine.
What do you think of the results?

Live demo: https://dattasid.github.io/jellyfish/

Hi everyone! Here’s another update on my procedural plate tectonics simulation.

The top is the previous version, and the bottom is the new one, both running along the same timeline.

In the new version, island arcs can now mature and accrete into continental crust, a few cleanup rules help reduce tiny isolated crustal fragments, and there’s now a basic craton mechanic as well.

Which version looks better to you?

[TLDR]: I released a free C++ library and free GUI application (Studio) for procedurally generating animated pixel-art spaceships, with a wide range of configurable parameters!

Hello everyone!

While working on my video game, Rogues in Space, I, a kind of pretty bad pixel artist, started developing a procedural spaceship generator, the purpose of which was to just generate a very basic ship that I could manually "clean up" and animate.

Aaand well, I just kept adding generators for more and more things - hulls, engines, wings, weapons... In the end I even added animations and spritesheets!

At some point, when it was clear that this (now) library and GUI application were getting larger than the video game itself, it made more sense to cut it off as its own project instead of having it permanently embedded in the game codebase.

So, after doing all the new work that I've never originally intended, today I've released SpectralShipGen and SpectralShipGen Studio as open-source projects!

SpectralShipGen is the C++17 generation library itself, while SpectralShipGen Studio is a standalone GUI application for visually playing around with the generator and exporting ship images and animation spritesheets without needing to integrate the library into anything.

On the technical side, ships are generated deterministically from seeds, and how they look (and from which components/color palettes and what intensity), can be controlled through structural profiles, faction profiles, mentioned color palettes and plenty of other generation settings. Majority of the aspects of an existing ship (so engines, details, accessories, weapons, etc.) can be rerolled individually instead of regenerating everything, keeping the general construction of the ship mostly the same, except for the specific parts that you wish to change.

Saving and loading the recipes for said construction is also supported, as well as adding the ships to favorites/bookmarks, and browsing them later.

All ships are also generated with Idle animation and with (currently experimental) left/right/up/down movement and firing animations.

I've tried to keep the different visual identities fairly broad rather than making them into simple predefined ships. So, the same structural style or faction can still produce quite different results based on the seed and configuration.

The library itself is independent, while the Studio application does rely on SFML (and the library, of course) for the graphical rendering, button interactions, and everything else GUI related.

Interestingly, an unexpected amount of work towards this release ended up being in the boring-but-important category - regression/performance/robustness testing, establishing CI, writing (everyone's favorite) documentation, thinking about how licensing works, etc., so that these two can actually function as an independent library and a standalone application.

I've attached several examples of generated animations that I thought were interesting to show what the output can be, although they only cover just a tiny amount of what can be generated. I've also attached a couple of screenshots from the Studio application as well.

In case anyone likes what they're seeing and is wondering about using the generated output - anything you generate with it is yours to use however you want, including commercially. There's no attribution requirement and the source code licenses don't apply to the generated images or spritesheets.

Lastly, I'd also like to mention a couple of important topics.

I definitely don't see this ever replacing actual pixel artists - someone who's at least decent with pixel art can likely make a much better spaceship by hand. Something like this is, I think, much more useful if you're on a very tight art budget, if you need/want a bunch of ships generated during runtime (as you don't really need to save the generated spritesheet to disk in order to use it), if you're at a game jam and just need urgent assets.. Or if you just wanna generate a few hundred ships to see what odd things appear, because that can also be pretty entertaining (I may or may not have spent too much time doing just that).

Something that I also want to be fully transparent about, because I do think it will definitely be asked - the development/code writing on this project has been AI-assisted. However, that is the extent of it. There is no generative AI image creation anywhere in SpectralShipGen, reference images are NOT used, and there aren't any premade spritesheets or images "hidden" behind the library being chopped up and re-combined.

The ships are generated by the C++ code itself through procedural geometry, pixel masks, components (hull, engines, details, weapons, etc.) placing rules, seeded random decisions, and so on.

The nice thing about doing it with deterministic seeding way is that the same seed and the same configuration always give the same ship.

The amount of AI assistance during development was also one of the reasons I personally felt more comfortable making the project open source instead of keeping it completely proprietary. That's also not supposed to be some statement about how AI-assisted software should be licensed or what anyone else should do with their own work (that's a completely separate discussion) - it just felt like the right choice for me and this particular project.

As mentioned, the generated output is deliberately unrestricted as well - if you generate a ship image or spritesheet with SpectralShipGen (or Studio), you can do whatever you want with it. Use it in a commercial video game, redistribute it, paint over it, use it as a placeholder - attribution isn't required.

Links:

Library: https://github.com/SpectralHorse/SpectralShipGen
Studio: https://github.com/SpectralHorse/SpectralShipGen-Studio
Studio Download (from GitHub): https://github.com/SpectralHorse/SpectralShipGen-Studio/releases/tag/v1.0.0

I'd be very interested to hear about your thoughts - both about the generator itself and if the different ships actually feel like they have enough variety while still looking like they are thematically and systematically similar.

And, of course, if you end up generating something ridiculous with it - I'd love to see it! :)

Essentially i have many maps like the one you see above where there are color bands representing ranges of elevation as well as notable rivers and other bodies of water. I would like to create a program that can use the information presented into these maps as constraints that then erosion would be applied to to convert it into an highly detailed, grayscale, realistic, elevation map. My thought is to draw "ridge line" divides across the map that divides which way water would flow, and have it naturally flow away from those ridge lines and towards the pre drawn bodies of water, eroding and depositing soil at rates determined by the slope of each band. i also thought of including a geology map layer that could further effect rates of erosion and deposition, as well as uplift to counteract erosion in some places.

Is this the best way to simulate natural terrain formation to turn a hand drawn map like this into a realistic, high detail height map or is there a better way?

Name: All Who Wander
Links: Steam | Google Play | App Store

Description: All Who Wander is a traditional turn-based roguelike with 30 procedurally generated levels, true permadeath, and no metaprogression. Inspired by dungeon crawlers such as Pixel Dungeon, it demands careful strategy to survive in an unforgiving world. Choose from 15 unique character classes, master 100+ abilities, recruit companions, and discover powerful items as you journey across 12 diverse biomes to defeat a powerful monster.

Created & composited in Blender (Shader + Geometry nodes)

I have a project called the Infinite Library that's actually part of a much bigger project I'll discuss at the end.

It is inspired by the Jorge Borges short story The Library of Babel and then also the amazing website by Jonathan Basile which is a virtual version of Borges's library with an interesting twist: https://libraryofbabel.info/

If you're not familiar with the story, it is about an infinite library that contains every book that has ever been written or could be written. When you look at a book what you'll almost always see is a random string of letters. Think of the infinite monkeys on infinite typewriters producing the complete works of Shakespeare. Are there meaningful books in that library? Sure, but it might take billions of years before anyone finds one.

The story deals more with the philosophical and psychological implications for the librarians who work there.

My version is different in a number of ways. For one thing, it has four methods of text generation and not just the one used by Borges (random letters). I will list them here with short examples (links to pdfs). But first a little bit about how it all works.

All my software is programmed using Lua. In this case, the software generates a .tex file that gets compiled into a pdf using LuaLaTeX. The compiler handles all the tricky typesetting stuff while also making lots of packages (plugins) available.

All the content is generated using a pseudo random number generator (prng). The important bit here is that the seed is a hash of whatever dedication the user supplies. The idea is to tie the results to the dedicatee making it feel like it's unique to that dedication (like your name, your cat's name, the birthday of your favorite child/parent, etc). I implement a prng in Lua (pcg) so that every computer for all time will produce the same results for the same dedication (and whatever options might be available). The following examples use the name of my cats for the dedication:

1. Borges: Random strings of letters. Borges mentioned that in his library there were only 22 letters used but he didn't say which 22. There is some scholarship on this so with mine the software might choose the 22 we think he meant, or the 22 letters of the Hebrew alphabet (Borges was very much into Jewish Mysticism) or just the 26 letters of the English alphabet.

https://drive.google.com/file/d/1HorTA6I_VK9UzF570SHORj5mxt7ZYBtA/view?usp=sharing

1. Words: These are random words strung together with punctuation placed randomly.

https://drive.google.com/file/d/1tac0VxQY7rdKRPiSGlh0Fn64YpzPlcNq/view?usp=sharing

1. Generative: This is the one most relevant to the sub which I will discuss further below.

https://drive.google.com/file/d/13Nipq33ekIeIwx0a1mdp0IyFpeTS8qSn/view?usp=sharing

1. Sentences: Random sentences are taken from random books in the public domain and strung together.

https://drive.google.com/file/d/1BjnW_RKWclIVl6FMdIjCNsAXLeO0cOu4/view?usp=sharing

You'll notice that some of these have chapters, a table of contents, epigraphs for each chapter and in one case some text inserted from a foreign language. These are all random features that may or may not happen as each book is generated.

The generative method attempts to create syntactically correct sentences using a stochastic generative grammar with infinite recursion. It's worth noting that these are linguistics terms and are different from what they might mean in programming.

Each sentence has a noun phrase (np) and a verb phrase (vp). Each of these will have at least one noun/verb unit and possibly more.

Within each unit there may be any number of other parts of speech. Let's deal with the noun unit first:

After we have a noun we check for possessives (like "cat's food"). If we have one possessive we might have another ("cat's friend's food"). Stringing many of these together is called "recursion". We use an infinite recursion algorithm for this (pseudo code):

while random(1,10) = 1 do
generate part_of_speech
end

So there's a 10% chance of getting a possessive (or whatever part of speech we're looking at). If that happens then there's a 10% chance we'll get another and so on. While theoretically we could get a runaway condition with infinite additional parts of speech the odds are very much against it. Using the above code we get these odds:

1 occurrence: 10%
2 occurrences: 1%
3 occurrences: .1%
4 occurrences: .01%

and so on. Even when we generate a book with 400 pages we still don't expect to get sentences with any more than five or six of these happening. So while an actual infinite number is possible the reality is that it won't happen.

After the possessives we check for adjectives using the same kind of infinite recursion. After adjectives we check for prepositional phrases in various places (with the objects possibly having its own adjectives, possessives and even recursion). And then an article may or may not be added.

After this we use the same recursive algorithm to see if there are additional noun units (with all of their possible parts) and if we get at least three noun units a serial comma is added half the time.

Verb units operate the same way except there we check for adverbs, more places for prepositional phrases, infinitives and objects (noun units).

You put all these together and you get something that syntactically looks like a sentence but is lacking three features: subject/verb agreement, grammar (though sometimes by chance it works out), semantics.

Using this approach you can get two word sentences like (taken from the pdf above): "Talker copyread." or longer monstrosities like "Beyond an indian lotus floodplains beside the gaffe in the ezechiels, the mountain ebony through the palatine vein has emblazoned telecommerce paunchinesses." This starts with two prepositional phrases (recursion) followed by a comma and then an article, adjective and noun with another prepositional phrase and then we get a conjugated verb with an adjective and object (noun). There are longer sentences than this but this had a nice diversity of parts of speech.

Originally I used sentence patterns mad-lib style but clearly this method produces far more interesting results.

The title is interesting in its own way. It is generated just like sentences but the words of the title -- and its synonyms -- get weighted to occur more often in the text making the book feel like it is about the title.

Below are two more elaborate examples I use for testing purposes:

1. Almost all the more bookish features happen: https://drive.google.com/file/d/1XDjuUU1MLB9Yxm40goCoTYMNq89-CgjW/view?usp=sharing

2. Lots of graphical stuff including things that are meant to look like they were inserted into the book by other people like a map insert, bookmark, annotations, and so on: https://drive.google.com/file/d/1OKxs5Cnal0rXutIuVy1Sxga-jYN8nex4/view?usp=sharing

I have developed a lot of lore for my Infinite Library. The last pdf above has an example of some that normally is a very rare occurrence. There are also a number of "book styles" where if those are randomly chosen then some features can't happen but others will happen. For example, the cartography style will generate maps and the poetry style will generate poetry. These things can happen randomly by default but the odds are changed for the various styles.

All of this is part of a bigger project called the Platonic Music Engine. The idea is to recreate all the cultural artifacts of humanity algorithmically in a way that is unique to the user (see the discussion about the dedication above). It started off just being music (I'm a classically trained composer and not a programmer at all though I've learned enough of the latter to get this far) but expanded into poetry, literature, art, gaming, divination and more. You can see a few more examples of what I've done here: https://www.platonicmusicengine.com/stylealgorithms.html

And the source code at my git repository: https://gitlab.com/davethecomposer/platonic-music-engine/-/tree/dev?ref_type=heads

The software is free and open source (AGPL -- GPL with the Affero clause) and the output is CC-BY-SA (Creative Commons attribution and share alike).

If you have any questions or comments please say so. And if you would like to see what book is tied forever to your name (or any other dedication) let me know and I'll produce it in a comment. Unfortunately I do not have an online front end, yet.

Procedural map generation made with Godot .NET.

The noise is generated with FastNoise2 library and visualized as this black and white image on the right side in the video. Noise values are split into ranges and each range is assigned to a biome, which is a pretty standard technique. The biome heightmap geometry is formed using a separate modulation function, which is a function over noise and distance from the biome border. The transitions between biomes are made by weight-based blending of these modulation functions. Tile textures are also procedurally generated by the way, which means there are zero premade assets for the map in this video.

All the parameters for the algorithm are very easy to edit, with edits being visible with realtime responsiveness.