[Award Winner] Building a ridge heightmap in PS

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

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.

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!