RmbRT said:
So there are really only 8 × 8 possible positions for a terrain feature within a cell at 3 octaves
That's wrong. The number of possible positions for a peak is practically infinite and limited only by the precision we use for the height values.
The grid resolution only constrains the number of peaks we can express, since we require 3 values to define a peak at all.
That's no nitpicking. It's really important.
RmbRT said:
But I want pointy mountain tops, sharp mountain ridges, but also smooth plains and also river beds etc.
You get them from the higher frequencies. To show sharp features, you need to increase resolution, so a round peak becomes small enough to look sharp.
RmbRT said:
Which are impossible in a purely FDM approach if I do not calculate the octaves and maybe even apply erosion or something.
You mean FBM i guess. (It means Fractal Brownian Motion. 200 years ago people believed heat is some kind of fluid flowing through matter. Later they detected atoms, and saw them jittering randomly. The wider the jitter, the higher the temperature. So it was no fluid, but actually the motion of atoms which caused heat. That's where the term Brownian Motion comes from afaik.)
But yes. Ideally you need one more octave each time you double resolution. So for a 256 x 256 terrain you need to call your noise function 8 times for each texel. But even if you do this at runtime it would be no performance problem. And as shown here, erosion can be done at runtime too. So what's your problem with doing it for a static world generated offline?
RmbRT said:
It's like vector graphics vs. pixel graphics. I want to determine the semantic elements of the landscape, and then generate the shape based on that, instead of letting all semantics emerge on their own.
Then let's go back to meshes and graphs.
Which conflicts with your goals: You want to use heightmaps. You want to understand nature and replicate its processes.
But nature does not use parametric patches to design shapes. Nature uses discrete small little things which interact.
Only after nature has done it's work, we can analyze the shapes, and fit a parametric representation so it reproduces the shape.
But you can not emerge natural creation from a representation which already defines the end result of this same process you want to reproduce.
Something does not fit together. You have to make a choice.
Do you want to define the end result like an artist does? Use Blender and model your dream landscape. (seriously - why not?)
Do you want to simulate or imitate nature procedurally, so the outcome gives you a landscape? Use the tools discussed here.
RmbRT said:
This semantics-first approach lets me easily add stuff like roads, rivers, and other things, because I can perfectly plaster them on the terrain without erosion or searching or anything. I basically know the path it will take a priori because I already know the exact semantic structure of the entire region.
Ok. I've got you wrong all the time. But i also don't understand why you use noise or randomness at all. I would work on an editor to model splines. Model mountain ridges, streets, rivers, some definition of elevation on a loop, etc. Your heightmap should grow considering such input. Noise may become useful at same point in the future, to add some details. But at the moment, your primary problem is to find a geometrical definition for your semantics?
Or is that not the whole picture yet? You rather want some procedural approach to generate those semantics on top of such system? A computer artist who can model those splines defining mountains, having some deeper understanding about how mountains form in nature? Something like that?
If so, then my opinion is: It is much easier and practical to simulate nature, so it gives you all that without a need for curves, patches, related adjacency data structures like meshes, abstract concepts such as semantics, and even artificial intelligence.
RmbRT said:
Of course you get more realistic results with erosion and all that simulation stuff.
Yeah, but that's irrelevant for now. You can always erode your stuff, no matter how you create it. Even i treat erosion as a 'post-process' in practice.
RmbRT said:
But let's say you want to build a town somewhere during the game, so after the landscape already exists. The terrain needs to be flattened out there retroactively. And let's say you then need to place a roadway connecting the town to another town.
Yes. That's exactly why i (and the games industry or Hollywood as well) believe in proc. gen. If i add a new street or river, i only want to draw a spline. Details have to be created automatically, changes in terrain may require re-simulation. It may take hours. But having some sleep over night is better than paying 100 artists to move some rocks around.
Anything i have proposed considers this obvious goal.
RmbRT said:
Multi-layer noise based terrain fails to clearly define its features, because it is a fractal.
It is a start.
Ofc. you can paint a low res heightmap, scale it up using noise to add details, then erode to make it look realistic.
You add a street? Rasterize it to heightmap, apply filters to flatten if needed. It's easy.
Or, personally i could draw heightmaps in a 2D vector editor like Adobe Illustrator. It can do this, extruding gradients towards a given loop, etc.
Or i could use a game engine like Unreal, which also can create / edit terrain from few splines. It can do it in real time, showing the the final result with all procedural texturing and bells and whistles.
One does not rule the other out. I can use all those tools in interchange.
Those tools are meant for manual design, and many implement proc. gen. as well. Houdini seems the king. It can do everything. Heightmaps, particles, SDF primitives, fluid simulations, creating entire cities, and you can use it to implement your idea about semantics. Many of those tools are available with fair pricing for indie devs. Many are even free. So if you don't know yet how to turn vague ideas into practice, look up for what other people, with the same vision and working on it for decades, already have achieved. It's inspiring, and low power HW targets do not rule out modern tools. See mobile games.
RmbRT said:
That meant to get cool looking mountains like Skyrim or something, I'd need high detail noise, which has exponential cost to generate.
I think i have already surpassed the mountains of Skyrim, using a 64W CPU for full blown 3D particle simulations.
I also had a game in the works for Nokia phones running Java. Car racing over a procedural terrain generated at runtime. Low fps, but it worked. Others run details erosion sim in realtime in a browser. Others erode entire planets generated and scaled up procedurally while you fly towards them.
And you say you can't create a heightmap from procedural noise fast enough? I don't believe it.
I've asked several times why you worry about perf., but all i know is your world is static, so it can be built offline.
So what do we talk about?
RmbRT said:
And what I'm generating is not strictly a terrain shape, but an entire world with artifacts of civilisation, such as towns, bridges, roads, trade routes, etc. My terrain needs to be shaped in a manner that explicitly allows the placement of a castle city in a meaningful location on a mountain within a cell.
Generate a distance field from your cities and roads, and use it flatten / raise / blend that noisy clueless terrain, to shape it into form at will. It's easy.
It really sounds you want to work on streets and architecture first. Surrounding it with some procedural terrain won't be that much of a problem after that, i think.
RmbRT said:
So where you take randomness and then post-process it to make it intelligible, I take intelligible things and make them look more real by adding randomness afterwards.
I do not use any randomness. I did those procedural noises only for fun, and the heightmap erosion only to learn about the process, so far.
Regarding architecture and traffic networks, i'd love to generate a dystopian city destroyed by earthquakes ideally. But i'll run out of time to work on this i'm afraid.