Thread: [Award Winner] Building a ridge heightmap in PS

Nice tutorial, thanks. I recently discovered this site and I've been excitedly playing with the tutorials here. I was following this one, trying to create a mountain range for a map I had planned, and ran into a problem.

I had several ridges close to each other in my height map sketch I started with:



Applying this method directly yielded an alienistic landscape with very smooth crater-like valleys between the ridges. This was generated using Photoshop's lighting effects rather than Bryce.



I think this is due to the dilate process used with the selection contract tool. Realistic earthlike mountains have valleys that are actually surprisingly sharp (check google maps satellite images).

The method I discovered after much button pressing was to alter the following steps:

Originally Posted by su_liam

7) Here's where that morphological Dilate tutorial comes in. A recap: Load the new channel as a selection, go to Select>Modify>Contract... I'll contract by 3 pixels, and iterate three times.

Save you selection as a channel and take a look. For the purposes of this I'm pretty satisfied. I'm going to munge it up using steps b3 and b4 and call it good for my current purposes.

Modify these so:

1) After you have the contracted selection, save it as a channel.

2) Load the channel you started the contract from. Invert selection (Ctrl-shift-I) and repeat the contract operation. Save this as a channel as well.

3) Create a new channel, fill with 50% gray. Load the selection from the channel created in 1) above, and fill with white. Load the selection from the channel created in 2) above, and fill with black.

4) Continue with the process, using this latest channel as the one you use for further steps.

With this, I came up with something that had way better valleys. A sample is below. I hacked this up very quickly for this post to keep it clear. To get nice ridges for high mountains, you need to pay more attention to getting a better initial sketch or do some magic with curves and such.

That's a problem I've been having with integration between mountains. It's a major reason I haven't been posting much on this lately(a little bit of my trial and ERROR process goes a long way...). I like the valleys in your modified version, but I think the mountains suffer. Although, those are terrific as hills or lower mountains.

Curves is good for small adjustments, in my opinion, but really significant curves force too much regularity on the landscape. My opinion.

I've been adding fractal noise with Clouds and Difference Clouds to try to disguise some of the problems, but, as I think Redrobes has noticed, this produces a lot of sinkholes, which just ruins the drainage. This is important if your trying to simulate decent erosion in less than a lifetime. And, at best, you still end up with something that looks vaguely like glacial u-shaped valleys.

One experiment I'd like to try would be to take the heightfields resulting from both of our methods, scale them in Levels and add them together. That could either(hopefully) integrate the best aspects of both methods or (unfortunately) amplify the worst aspects of each.

I'll try that when I get a chance. Tell you how it works out...

Originally Posted by su_liam

I like the valleys in your modified version, but I think the mountains suffer. Although, those are terrific as hills or lower mountains.

Agreed, but I think part of that was due to a bad sketch in my example... Here's a part of the map I'm actually working on at the moment. I actually ended up making the sketch in two parts, one representing the major ridge areas that got a large blur moving forward, and the second representing only the ridges. That allowed me to exclude the ridges from the valley generation procedure but include them in the final result.



I'm still not 100% happy with the hand drawn bit, but it's getting closer.

Other than the part of the process I described, I'm following your tutorial pretty much as written, including the noise bit.

The problem with having access to Photoshop alone is that not having any realistic erosion puts a limit on how far you can go with this without having to draw a lot of minor ridge areas by hand.

@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.

Originally Posted by Redrobes

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.

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

"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>

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

Those initial U shaped valleys look like an ideal representation of a glacial valley, however!

-Rob A>

I've been playing around with a variation of my previous method. It's not perfected, even to the standard of my previous tutorials, yet, so I'm not going to give a detailed method yet.

Basically, I created a top layer named Peaks. I filled this with solid noise(in this case Clouds followed by several iterations of Difference Clouds; still lazy) in a greyscale range from about 175 to 255. I'd like to do this in 16-bit, but I'm not sure any of the tools, even in CS, actually produce 16-bit variations. I put a black Layer Mask on this and drew in peaks using reasonably thin lines and a bit of Brush-Fu.

Below that, I created a Valleys layer. Same solid noise method, only with a greyscale range of about 0 to 80. This time I drew valleys in on the black Layer Mask using a dendritic method.

On the bottom, I created a Midrange layer. No mask this time as it's the base. I did solid noise at about a 88 to 168 range.

I applied a variation(that still isn't quite working for me) of the Ridge method I outlined at the beginning of this thread on the Layer Masks. I also tried to apply some of Gecko's idea for valleys from memory.

If I can perfect this method it looks like it will be a better, if more labor-intensive, way of hand-designing heightfields(given a limited set of tools). I'm hoping having a greater number of narrower(and more varied because of the clamped snoise) terraced greys will make it easier to blend together with lower blurs and narrower spatters. This should make it easier to maintain a desired geometry without having it melt away into a blurred, noised-out mess.

While I think this might be passable, in itself, I think it also might be a good start for a faster erosion stage.

For the moment I'll put up the resulting HF and a Gradient Mapped and Lighting Effectsed image. I have a Bryce render baking in the oven right now.