Apart from the modelling in the rain idea- where you have realtime feeback of fluid flow, there are other workarounds. We see realtime fluid is the ultimate approach because we're kind of terrain purists (at ME-DEM)- that is, you haven't really got a map (of any depth) without terrain. And that makes rivers for us important (well really fluid interaction the most important thing. Obviously there are others in the real world, but the two main ones are glacial action and water erosion). You could simplify that even more and say it's all about temperature gradients...which is really what drives GTS.
I like your idea regards rivers. Come the timne, I'd be interested in running that on our maps.
One workaround, is you could try run the erosion (a chanelling/incising erosion would be best
rather than a high sediment one) on the uneroded terrain to see where erosion was naturally
headed. Then use that as a guide to mark your river estuaries and your river paths on your
design map. Then when you run the erosion again, everything would connect up. I do this to
establish the main rivers, and then I add noise around the rivers and get the procedural
tributaries from the erosion as extras- the stuff I don't have time to do.
Other than contours- which require a particular kind of madness
..- I use a smudge tool
which I paint from the estuary along the river path into higher ground. You could automate that
I imagine. If you visualise the land as contours, the smudge tool creates ridges and valleys
depending on the land. You could automate that using input from a desigm map. Stepping through
pixels.
http://www.skindustry.net/medem/files/Temp/ContoursIdea3.png I also use a gradeint tool across a selection, but the smuge tool is the most reliable (but
it's the slowest!).
Robes also wrote a nifty river flow tool for GTS (which he's not mentioned) which takes a user
input vector map of where rivers are, and bascially shunts water flow along them- it was
created to solve the problem of flat areas (by artificially multiplying the flow magnitude)-
they're the killers, it's difficult to avoid them with large "realistic" models. But with
interpolation across contours you can minimise them.
Given a design map and some programming, rivers to order should not be *that* difficult if you
hook up the two in the programming. Get the main rivers with the design map, and then the
tributaries will follow procedurally.
Ideally, for these large worlds, you want tools which are vector based- rivers included.
It strikes me Games have just not given any priority to rivers before; understandably. But really rivers are
where it's at if you talking about pure, realistic terrain. They define connectedness and
geography. It's what makes a world.
...Tolkien wanted other people to collaborate on his world. His famous statement about "Other
hands". The internet is the perfect platform for that vision. He did become "crest fallen"
about that in later years though, as nobody did add to his creation.
There was a moment in Tolkien's life where he to make the decision between "cash or kudos" as
he put it. I think he chose cash and as a father of four with a sick wife who was put upon for
many years lecturing, I don't blame him
Tolkien would have tolerated the non-commercial fan work- I don't doubt that. The problem was,
not that he was avaricious, but that he had very high standards. I think Tolkien would have
hated what the lawyers do- what they do amounts to political control, and Tolkien loathed
politicians- it's well documented.
I agree if you're making a game (I wasn't sure if you was), then it'd be risky to use anything
M-E shaped in it. But if you need terrain, you could use it with some modifications.
It'd be great (awesome) to make movies in the engine. And as RedRobes said, it really wouldn't
rebound badly to you guys. And, the tools testing, yeh
monks
