Not sure if this is the best place to ask this, let me know.
I am trying to create a heightfield image and would like to
be able to do it by initially creating a contour map. I just
downloaded Leveller and while it is a nice, 5 min to learn
type program, it doesn't quite do what i would like.

What i'm trying to create is a golf course terrain. It
should have gentle rolling hills, i.e. only a small
amount of elevation change, but i'm having difficulty
getting it to look the way i want. Are there any other
good terrain modelers I should look at? I also have
Photoshop 4, and have been considering using the pen tool
to create the contours and then doing some type of gradient
fill, not sure how well it would work.

Any ideas would be much appreciated.

Adrian Pederson
ape### [at] mailtdsnet

Post a reply to this message

Adrian Pederson <ape### [at] mailtdsnet> wrote in article
<35d12507.0@news.povray.org>...
> Not sure if this is the best place to ask this, let me know.
> I am trying to create a heightfield image and would like to
> be able to do it by initially creating a contour map. I just
> downloaded Leveller and while it is a nice, 5 min to learn
> type program, it doesn't quite do what i would like.
> 
> What i'm trying to create is a golf course terrain. It
> should have gentle rolling hills, i.e. only a small
> amount of elevation change, but i'm having difficulty
> getting it to look the way i want.

	Well, the thing to remember in _any_ terrain editor is that the
relationship between any given pixel value on the height field image and
the altitude at the corresponding point on the resultant height field is
dependant on the vertical scale of the height field. Try creating a height
field, in whatever way you wish, then, create a pov scene where you can see
the entire height field. Now, insert scale<1,100,1> into the height field
definition and you'll get a height field with very steep hills. Now, change
that to scale<1,0.001,1> and you'll get an almost flat height field ! Now
keep experimenting with that scale instruction and you'll see you can
adjust easily adjust the apparent steepness of the hills.

-- 
Scott Hill
Sco### [at] DDLinkscouk
Software Engineer (and all round nice guy)
Company homepage : http://www.ddlinks.demon.co.uk

"The best trick the devil ever pulled was convincing people he didn't
exist..."
								- Verbal Kint.

"the Internet is here so we can waste time talking about nothing in 
 particular when we should be working" - Marcus Hill.

Post a reply to this message

I guess I should clarify my last point, i'm aware that changing the
vertical scaling will have a direct effect on the slope. What I'm trying
to do is create a smoothly contoured gradiant over large odd shaped areas
in the heightfield image. It would be nice to do this in a somewhat direct
way, rather than by going through a multiple trial and error filtering
process.

Adrian Pederson


> Well, the thing to remember in _any_ terrain editor is that the
>relationship between any given pixel value on the height field image and
>the altitude at the corresponding point on the resultant height field is
>dependant on the vertical scale of the height field. Try creating a height
>field, in whatever way you wish, then, create a pov scene where you can see
>the entire height field. Now, insert scale<1,100,1> into the height field
>definition and you'll get a height field with very steep hills. Now, change
>that to scale<1,0.001,1> and you'll get an almost flat height field ! Now
>keep experimenting with that scale instruction and you'll see you can
>adjust easily adjust the apparent steepness of the hills.

>
>--
>Scott Hill

Post a reply to this message

Adrian Pederson wrote:
> 
> I guess I should clarify my last point, i'm aware that changing the
> vertical scaling will have a direct effect on the slope. What I'm trying
> to do is create a smoothly contoured gradiant over large odd shaped areas
> in the heightfield image. It would be nice to do this in a somewhat direct
> way, rather than by going through a multiple trial and error filtering
> process.
> 
> Adrian Pederson
> 

This function (constraining the height field boundary conditions
over contours and/or regions of finite area) would be extremely
useful for more than links.  There are many examples.

One would be a road winding along a hillside.  It would
be nice to be able to specify the road, then to have the
landscape generator fill in a terrain which smoothly matches
the edge of the road.  Of course, this is backwards from nature,
where the roadbuilders must deal with the hill they are given.
But it would be good for generating scenes.

I can imagine algorithms which might do a credible job at this.
The easiest implementation may be to manipulate tga files using
PERL -- the format is straightforward and PERL does a nice job
with file I/O.  It does takes a bit of work to learn, though.

But then, it's probably already been done -- I also am interested on
hearing of implementations.

Dan

-- 
http://www.flash.net/~djconnel/

Post a reply to this message

Dan Connelly <djc### [at] flashnet> wrote in article
<35D21679.AD96E720@flash.net>...
<snip>
> 
> This function (constraining the height field boundary conditions
> over contours and/or regions of finite area) would be extremely
> useful for more than links.  There are many examples.
> 
> One would be a road winding along a hillside.  It would
> be nice to be able to specify the road, then to have the
> landscape generator fill in a terrain which smoothly matches
> the edge of the road.  Of course, this is backwards from nature,
> where the roadbuilders must deal with the hill they are given.
> But it would be good for generating scenes.
> 
> I can imagine algorithms which might do a credible job at this.
> The easiest implementation may be to manipulate tga files using
> PERL -- the format is straightforward and PERL does a nice job
> with file I/O.  It does takes a bit of work to learn, though.
> 
> But then, it's probably already been done -- I also am interested on
> hearing of implementations.

Actually I' very interested in such a tool. I tought of taking a height
field and take the difference
with a box, and a cylinder on top of it for tunnels. and then bend it using
the spline include file from 
Chris Colefax. haven't tried it yet. But if their is a tool.......

Thomas

Post a reply to this message

Since there seems to be some interest in this type of tool, i would
be willing to try making one, mostly for selfish reasons though.
I have Borland C++, and Matlab for development platforms, the
latter may be the easiest for doing the constrained interpolation.
I could then compile the functions into a C program.

My biggest question is where to start. What would be the best
method for defining and drawing the contour map itself? Should
it be created as some type of data file or an image map?

Putting on my cs hat for a minute and abstracting the problem,
i see that there needs to be a way to define closed or open
paths and to have an associated height value for each.

So taking the data file path, is there any preexisting app that
would be good for drawing the contours and creating a file that
would then be 'easily' convertible into an image. This could be
something that would create the contours as segmented vector
paths or (ideally) splines. sPatch jumps to mind, i think i just
read some info on its data file structure.

For the image map route, something like Illustrator, which i
don't have (yet), could do a similar job. Just create the
contours, give them the appropriate color(height value), save
as tga, png...?, and run though the interp program.

Ideas, comments...?

Adrian Pederson


>This function (constraining the height field boundary conditions
>over contours and/or regions of finite area) would be extremely
>useful for more than links.  There are many examples.
>
>One would be a road winding along a hillside.  It would
>be nice to be able to specify the road, then to have the
>landscape generator fill in a terrain which smoothly matches
>the edge of the road.  Of course, this is backwards from nature,
>where the roadbuilders must deal with the hill they are given.
>But it would be good for generating scenes.
>
>I can imagine algorithms which might do a credible job at this.
>The easiest implementation may be to manipulate tga files using
>PERL -- the format is straightforward and PERL does a nice job
>with file I/O.  It does takes a bit of work to learn, though.

Post a reply to this message

Adrian Pederson wrote:

> Since there seems to be some interest in this type of tool, i would
> be willing to try making one, mostly for selfish reasons though.
> I have Borland C++, and Matlab for development platforms, the
> latter may be the easiest for doing the constrained interpolation.
> I could then compile the functions into a C program.
>
> My biggest question is where to start. What would be the best
> method for defining and drawing the contour map itself? Should
> it be created as some type of data file or an image map?
>
> Putting on my cs hat for a minute and abstracting the problem,
> i see that there needs to be a way to define closed or open
> paths and to have an associated height value for each.
>
> So taking the data file path, is there any preexisting app that
> would be good for drawing the contours and creating a file that
> would then be 'easily' convertible into an image. This could be
> something that would create the contours as segmented vector
> paths or (ideally) splines. sPatch jumps to mind, i think i just
> read some info on its data file structure.
>
> For the image map route, something like Illustrator, which i
> don't have (yet), could do a similar job. Just create the
> contours, give them the appropriate color(height value), save
> as tga, png...?, and run though the interp program.
>
> Ideas, comments...?
>
> Adrian Pederson
>
> >This function (constraining the height field boundary conditions
> >over contours and/or regions of finite area) would be extremely
> >useful for more than links.  There are many examples.
> >
> >One would be a road winding along a hillside.  It would
> >be nice to be able to specify the road, then to have the
> >landscape generator fill in a terrain which smoothly matches
> >the edge of the road.  Of course, this is backwards from nature,
> >where the roadbuilders must deal with the hill they are given.
> >But it would be good for generating scenes.
> >
> >I can imagine algorithms which might do a credible job at this.
> >The easiest implementation may be to manipulate tga files using
> >PERL -- the format is straightforward and PERL does a nice job
> >with file I/O.  It does takes a bit of work to learn, though.

  Perhaps since Taps progam Leveller, allows plugins a lot of the
work has already been done.  It might be worth contacting him and
see if there is a way to integrate what you want to do as a plug in
to his program.

K.Tyler

Post a reply to this message

Adrian Pederson wrote:
>
> My biggest question is where to start. What would be the best
> method for defining and drawing the contour map itself? Should
> it be created as some type of data file or an image map?
> 
> Putting on my cs hat for a minute and abstracting the problem,
> i see that there needs to be a way to define closed or open
> paths and to have an associated height value for each.

The following is all speculation... I will likely experiment
further with it (if I can figure out how to parse Targa in
PERL) when I can get some time on a UNIX system.

The approach I would take is to not define 1-d constraints, but
to use 2-d constraints.

What I would use is two images, plus an alpha channel which has ones
where the constraint image ( z1[x,y] ) should be used, and zeros
where the background, terrain-generator-created terrain ( z0[x,y] )
should be used.  Image 1 would be defined over regions where the
alpha channel is 1, and would be "don't care" elsewhere.

Then to create a smooth transition, two things need to be done:

1. extend image 1 into the non-defined areas...  This is a bit tricky.
   It's easy to come up with O(n^2) formulas based on weighted averages
   over constrained pixels (for example, a weighting factor of 
   1/r^4 might work, where r is the distance to the constrained pixel
   in question), but I am sure more efficient algorithms exist.  The
   extended image 1 field I'll call z1'[x, y] .

2. smooth out the alpha channel : this can be done with a diffusion
   algorithm applied to pixels with sub-unity alpha.  I'll call
   the revised alpha channel a' .

3. combine the images:
   z[x, y] = (1 - a'[x, y]) * z0[x, y] + a'[x, y] * z1'[x, y]


The result is the final image will exactly match the boundary conditions
imposed
by image 0, and will make a smooth transition into image 1 in the
unconstrained
regions.  The length of the transition is determined by the diffusion
algorithm.

BTW, the diffusion algorithm can be something like :

a'[x, y] =
 ( 
   ( a[x, y] * (1 + a[x, y]) ) +
   ( a[x-1,y] + a[x+1,y] + a[x,y-1] + a[x,y+1] ) * ( 1 - a[x,y] ) / 4
 ) / 2;

applied iteratively (of course, between iterations, a' -> a).
Note this tends to retain values which are closer to one, while
values closer to zero get averaged against their
nearest neighbors.  

It remains to be seen if this results in realistic transitions
from the constraint region to the unconstrained region.

Note contours would need to be implemented via
2-d approximations (ie they must be pixellated
at height field resolution).          

-- 
http://www.flash.net/~djconnel/

Post a reply to this message

>The approach I would take is to not define 1-d constraints, but
>to use 2-d constraints.
>
>What I would use is two images, plus an alpha channel which has ones
>where the constraint image ( z1[x,y] ) should be used, and zeros
>where the background, terrain-generator-created terrain ( z0[x,y] )
>should be used.  Image 1 would be defined over regions where the
>alpha channel is 1, and would be "don't care" elsewhere.


I've had very similar thoughts, but wouldn't it really be a 3D
constraint? X and Y from the pixel row and column, and Z from the
color value (right-handed system). Also, why create a second file
that needs to be recombined with the original? Wouldn't it be
better to just store the pixel channels into a 2 dimensional
array of structures containing the channel info, then do the
interp and output directly to a completed image file, so what if
it takes a little more memory. You only really need two channels
on the input, i think pov uses red for the height (correct me if
i'm wrong) and the alpha, of course you could always copy the
calculated values into all 3 RGB channels for the output, if it
matters.

Regarding the interpolation algorithm, that's something i'd need
to experiment with, i've never had to do more than one dimension
before. The 'diffusion' algorithm sounds like a possible starting
point, i've had thoughts of finding contour paths and normals (2D),
more complex than i would like.

Adrian Pederson

Post a reply to this message

Adrian Pederson wrote:
> 
> >The approach I would take is to not define 1-d constraints, but
> >to use 2-d constraints.
> >
> >What I would use is two images, plus an alpha channel which has ones
> >where the constraint image ( z1[x,y] ) should be used, and zeros
> >where the background, terrain-generator-created terrain ( z0[x,y] )
> >should be used.  Image 1 would be defined over regions where the
> >alpha channel is 1, and would be "don't care" elsewhere.
> 
> I've had very similar thoughts, but wouldn't it really be a 3D
> constraint? X and Y from the pixel row and column, and Z from the
> color value (right-handed system).

By 2-d constraint, I mean it is a scalar field defined in two 
dimensions.  It isn't a full 3-d function : these are defined
over arbitray choices of (x, y, z).

> Also, why create a second file
> that needs to be recombined with the original? Wouldn't it be
> better to just store the pixel channels into a 2 dimensional
> array of structures containing the channel info, then do the
> interp and output directly to a completed image file, so what if
> it takes a little more memory. You only really need two channels
> on the input, i think pov uses red for the height (correct me if
> i'm wrong) and the alpha, of course you could always copy the
> calculated values into all 3 RGB channels for the output, if it
> matters.

Actually, in the "tga16" format, it uses red and green combined to
yield 16 bits of height resolution.  True -- one could then
use the blue channel as an 8-bit alpha channel.   However, I am
trying to cast the system in a form which allows pre-existing
unconstrained terrain generation algorithims (such as the
transform-based one used in Beale's excellent gforge code)
to be used with minimal perturbation.

An interesting thing about the use of the tga16 -- the Targa
spec seems to allow for 16-bit grayscale images.... I wonder
why POV didn't chose to use this, instead using 8-bit RGB.

Dan

-- 
http://www.flash.net/~djconnel/

Post a reply to this message