[Award Winner] Building a ridge heightmap in PS

[su_liam]

Yeah, I got a copy of CS(1) on my happy laptop, but it's terribly buggy. I may get CS3(or CS4 by that time) when it doesn't involve taking food out of my children's mouths.

[su_liam]

So a ways back I found a reference by Joe Slayton of Wilbur and Fractal Terrains fame to a paper on a pitfill algorithm by Planchon and Darboux. Well, with some effort, I managed to track down a free copy of the paper he referred to. It has since disappeared, and the paper no longer appears to be available for free(Waaah!). After searching deeply into the musty bowels of google, I managed to find "A New, Faster, Scalable PitFill Algorithm" by Ted Dunsford and Dan Ames ad Idaho State University. This looks promising, but I haven't yet managed to examine it too closely. Implementing their algorithm would probably defeat my pitiful programming acumen anyway. Redrobes, however, might find this more useful.

I just think pitfilling could be a useful tool in eroding heightfields, or at least in preprocessing them for erosion. Especially if we can find a decently fast pitfill algo.

By the way, what's up with me-dem? I'm missing it.

[ravells]

I tried the method last night and ended up with something truly horrible (not worth posting here) ... I'll stay with it and see if I can improve!

[Redrobes]

This is interesting but its not the way GTS is doing things. GTS is a physics sim. Very simple thermal / fluid dynamics with some vegetation heuristics. It runs everything together all at the same time. Most apps and this paper talk of algorithms that are used in isolation - like finding the pit fill, then using that information to jump to the result that you would have got if you had poured water in until it overflowed. It would be two orders of magnitude faster but it would not have calculated all the in between stuff and the other non water effects at the same time. There was a training video about somewhere that showed Geo Control doing this sort of thing. I cant find a link to it now tho.

Its very probable that to get a result on a terrain the size of MeDem then you would have to do these techniques. Maybe the way I am doing it would take just too long. The thing is I can't see this algorithm doing rivers or working out how much sediment went into the lakes etc. It is more likely the way you would need to use to sort out the large scale pooling of water tho.

The MeDem web site is down. Its been down for a while now after it got hacked and was temporarily a phishing portal. I know Monks is still doing a bit on the mountains and I am still working at GTS. I want to be able to make MeDem type terrains even if I make something other than the ME landscape with it. I would like a generic large terrain just for general RPG use. I could probably do what I want right now but the ME group have much more specific requirements and also need to keep the resulting terrain strictly to the reference map. Thats the main problem, creating automated terrain that has to fit exactly to a ref map made by somebody who freely admitted that it was drawn for effect rather than accurate geography.

[su_liam]

@Redrobes
I wasn't making any assumptions about how GTS works. Basically, it was a suggestion of one way in which you could massage the input heightfield so that GTS could work a little quicker. Realistically, most of the pits should be removed by a combination of the downward erosion of blockages and filling of pits with sediment. Of course, I don't know the algorithms you are using, so the Planchon/Darboux pitfill algorithm might slow your process down even more.

Interestingly, one of the slowdowns in the algorithm is the requirement that every pit be filled. For the purposes I'm discussing, perfect completeness is not necessary(after all, we do want some lakes here and there). That should speed things up. This MIGHT create a concentration of lakes in the center of your HF, which could be a problem. I don't know...

I think a combination of intelligent design of your input HF, fractal noise, preprocessing to try to remove pits and other obstructions that would slow down GTS followed by a faster run with the realistic operations of GTS, could be quite pleasing and realistic. I doubt the results would be exactly the same as running GTS across pure fractal noise, but it should converge to a convincing result much more quickly.

I've tried doing feature extractions on some of my noise-based heightfields. Even some of the nicer ones are obviously unrealistic when you look at the ridge and channel networks.

Most apps and this paper talk of algorithms that are used in isolation - like finding the pit fill, then using that information to jump to the result that you would have got if you had poured water in until it overflowed. It would be two orders of magnitude faster but it would not have calculated all the in between stuff and the other non water effects at the same time.

Well, yeah... Most of the scholarly papers assume that the actual process of making a realistic heightfield have already been done. Sure, it was a slow algorithm. It took a few billion years to get to where it is... Mostly, the pitfill algorithms assume that dry depressions are spurious noise. They also often assume that pits are going to be fairly small. After all, a single measurement error should only effect one or two cells at most. Unfortunately, the community that is interested in the Earth is considerably larger than the community that is working on creating realistic imaginary worlds. Therefore we have to pick the brains of that larger group on occasion to supplement the often great but still finite ingenuity of our much smaller group.

[monks]

Man, I'm following this convo with interest but this has all been discussed at extreme length on ME-DEM. I'd link to tutorials over there but the site is down. There are a crop of tools on the horizon that will essentially be one generation ahead of Bryce: World Machine 2.0 and GeoControl 2.0. Then there's terrain synthesis....something Joe Slayton has been chipping away at with some impetus from Howard Zhous' ppa algorithm. Bryce is a damn fine renderer but it's not a terrain modelling program. If you really want to do the job thoroughly and at scale, you have to use more than one app unfortunately.
You need:
contours: Global Mapper, Photoshop.
heightfield tools: vectors and isolines: WM2, GC2.
erosion: WM, GC, GTS.
water modelling/ output: GTS, GC2.
texture output: GTS, WM2, GC2.
renderer: TG2, Bryce, Vue.
GIS: Global Mapper.

The best all rounder imo is L3DT. Not to forget Wilbur- now that program can do a LOT- and a perrenial favourite of mine, Fractal Terrains.

Robes you thief, 'modelling in the rain' was coined by me! World Machine 2.0 actually has this but in slow mo- and that's on a very high end machine (8800 GTX, Quad, 4 GB RAM). I reckon if we harnessed gpus for terrain modelling, we could see this as more of a reality.

monks

[su_liam]

"Unfortunately," and, "I'm on a mac," aren't things I often say together. In fact, I'm usually saying, "#$#$ POS," when I'm forced to use a PC. But, in this case, mac is a problem. Most of these apps are unavailable on a mac. I think Global Mapper is available, but it costs.

So I have a choice of buying a new computer(which also costs), using my limited programming skills to build my own set of tools(which is going slowly), or figuring out how to make do with what I have. This is an example of the last approach.

I saw a post about a Spectral Combine node in the WM2 development diary. I found myself salivating, not at the cool effect of the node(which was great, but unattainable at the moment), but the source he had quickly drawn in layout mode. If I could get that simple thing, I could set about adding noise in various ways to get a tolerable result. This is a step toward that. The next step would be an image loading node for planetgenesis. Then I could start work on an erosion routine.

Hopefully, at some point, I can make contact with someone who is both a decent programmer and interested in this field of endeavor. Vargol, the lead programmer for pG, is good, but very busy. I think his dreams for the future of pG are different from my own.

I really want to evangelize for planetGenesis here. Not just to users, but perhaps especially to people who might want to contribute. It's a small enough project that even someone with my own small skills in programming can be of use, but it is an open source project with great potential.
</rant>

[monks]

I've just been looking around planetgenesis. Cool idea and I hope it takes off. I have LOTs of ideas in this area Doing planet modelling on a sphere and with lat/long is a next step in this field. The renderers (TG2 and OGRE)/GISers are already onto it. Then you have FT Pro of course- an app ahead of its time for sure.

When you model ridge networks, the best way to look at it is as watershed/ catchments. That way you have a good abstraction of the structures.
What I did is build a mountain range. Use real world terrains for visual aids. I combined ridge networks from the Alps with a base terrain.
The problem I found was that you need to provide for water flow in the initial hf input- sensible/ massaged, etc. This is *if* you're bothered at all about water flow- you might not be, or need to be. So I set up a base terrain with gradients that channelled water along the watersheds of the range. Think of each watershed as like a pinball machine. Ball= water, table = base terrain gradient. Paddles = ridge networks. So the water should be at least helped along in the right direction- but the results (insofar as waterflow) are yet to be tested....

monks