Hi

I have looked into it and got the attached image (I do not know if you 
expected that, I think not, although one can see the structure). You 
were mistaken in edge_points (about line 77). Please look what I have 
changed in the attached version.

~DR0ID


Kris Schnee schrieb:
>  Dave LeCompte (really) wrote:
> > Also, there's a pretty good paper about the tricks that the "Tribal
> > Trouble" guys used to make their terrain here:
> > http://oddlabs.com/download/terrain_generation.pdf
> 
>  That paper was really useful. I was able to implement a version of the 
>  Voronoi (bubble/ridge thing) with some fiddling, and accidentally made 
>  what appears to be a fractal by accident. It's attached as 
>  "my_generation.py" if you want to see the messy code. The part that 
>  was hard to figure out was what the paper described as:
>  height = (distance to nearest point)*(arbitrary constant 1)
>  The distance ranges from 0 to many thousands, so what's a good way to 
>  convert that to a 0-255 range or the 0.0-1.0 range used in the paper? 
>  I ended up doing it in an arbitrary way.
> 
>  I see that <http://home.scarlet.be/zoetrope/voronoi/> has a Python 
>  implementation of Voronoi code as a "Crystalize" filter for images.
> 
>  I also tried to implement a diamond-square algorithm, but something's 
>  not quite right about it. If I force the squares to be higher than 
>  normal (adding 64 to the height values), I can see that it's 
>  calculating all the pixels in the image, but normally most of the 
>  image ends up black. The code for that is attached as 
>  "my_generation3.py"; anyone know how to fix it? The problem seems to 
>  be that I'm using a 256x256 bitmap, and the calculation of each cell's 
>  "neighbors" is off by one pixel or something where it wraps around the 
>  edges, so that it finds zeroed pixels instead of the 
>  already-calculated ones.