Wilbur is using the Planchon thing with a slight twist: anything below "sea level" is considered as not part of the area to be filled. This change allows the ocean to capture basins without too much odd filling. I keep meaning to allow selections to have a similar effect (areas outside the selection don't participate in the fill as opposed to the current technique of filling everything and then using the selection as a blend mask), but I'm a little time constrained these years.
One classic technique to the overlarge basin problem is to downcut the lowest point on the basin's edge. With a good basin-fill algorithm, it's not too bad: fill the basins in a temporary copy and then scan along the edges of the basin to find the outlet (a very slight non-flat slope in the lakes helps). Then drop the basin edge in that area by an appropriate amount and rerun the operation until the basins are a suitable size. This technique is also on my list of things to look at some year.
As I describe in the various Wilbur tutorials, I'm fond of running a process loop of basin fills to rough out the flow connectivity, white noise to rough up the flats, basin fill again to reestablish connectivity, incise flow to rough in the raw flow channels, a basic fluvial-style process to clean up the excesses of the incise flow process. The results are strangely plausible.
Sounds like a pretty good way to reduce the size of basins.....my fill sinks function has the same twist as yours, coincidentally. Also, I use a stupid "fill landlocked oceans" function before filling sinks which sets sea areas that cannot reach the edge of the map to the lowest non sea level height of its neighbour squares. Which probably is adding to my problems actually, but at least everywhere doesn't have lots of little "black sea" pits for all the rivers to flow into.
The fluvial erosion step tends to eat the smallest pits first.
Free height map viewer.
If your on windows, your welcome to use my height map viewer for this stuff too. Its a freebie:
ViewingDale - getting browser details...
Just save it in some folder and name your height maps height.bmp and run it up. If you press '2' then it should use 256x256 viewing which is pretty low res. '3' is 512x512 etc up to 2048x2048.
Thank you redrobes, I already have downloaded your software. I'm using sfml/opengl to render the maps though. There it is in front of me, laughing at me while it runs the erosion systems that don't work how I want boohooohooooooooo...
Right. That's enough terrain generation for a while I think...It's not exactly brilliant but it makes fairly interesting locations and you can hand-craft the heightmap if you want.
So now I got it to polygonize the rivers and lakes and generate contours. I was wondering if anyone can point me to a nice contour-hierarchy producing algorithm...you know, like "contour B is inside contour A, and contours C,D and E are inside contour B" and so on....(I already looked at openCV and didn't understand what was going on with that implementation, so...). At the moment they're a bit dodgy.
pic1.png
CONREC - A Contouring Subroutine is a classic, but any code that will generate contours on a raster will work. The idea is that you run a line along pixels of equal intensity. The cheap way to handle edges so that they are connected to other contours is to accept a surface that's one pixel smaller all around and set the outermost pixel on each edge to a value that's less than all of the rest. Assume that your heightfield surface is ranging from 0 to 255: a contour at 1 will be outside of contours at 5, which will be outside contours at 10, which will be outside of contours at 50, and so on.
It occurs to me that you might be concerned about purely interior basins (i.e. lakes with no outlet). My lazy technique is to do all of the regular land contours from low to high and then do contours on water from high. Land contours from low to high get progressively smaller, as do water contours from high to low. For your convenience it may be simpler to make a "water surface" where the shoreline of each lake is at 0 altitude and the depth of the lake goes down from there. That way all water is referenced to the same 0 point. With the water surface and the land surface, it's also just two contouring passes (one for land and one for water) to get all of the contours.
If you don't care about filled contours, it doesn't really matter what order you do things in.
Last edited by waldronate; 08-02-2014 at 03:40 AM.
Yeah, that reminds me. I need to see if Dragon Flight runs on Wine.Originally Posted by Redrobes
Astrographer - My blog.
Klarr
-How to Fit a Map to a Globe
-Regina, Jewel of the Spinward Main(uvmapping to apply icosahedral projection worldmaps to 3d globes)
-Building a Ridge Heightmap in PS
-Faking Morphological Dilate and Contract with PS
-Editing Noise Into Terrain the Burpwallow Way
-Wilbur is Waldronate's. I'm just a fan.
Yeah, I tried passing the tracing algorithm a map with a one pixel buffer around it with the pixels set to -99999. It works for most contours, producing nice connected shapes on the borders. But for a few contours, it kind of goes the wrong way...so I end up with a big contour that sort of goes in and out at the edges and makes a single contour when there should be five or six...don't quite understand why since the map is normalised between zero and one before this step.
Not quite sure I follow the bit about "contour at five will be outside contour at ten which will be...". A contour at height 5 will not necessarily contain a given contour at height 10, will it? Although it might, it's not guaranteed, and I need a guaranteed parent-child relationship between all contours....at the moment I'm running point in polygon tests, so I test all contours to see what contours are inside them. Then I run a test to see if a contour contains child contours that are also children of the children of that contour, and repeat until there is a structured hierarchy. It actually works, even if my explanation sucks, except for those contours I mentioned earlier that aren't being separated properly...
A heightfield is defined as a raster of heights. That means that it's not possible to have overhangs (it's one of the major drawbacks of heightfields). Consider the worst case: on sample at the minimum value and its neighbor at the maximum. If you trace contours using an interpolating checker, then every possible contour will pass between those two samples, each slightly offset from the next. If you use a contour tracer that's locked to pixel values, half of them will hit one pixel and half will hit the other pixel.
Now think about what a contour is: it is the edge of a constant-height surface If you pull out one contour and draw it as a filled element in white on a black background, then you should get exactly the same image as if you drew your original surface colored with all pixels at or above your contour level in white and all pixels below that in black. The contours are effectively slices of the surface. If you're getting interior holes in your contours, then you have basins. You have a basin-fill algorithm and a raster, which means the next part is pretty straightforward (if a bit inelegant): fill all basins in a temp surface and generate contours. These are the base contours and have no basins. Now make a temp surface that's just the basin deltas adjusted for the base level in the same way as the water surface I discussed before. Contouring that surface from low to high will produce contours that are children of the base contours. Then scan the water surface on top of that.
Note that it's a whole lot easier if you have polypolygons (polygons with others that punch out holes) available as a primitive. In that case, you just scan all of the polygons as a given height and the polypoly renderer does the grunt work.
Posting Permissions
Reply With Quote
