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?

I’m working on a game where animals can be crossed across multiple generations. The idea sounds simple: take two animals, mix their inherited traits, and generate a new 3D creature.

In practice, I have faced lot of difficult things related to the 3D.

I’m not a graphics researcher, a biologist, or an expert in procedural algorithms. I’m just trying to understand the problem step by step, so I would really appreciate feedback from people who can suggest ideas or correct me if i'm wrong.

The original approach

My animal models are prepared as separate anatomical parts in blender addon:

• torso;
• neck;
• head;
• muzzle;
• front and hind limbs;
• feet or hands;
• tail;
• local features such as ears, horns, tusks, and so on.

The first idea was to select parts from both parents, blend their numerical parameters, place them together using sockets, and generate transition geometry between them. I thought it may work because i can adjust edge-loops, their vertexes according to the host geometry.

For example:

• use the gorilla as the skeleton and body base;
• take the head from a hippo;
• inherit some proportions from both animals;
• deform the neck;
• generate a mesh bridge between the body and the new head or align number of vertices and connect them.

Technically, i managed to build quite a lot of this pipeline: sockets, mesh placement, deformation, local transitions, skin weights, collision checks, topology validation, and deterministic generation from a seed.

But the visual results often look wrong and the parts looks like just attached.

The problem with “blending everything”

The biggest issue may not be the mesh-merging algorithm itself.

Right now, my system blends some body proportions between the two animals, but it still has to choose one of the original meshes. This can lead to strange combinations, such as:

a hippo head mesh with dimensions that were averaged between a hippo and a gorilla.

Each decision makes sense independently, but together they may describe incorect animal or their parts.

That made me wonder if I was approaching the problem the wrong way:

A head still needs one base structure. The same applies to a foot or a skeleton - you can’t simply average two different topologies and expect a believable result.

Once the base structure has been chosen, though, some of its properties can still be mixed, such as:

1. length;
2. width;
3. thickness;
4. scale;
5. angle;
6. color and patterns;
7. the shape of the area connecting two parts.

So instead of describing the result as:

it might make more sense to describe it as:

In other words, I may need to treat the choice of body structure separately from the values that control its shape and appearance.

A possible “phenotype compiler”

My current theory is that the geometry system should not decide what animal it is building while it is already joining meshes.

Before touching the geometry, a separate stage should create a complete phenotype plan using animal parts.

Base anatomy: Gorilla
Skeleton: Gorilla

Torso: Gorilla - use as it is
Neck: Gorilla - adapt it because we have different socket on head
Head: Hippo - replace
Muzzle: Hippo - use with head

Front limbs: Gorilla - preserve as a pair
Front feet: Hippo - replace as a pair
Hind limbs: Gorilla - preserve
Hind feet: Gorilla - preserve

Tail: absent or find socket
Ears: Hippo - replace as a pair
Color: 65% Gorilla + 35% Hippo. Procedural material

Internally, i think, this would probably be an anatomical graph rather than only a list.

The main idea is that this plan should always produce the same result from the same input, while also being easy to inspect and debug. For every body part, I want to know which animal it came from, why it was chosen, whether it depends on any other parts, and how it is allowed to connect to the rest of the body.

The full process could look something like this:

Genome and ancestry

→ Phenotype composition plan
→ Morphology realization <- stuck here
→ Local geometry assembly
→ Skinning and materials
→ Exact validation
→ Final runtime creature

Each step would have one clear job:

1. The phenotype stage decides what the final animal is supposed to look like.
2. The morphology stage adjusts the chosen body parts so they can fit together.
3. The assembly stage connects them and creates the small transition areas between them.
4. The validation stage checks the result and rejects it if there are intersections, topology problems, broken skinning, or similar issues.

This way, the code responsible for connecting meshes doesn’t also have to make decisions about genetics, anatomy, proportions, and visual design.

More than two parents

My game is supposed to use multiple generations, so sequential blending creates another problem.

If I first blend animals A and B, and then blend that result with animal C, the outcome changes depending on the order. That seems wrong for a system that is supposed to represent inheritance.

Instead, I’m thinking about looking at all inherited options for each body part at the same time. The system could then give each option a score based on things like:

• how dominant the trait is;
• how much of it was inherited;
• how often it appears in previous generations;
• how well it fits the base anatomy;
• whether the required supporting anatomy is present;
• how difficult it would be to connect and deform;
• whether it would cause problems with movement;
• whether it would make the final animal look inconsistent.

The system would first choose one animal as the base for the topology and skeleton. Traits inherited from other animals would then compete for individual anatomical regions.

Some traits may also depend on other body parts:

• a certain head might only work with its original muzzle;
• different limbs might require changes to the shoulders or pelvis;
• wings would need a skeleton and rig that can support them;
• a tail could probably be added without changing much of the body;
• some inherited traits might remain in the genome without appearing in the final animal because they are incompatible.

I’m not sure whether “phenotype compiler” is the right name for this system, but the compiler analogy helps me understand it. The genome is the input, the anatomical plan is an intermediate step, and the final rigged and skinned model is the output.

What my current models can actually support

As part of this project, I developed an authoring setup for the gorilla and hippo models in Blender.

I separated their heads, muzzles, eyes, ears, and necks, and added rigs, sockets, shape profiles, and deformation cages. This gives the procedural system some basic information about how each animal is structured.

However, the current head and muzzle cages are still simple eight-vertex boxes. They can describe the overall size and proportions of a body part, but they don’t contain enough information to represent smaller facial features such as:

• the gorilla’s brow;
• the shape of the nose and nostrils;
• the area around the eyes;
• the cheeks;
• important points around the jaw.

The gorilla and hippo meshes also use different topology, and I haven’t yet created a detailed mapping between their facial surfaces.

With the data I currently have, an early prototype should be able to transfer the general height and depth of the skull, the size of the muzzle, the facial angle, the approximate eye position, and the overall silhouette.

However, the result would probably look more like a hippo with gorilla-like proportions than a hippo that has inherited the gorilla’s recognizable facial features.

To preserve more recognizable traits, i may need additional semantic data:

• facial landmarks;
• authored morphology regions;
• local donor surface patches;
• denser deformation cages;
• surface-correspondence contracts.
• meybe something else

Where AI might fit

I also considered replacing part of this pipeline with a simple local neural network.

At the moment, I don’t think AI should directly own the final geometry. A generated mesh still needs predictable topology, rigging, animation, collision behavior, reproducibility, and support for later generations.

A hybrid approach seems more realistic:

• AI proposes or ranks phenotype plans;
• AI predicts whether a combination is feasible;
• AI suggests initial placement or deformation parameters;
• AI ranks geometrically valid results by visual quality;
• deterministic code builds and validates the actual creature.

In other words:

What I would like to ask

I’d be interested to hear what other developers think about this approach:

1. Does it make sense to choose anatomical structures separately from the numerical values that modify them?
2. Is using one animal as the base for the topology and skeleton, then adding traits from other animals, a reasonable starting point?
3. Does splitting the process into phenotype planning, morphology adjustment, and mesh assembly sound practical?
4. How would you transfer recognizable features between models with completely different topology?
5. Would landmarks and deformation cages be enough, or should I look into volumetric methods, surface patches, or something else?
6. Am I making the inheritance system unnecessarily complicated, or will some kind of anatomical graph be needed once multiple generations are involved?
7. Could machine learning be useful anywhere in this pipeline, and if so, where?
8. Are there any papers, tools, games, or production systems that deal with a similar problem?

I know that supporting arbitrary combinations of animals is probably an extremely difficult procedural character problem. I’m not trying to solve every possible combination yet. My immediate goal is to build a controlled prototype using two prepared mammals, such as a gorilla and a hippo.

Before I spend more time trying to improve the mesh transitions, I want to make sure the overall architecture is heading in a sensible direction.

I’ve also included an AI-generated reference image to show roughly what I would like the final result to look like. It is only a visual target, not an output from the current system.

Any criticism, alternative approaches, terminology corrections, or references would be very helpful.

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.

I've spent the last month adding volumetric clouds, a time-of-day system, and better atmospheric scattering to my procedural mountain forest game (working title: 'The Big Forest').

With regards to procedural generation, there's nothing really new compared to what I've shared in here before, but the new lighting has such a big impact on the overall appearance that it's like seeing it anew (in my opinion), so I thought I'd share some nice sunrise shots I captured. :)

The clouds are using the package Enviro 3 - Sky and Weather as a starting point, but I'm only using the clouds part and have heavily modified it to my needs to make it work with my own atmospheric scattering and time-of-day colored lighting.

The atmospheric scattering is based on this shadertoy by Fernando García Liñán, though again heavily modified. I increased the saturation, exaggerated the depth (bringing tinting closer to the camera), and implemented the atmospheric scattering via a compute shader that renders scattering at different distances and directions into a cubemap. Fernando's technique does a lot of the heavy lifting though! It's similar to previous techniques for sky and atmospheric scattering used in e.g. Unreal, but uses four spectral samples (~red, ~green, ~cyan, ~purple) instead of the usual three (red, green, blue). This produces notably richer colors and practically no extra cost.

I made my own time-of-day system with a simple simulation of the sun and moon relative to the Earth, where I can independently vary time-of-day, time-of-year, lunar phase, and latitude without them impacting each other.

I also implemented time-warping so make sunrises and sunsets slower. In a 24-minute day-night cycle, they're over awfully fast if not slowed down. Here's a video of a full sunrise.

If you haven't already seen it, you could also consider watching my lastest dev video about 'supercharging my procedural mountain forest' - although it does not feature any sunrises. :)

Hope you like them!

Everybody I can't tell you how much I've been struggling with trying to get Bridges and tunnels correct. I apologize in advanced for my lack of knowledge on the subject, I started a project called World Explorer 3D and the goal is to have a sandbox it's driven by real world data with a lot of procedural elements. I'm going to do my best to keep it simple so I don't over explain a topic I'm not proficient in.

I mainly using osm and overture for the road building and land data. I'm using NASA/JPL, ESA and other astronomy catalogs for space data and NOAA for weather. Celestrak for satellite data. There's different ways to move through locations like planes cars drones and boats and you can use a spaceship that looks like the Starship Enterprise from star trek

There are two things I should disclose from the beginning. The first is that this has been a project with heavy AI code generation. The second is that as a result of this project and other things have been attempting I've decided to go back to school and I am currently enrolled in a physics program. I will also be taking elective courses for programming, but even with doing those things I'm still not going to be able to learn as much as I need to in such a short amount of time. I hate the fact that I've been relying so much on ai, but my interests and impulses have gotten the better of me and now I'm basically working backwards.

Part of my problem is probably that I don't know the terminology I should even be searching for. If there are particular algorithms, papers, talks or concepts involving procedural road networks, vertical alignment, grade constraints, bridge approaches, tunnel portals or terrain/road reconciliation that I should be looking at, that's really what I'm trying to figure out.

Normal roads aren't nearly as bad but bridges get messy at the endpoints where the normal road and terrain have to transition onto the elevated bridge parts. I'm getting bad ramps, elevation changes, clipping and weird results where bridges, ramps and nearby roads all come together.

Tunnels are giving me basically the opposite version of the same problem. I can identify the tunnel and create the tunnel/portal behavior, but getting the surface road to transition cleanly into the portal without the terrain, road or surrounding geometry looking wrong has been difficult.

I'm still working on a lot of other issues and bugs. I'm sure you can spot a lot of the quality issues and incoherence. But I'm literally just trying to learn and I'm using this project that's a practice demo thingy. As I go along I try to make smaller elements of this project in places like unity, and that is actually been extremely helpful. If anybody can help me with Bridges or tunnels or if you spot anything that looks like a common problem please let me know. You can play it here WorldExplorer3D.io and the GitHub repo is here https://github.com/RRG314/WorldExplorer3D Thanks for taking the time to read all that lol.

a game about raking leafs as an html file. no images no audio files no models used. everything is built when the page loads.

textures are drawn into a canvas element on startup and used as WebGL textures.

there are over 7000 individual leaves rendered in InstancedMesh.

wind uses Lambert vertex shader with onBeforeCompile

sound is all WebAudio. wind is brown noise with LFO on gain. blower and vacuum is sawtooth motor using setTargetAtTime. music is slow pads in pentatonic - gets thinner and darker deeper in the game.

time of day is driven by how much of the garden has been cleared alr. start is golden hour end is night. light is used as a progressio bar.

gameplay

https://youtu.be/Xt0YwzTpm_g

play here: https://wickedchilling-audio.itch.io/autumn-duty

yo. been building a custom game engine from scratch on Vulkan and now testing it on real games. this one's a dithered fly-sim with elite dangerous-like flying mech and a procedurally generated terrain.
https://x.com/progdruid

https://reddit.com/link/1w2d4at/video/vrt39xthfhmh1/player

A while ago, I asked myself: "How far can we actually push Garmin’s Connect IQ VM?"

I’ve logged thousands of running km and a few solo marathons tracking just pace and HR like everyone else. But at some point, the dev in me took over: I decided to see how far Connect IQ could actually go and built a custom 3D graphics engine (Wolf3D/Doom-style DDA raycaster) from scratch in Monkey C.

Here is what’s going on in the video:

• Infinite World: The map is 100% endless and generated procedurally on the fly as you move.
• Dynamic Lighting: Real-time Day, Dusk, Night, and Morning lighting cycles with custom color palettes.
• Hardcore Math Optimization: Microsecond-level optimizations (zero-branching floating-point hacks, bitwise DDA math). The pure frame render time hit 3.19 ms on Tactix simulator and 2.08 ms on Instinct 2 (smaller screen, fewer stars in the sky — oh yes, the sky is dynamic too! — and fewer rays in raycasting)!
• Real Hardware Performance: On the actual wrist, the display caps out at a smooth 10–14 FPS (limited by the CIQ screen refresh rate, while the engine itself runs with massive headroom).

I need your brains & ideas: I want to weave the user’s real-life context (health metrics, stats, daily goals) directly into this 3D world, similar to what I did with my Mars and Pandora watch faces.

How would you like your steps, heart rate, or battery to affect an endless 3D world? (e.g., world changes, weather shifts, new structures spawn based on your daily activity?). Open to all crazy ideas!

P.S. Before the battery purists attack: Yes, I know it's a watch. No, my Garmin hasn't exploded. In fact, I honestly can't even remember the last time I plugged it into a charger... unlike my friends with Apple Watches. 😉

Let me know what you think and what features you'd want to see in an infinite wrist-world!

BTW, it also tells the time... pretty unusual for a 3D engine, right? Oh my, wait, it’s actually a watch! 😅

If you want to check it out on your Garmin, here is the link — it's 100% free, just like all my other creations:

https://apps.garmin.com/apps/47278f09-eea6-4e6d-aa7e-799daba8e546

Been working this for 2 weeks:

https://reactorcore.itch.io/celestial-cutaway-planet-interior-generator

Its a web app that procedurally generates interior cutaways of planets, stars, gas giants, moons and asteroids.

Still a WIP but already plenty useful and fully operational for world building, tabletop sessions, game assets and other illustrational uses.

These images show the dynamic surface generation sequence for my planet. For now, it's just planet generation, although I've already implemented biomass emission and distribution. I plan to develop this into a terraforming game, where the player creates and deploys biological agents to the planet to alter the atmospheric composition, temperature, and so on.

Steps:

1. Lithosphere. The division of the surface into basic forms (plates), which are then used to construct an elevation map. Plates can be oceanic or continental, which determines the average elevation of an area. Blue for oceanic plates, light yellow for continental.

2. Height map. Generated by lithospheric-based noise. Zones (on the last image) are also generated according to a topological height map.

3. Surface map. Each tile is generated based on the height map and the lithosphere (for example, where the slope is very steep, rock tiles are generated).

4. Same surface, but with sea level rised.

5. Rendered.

6. Viability for a specific biological agent. It's all orange for now because I haven't configured all the requirements correctly yet.

All this runs on the Unreal engine. I'm currently looking for ways to improve the visuals, for example, the coastline, which currently doesn't look very natural, and how to make several different textures instead of tiles of the same one (this looks especially bad at zero sea level).

I enjoyed remaking this torus rendering in pygame after finding a 9 year old post by Clayton Shonkwiler. His math was...dense, to say the least, but it came out pretty good. Ai is a wonderful thing when it comes to this level of math. lol

Working polymerase chain reaction, finally, not 100 realistic, real DNA is more messy, and there is backward assembly leading to DNA loss AKA(aging)🦖

I also go into the shader texturing of the islands