# Mapping Resources > Tutorials/How-To >  [Award Winner] Building a ridge heightmap in PS

## su_liam

Well, I'm going to start with a teaser, because I'm short on time.
This image was rendered in Bryce, but everything involved in the creation of the heightmap was done in Photoshop. No Bryce erosion, nothing.

It all started with a somewhat sperm-shaped stroke....

----------


## Redrobes

Ahh right !, your 'spread effect' makes more sense now. I'll be watching this one with interest. Monks and I have been hard at work on mountains for ages now. We have both taken different paths to them with the intention of merging. It would be fascinating to see your approach. They could do with a bit of erosion applied now but I bet you created that in just a few seconds. Being able to paint these ridges would indeed be a great step to better mountain ranges. My hand is reaching for the rep button already...

----------


## NeonKnight

Actually, with the colors already on them, they look and remind me of the Alberta Badlands and the Montana Badlands.

----------


## su_liam

@Neon Knight: Actually, the colors are existing materials presets in Bryce. The grey stony background was one I had slightly modified to make up for deficiencies I saw in the original.

@Redrobes: I wish it was seconds, but it was still not too slow by my standards. Adding erosion would be good, even with the somewhat limited tools I have. I _did_ see some interesting erosion-like features that showed up in the original. That makes me think a little bit of subtle smoothed erosion with bryce would look pretty nice.

*On with the show!*

Here goes.
I'm going to start with a new document. This time, as an experiment, I'm going to forgo my typical sperm, and try something a little different. Say Hello to our next mountain range. Now lets rasterize that. Then we Select All(Cmd-A on Mac, I think ctrl-A on PC) and then we Copy Merged(shift-cmd-C on Mac, presumably shift-ctrl-C on PC) and Paste(cmd/ctrl-V) into a new layer where we can play with it like a cat with a rodent.

1) Begin with Gaussian Blur. I'm going to use a 12.4 pixel radius. I just want to get a bit of gradation to get the ball rolling.

2) Now I'll use Filter>Brush Strokes>Spatter... with a Spray Radius of 12 and a Smoothness of 1. I could use my Spread method, but I still haven't created the Action so it's time consuming, and I'm not sure it has any advantage for Radii below 25.

Here, I have a couple options
a>
	a3) Gaussian Blur at 1.3 pixels.
	a4) Spatter at a radius of 12 and a Smoothness of 5. *Note*: All these settings will vary with the image. What we want here is to ramp up the clumpiness. If this thing was rendered now it would probably look like hammered metal rods.
	a5) Gaussian Blur 1.3 pixels.
or
b>
	b3) Spatter at a radius of 12 and a Smoothness of 5.
	b4) Gaussian Blur at 1.3 pixels.
	b5) On inspection, I like the results of the B branch better. It looks a little mungier. I'm going to follow this track.

6) Select All and Copy(just cmd/ctrl-C) now move over to your Channels palette, create a new channel and paste into that.

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.

 :Cool:  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.

9) Well, not quite. I'll want to add a little fractal noise. So let's Paste this abused, dilated, brutally munged text onto a new layer at full opacity and normal mode.

10) Create a new layer on top of that. For simplicity, and to keep up the all-photoshop thing, I use Filter>Render>Clouds_ in black and white. Now, I'll iterate Difference Clouds several times on top of this.

11) Set the mode on this top layer to Multiply. Play around with the opacity.

12) Just for giggles, I'll leave the opacity at 100% and bring up Filter>Other>High Pass... on my cloud layer. I really like the look at a Radius of 15.7 pixels on that High Pass. The high pass damps out the big low frequency variations that aren't related to our desired ridges, but are big enough to overwhelm them. This leaves us with the little variations that add interest, but are small enough both in spatial scale and amplitude to fit into our ridges.

13) I like this look, but it's getting a little dark. So I'll add a Levels adjustment layer.
I hold down the alt/option button while I drag the white point arrow(the one on the under the left side of the mini histogram this will show me when I'm driving non-white pixels to white. The image will go to black and I will drag until I see some white pixels. At that point, I pull back a bit so the screen is all black. In my case, this will put the white point at 145, 57% grey. Things _were_ a bit dark.

14) Finally, to make my ridges pop, I add a Curves adjustment layer. I create a curve that's concave to make the tops pointier. I notice on the histogram that my highest level is now 251. Meh, I'll live with it.

Optional Step) Take this into Bryce or whatever app you have that includes tolerably good erosion tools, and add a bit of erosion.

This took me a couple of hours including false steps and the process of documentation. If, unlike me, you have the good sense to create Actions, and you're not flopping about like a fish trying to figure out how you did this last time, I'm sure this could be done in less than an hour.

If you have access to good, specialized heightfield manipulation tools, this might not be worth the effort, but if your tools are limited to photoshop and the terrain editor, this is pretty darn attractive. I think so anyway.

----------


## su_liam

Here's more of my images. Dealing with the five image limit.

Oh! I intend to add a Bryce rendering of this whenever the computer is finished playing wih it.

----------


## su_liam

Okay, here's my rendered image. I like it generally, but the tall peaks look a little too zauberland for my taste. I think my curves adjustment might have been a bit much. I'll try fixing that and then maybe applying a little bryce erosion 'magic'.

----------


## pyrandon

Awesome!  This is hugely helpful!

And, just to make your life more complicated, if you ever felt like it and had time I'd love a bit of a addendum to this showing how to do this sort of thing in Bryce.  I own Bryce but have never been able to (ie, never taken the time to) learn how to do anything with it.  Helpful hints, rudimentary processes, etc...  Like I said, what you've done is awesome and immensely helpful, but if you ever get bored...   :Wink: 

You rock, Colin!

----------


## su_liam

Thanks for the kind words Don!

I'm still kind of working on this heightmap here at Chez Paddles. First, I think the curves adjustment layer _is_ better *under* the clouds layer. The clouds help to weaken the kind of regular smooth curvature they impose. Second, this heightmap honestly seems to look nicer without the curves altogether... Third, a couple more rounds of spread/clump/blur/contract would help oodles. Finally, as Redrobes has already said, a little erosion, even with bryce's erosion tools would make this thing pop nicely. Also, as a little addendum, mountains might tend to look better if they're not sitting on an infinite, perfectly flat, plain.

As  time permits, and as I think of anything remotely useful, I'd be perfectly happy to provide tips on Bryce. I'm afraid _rudimentary_ processes are the only kind I know.  :Smile: 

Later, folks...

----------


## RobA

That works pretty well!

I'm still playing but this is what I have managed so far...

-Rob A>

----------


## su_liam

Nice work RobA. I assume your using GIMP and, maybe povray?

It seems less clumpy/hummocky than my results. I presume your blurring it and then using an iteration of spread/blur/dilate. Part of the difference is that I think the dilate filter in GIMP is strictly 1 pixel at a time. If I understand Dilate properly, the single pixel dilate, or contract basically looks at a 3x3 neighborhood around each pixel and sets the pixel to the smallest value it finds(Erode or expand sets the central pixel to the _highest_ value it finds. With a radius of 3, as I've been using, contract finds the smallest value in a 7x7 window this is naturally clumpier. I've also been using a second pass with the Spatter filter with a higher smoothing value. This can be simulated nicely in GIMP by using a pass with the Pick filter after the Spread. Hopefully, that might help, if you WANT the more hummocky look. Also, adding more fractal noise at the end with clouds makes a difference.

Actually, I've been meaning to do an experiment with a more conservative spread and blur, no intentional clumping stage, and a slower, but less clumpy radius 1(3x3) dilate. I'm hoping it would make a good approximate way to remove terracing. Better than my previous erosion idea. Still not so good if you want an exact interpolation, but hey...

I think I'll call it the Stochastic Deterrace Algorithm if it works. Heehee!

----------


## su_liam

Hi in the vast Himalayas, water, wind and ice have conspired to create this odd formation.

I put a High Passed differenced Cloud fractal under a blurred, noised and dilated text layer. The text is applied using Linear Light(additive) mode. In Bryce, I applied(perhaps too much of) both types of erosion.

----------


## pyrandon

This is amazing!  Ok, you've convinced me:  I need to play with these apps and your process!

----------


## su_liam

I'd give my left pinkie and two toes to be able to do this in 16-bit. Or better yet 32-bit float...

----------


## Redrobes

> I'd give my left pinkie and two toes to be able to do this in 16-bit. Or better yet 32-bit float...


Heh heh - GeoTerSys is float...  :Smile: 

Anyway, I was going to say that this looks just great - thats some nice erosion effects there.

We have found that getting from this stage to the next is where it gets hard so ill pick your brains. In a real landscape the water runs downhill and pools up. In almost all systems the app does not compensate for this which is why I was challenged to write GTS in the first place. What we have seen is that in almost all terrain you get lots of huge pools. We have a solution but I'm telling ya that GTS takes ages to run and if we could feed it nearly right terrain then it could fix it up a lot faster. Do you have any tips n tricks so that the valleys in these mountain ridges would form terrain that would not pool up water. Sorta glacial U shaped ones. I know thats a tall order but thats what I am up against - not just providing it but providing it at a rate thats not so stupendously slow that its going to take multiple years to generate.

If your more interested then post the grayscale heightmap of the Hi in the mts and ill post some more.

BTW, Can't Bryce use 16 bits formats then ?

----------


## su_liam

Bryce accepts 16-bit formats. Photoshop is the problem. PS7 can _open_ 16-bit files, it just can't _do_ much with them. Possibly, you could create an 8-bit file in 512x512 resolution(for example), and interpolate it up to a 16-bit file in, oh, 4096x4096 with GTS, perhaps?

Erosion is kind of a sore point with me right now. I just spent more than a month trying to implement linear precipiton erosion in planetgenesis, and I have nothing to show for it but a huge mass of nonfunctional kludgy code that I just don't understand anymore.  Too many little hacks trying to make it work rendered it incomprehensible. I'll have to start over from scratch, but I'm not up to it at the moment. If I ever get that going, I have some thoughts about using a pit-fill algorithm to find an edge to the lake and then erode the pit down starting from the low point that stops the pit-fill. Still a little  nebulous, and I haven't put much thought into it while trying to get the $%#@ precipiton to work.

I wonder if geologically very young areas more closely resemble the results of applying fractal noise. Maybe hills could be gradually built up in user defined areas with frequent erosion steps in between? Hmmm...

I've been playing around with some ideas using gradients combined with a variation of this method to do something along the lines you're talking about. No great breakthroughs so far. Even if something pans out, I really don't have anything algorithmic, more kind of painterly case-by-case judgement call things. If anything works out I'll definitely put it up here. My grotesquely overdeveloped ego demands it of me.  :Wink: 

Wish I could give you more. I'm definitely working on it, though.

----------


## Redrobes

I hadn't realized you were trying to code a solution for this kind of stuff. I was hanging out on the terrain summit site chatting to the me-dem group when they said that they needed to calculate rivers. I had my program geomorpher at the time which could not do rivers. It did mountains and some erosion but I had all the framework there and thought hell, how hard can it be ? Well neigh on impossible is the answer. I have been hacking away at this for about a year and the progress is slow - the latest stuff has been a near precipitous climb though the other day I made a partial break through - I have no doubt that there are more obstacles ahead. I reckon I hang out here so that it diverts me from having to face it any more.

We were talking about image magick. There is the 16bit internal processing version of that available. What I tend to do a lot is draw stuff like the squiggle and use programs like IM and my texture compositor to script it through to something else. IM ought to be able to take the 8 bit brush strokes, do the splatter and gauss stuff in 16 bit and then output into some 16 bit format therefore avoiding Photoshops limitations.

That bit about the building it up has been discussed at length too. I have dubbed it "modeling in the rain" where you make changes and see how that affects the hydrology and then make more changes whilst its eroding it down. I still think this is an excellent way to go but its so slow for me to run it that its not tactile any more. Part of the ongoing effort has been to try to do this with multiple stages using tiles where we run a tile sim for a while and then blend all the tiles back together, cut some new ones and go again. We have also been chatting about lots of CPUs, lots of cores, using GPUs etc all in order to drive up the speed to get the interactivity needed to model in the rain. That seems like a million miles away right now tho.

----------


## HandsomeRob

> Bryce accepts 16-bit formats. Photoshop is the problem. PS7 can _open_ 16-bit files, it just can't _do_ much with them. Possibly, you could create an 8-bit file in 512x512 resolution(for example), and interpolate it up to a 16-bit file in, oh, 4096x4096 with GTS, perhaps?


The most recent versions of photoshop (CS2 and CS3) have the ability to do much, much more with 16-bit files. There is not complete functionality yet but it's very close. So you may want to upgrade!
-Rob

----------


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

----------


## Gecko

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:




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

----------


## su_liam

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

----------


## Gecko

> 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.  :Smile: 

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.

----------


## 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!  :Very Happy:  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  :Smile:  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.... :Smile: 

monks

----------


## RobA

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

-Rob A>

----------


## su_liam

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.

----------


## su_liam

> 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:
> 
> Attachment 2356
> 
> 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.
> 
> Attachment 2357


Here's a real life shaded relief by Tom Patterson of shadedrelief.com



Of course, this is from the Grand Tetons, so it doesn't do much to refute the "alienistic" statement.  :Smile: 

I finally managed to get a "16-bit" version of my heightfield into Bryce. B6 doesn't seem to like 16-bit tiffs or pngs from PS CS. It seemed to do pgms okay, but I couldn't figure out how to convert photoshop output into pgm. The method outlined in shadedrelief required an app called bsmooth. I refuse to pay as much for a Classic app that hasn't seen any changes since 2001 as I paid for Bryce 6, and the trial version is limited to 196x196(?)! Then I found the CartoPGM PS plugin on reliefshading.com. So here's the result...

----------


## su_liam

So I was looking through my HD yesterday, looking for stuff to trash prefatory to a little defragmenting of the HD. My laptop's been a little slow lately, seriously shortbus material. Anyway, I find a copy of the Vue 6 Infinite PLE. Well I can't really do much on it. With the time limit expired, I can't even render bigger than 320x240. But I decide to look at it's terrain editing. Wow! The editing is hugely superior to that of Bryce, and the erosion tools? Ohhh! Diffusion, Thermal(I haven't been able to see a difference between Diffusion and Thermal, but they work okay for plain vanilla 1998 soft erosion), Glaciation, Wind(kinda weak, actually), Dissolve(looks like precipiton from the ground up), Alluvium(the true killer app here... sexy...), and Fluvial(basically top-down Dissolve). Hoot mon, it's sweet!

I import my old noised, "Hi," terrain into Vue and start playing. Now the vue renerer seems to do well with tiny 256x256 terrains, which is good 'cause things get a little slow with larger terrains. So I downsample my original down to 512, which is a good tradeoff between speed and detail.

First off I use dissolve and fluvial at high hardness to start building channels to drain the many basins. I use a lot of alluvium to fill in the lakes from the other side. Most of my basins fill in and and break through pretty quick, but there are a few deep pits that hold out obdurately. No matter, I look for the lowest point on the periphery of each of those basins and use the Paint brush in Dig mode(small, soft, low flow) to give those an exit. I then use Fluvial and/or Dissolve to erode out channels, and then Alluvium, again to get the lake draining out. Tool marks are quickly obliterated by the canyons formed when the alluvium comes pouring out. It can be quite impressive to watch. A little bit more Dissolve, Fluvial, and Alluvium for good measure. I then use the x2 button at the top of the Terrain Editor to upsample the terrain to a more useful resolution. Before I export I run a little Alluvium to detail things. Don't use Dissolve or Fluvial at this point, they tend to make pits and it's slow as hell to fill pits at this resolution!

Now I hit the export button at the lower right side of the Terrain Editor. I select PNG as the object type go ahead and experiment with other types. When assigning a name for a PNG it's important to hit the browse button. The program crashes otherwise! Once you select a name, Vue asks you for Picture Format Options. I chose 65k Colors and High 100%. Hit OK and your back to Terrain Format Options. Now choose whether you want to generate material maps, and, if so, what format. Hit OK. This is the end of what I can do in the free version of Vue. Did I mention this was free?

Now to Bryce. Create a new terrain and open the Terrain Editor. Use the pictures tab to import your png. In retrospect, I'm not sure Bryce imports PNG as 16-bit. It might be better to open your png in Photoshop and, with the CartoPGM plugin, save to pgm, then use File>Import Object... to import the pgm into Bryce.

After getting my terrain into Bryce I open the Terrain Editor add a little Height Noise and a little Slope Noise then I Erode it a bit. Blur it slightly and use the grid control to upsample to 2048. Now I add a smidgen of Slope Noise(only) and a touch of erosion.

Next I found a nice material from my personal collection of saved materials and render at moderately decent quality. Have a look...

----------


## Asharad

Nice tutorial.  Here is mine.   No Bryce.  All photoshop.  I see potential with this!

----------

