Also, if you happen to be on Linux (or some other Gnome-enabled UNIX), you 
might want to try 

  http://terraform.sourceforge.net

which features a quite-capable terrain editor with some (limited) povray 
integration ...

Greetings
--> R

Ken wrote:
> 
> 
> Lars wrote:
> 
>> Any recommendations on good tools to smooth and manipulate 16bit
>> grayscale images under win2000?  Photoshop is quite limited in it's
>> 16bit handling, and I'm not having any luck with Wilbur--it seems to
>> produce a lot of empty images and lose data.  HLA didn't run under
>> windows 2000.
> 
> Have you looked at Leveller? - http://www.daylongraphics.com/
>

Post a reply to this message

>   Did you try with a lower resolution? For example divide width and height
> by 10. (You don't have to use it; just try it to see what happens).

do you mean the rendering or the height field source?   

Reducing the res of the HF source doesn't change the boxing effect, only 
I get larger boxes.  I tried resolutions from 500x500 up to 10000 x 
10000, both 8 and 16 bit depths.  They all show the posterization and 
boxing when smooth is enabled, just with differing size boxing.

Reducing the rendering output size makes everything lower res, and 
eventually the boxes disappear as they become sub-pixel in size.  The 
world looks reasonable at 640x480 or whatever, since each box is 0.002 
pixels across!  So the scale of the boxes is constant in relation to the 
world scale.

Post a reply to this message

Is it possible to output the HF vertices? If so, you could make the
triangles and figure the normals yourself. The fact that a HF parses so
quickly suggests to me that some type of cheat is used to figure the
normals. If you put the HF where you wanted it and then calculated the
"real" normals, you would surely get a better result.

If not, I think it would be pretty easy to build your own heightfield with
eval_pigment. Haven't tried that, though.

Hope this helps.
 -Shay

Lars <sel### [at] pacbellnet> wrote in message
news:MPG.16d84912e546d13b989680@news.povray.org...

Post a reply to this message

In article <3c72a800@news.povray.org>, "Shay" <sah### [at] simcopartscom> 
wrote:

> Is it possible to output the HF vertices? If so, you could make the
> triangles and figure the normals yourself. The fact that a HF parses so
> quickly suggests to me that some type of cheat is used to figure the
> normals. If you put the HF where you wanted it and then calculated the
> "real" normals, you would surely get a better result.
> 
> If not, I think it would be pretty easy to build your own heightfield with
> eval_pigment. Haven't tried that, though.

Or just use one of the height field macros from shapes.inc. ;-)

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

Christopher James Huff <chr### [at] maccom> wrote in message
news:chr### [at] netplexaussieorg...
>
> Or just use one of the height field macros from shapes.inc. ;-)

I think he's trying make a HF out of a satelite picture, so I'm not sure
those macros would help. Still, should be easy to write a similar macro that
uses as image.

 -Shay

Post a reply to this message

In article <3c72bbbd@news.povray.org>, "Shay" <sah### [at] simcopartscom> 
wrote:

> I think he's trying make a HF out of a satelite picture, so I'm not sure
> those macros would help. Still, should be easy to write a similar macro that
> uses as image.

The macros take functions as input, so there is no problem with using an 
image.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

Christopher James Huff <chr### [at] maccom> wrote in message
news:chr### [at] netplexaussieorg...
>
> The macros take functions as input, so there is no problem with using an
> image.
>

That's right. Wasn't thinking straight.

 -Shay

Post a reply to this message

> > I think he's trying make a HF out of a satelite picture, so I'm not sure
> > those macros would help. Still, should be easy to write a similar macro that
> > uses as image.

originally, it's DEM->TGA->edited image.  So yes, USGS data initially, 
then edit it, then make a very high res terrain from that. 

> > The macros take functions as input, so there is no problem with using an 
> image.

I'll look into that.  I tried a mesh earlier, using Wilbur as a TGA->
Mesh converter, but it's normal calculations were broken, so it looked 
quite faceted.   Even with the broken normals issue aside, I wasn't able 
to get that many points into the surface before running out of memory / 
hitting internal POV limits (I've got 1.5GB RAM--maxxed for this 
machine) I think POV maxxed out parsing a 500x500 point mesh inc file.  
But by using a macro, I might get farther without having to have a 
several GB .inc file to parse.  

It was also much much slower, parsing such a huge .inc file, but I can 
live with that if it ends up working.

Post a reply to this message

In article <MPG.16dc658922b4245d989686@news.povray.org>,
 Lars <sel### [at] pacbellnet> wrote:

> I'll look into that.  I tried a mesh earlier, using Wilbur as a TGA->
> Mesh converter, but it's normal calculations were broken, so it looked 
> quite faceted.   Even with the broken normals issue aside, I wasn't able 
> to get that many points into the surface before running out of memory / 
> hitting internal POV limits (I've got 1.5GB RAM--maxxed for this 
> machine) I think POV maxxed out parsing a 500x500 point mesh inc file.  

I don't think POV should be that limited, it might be some other 
problem...but you might get around it by using several meshes. And with 
the macros, you don't have to have the mesh resolution the same as the 
image...because it uses a function, you could just use a lower 
resolution for the macro and let the image_map interpolation take care 
of things. If you need a higher resolution for a specific area, you 
could generate a smaller, higher resolution height field for that area.


> But by using a macro, I might get farther without having to have a 
> several GB .inc file to parse.  

The macros won't help the speed, though they have the advantage I 
mentioned of allowing you to pick your mesh resolution. The macros parse 
slower than a mesh include file, which is why I added the option to 
output to a mesh file.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

> I don't think POV should be that limited, it might be some other 
> problem...but you might get around it by using several meshes.

A 300x300 point mesh worked, but looked pretty rough--not enough points 
(I'm rendering a 20K x 10K pixel image, so it's very very high res and I 
need a lot of detail in the terrain map)

I just tried a 1000 x 1000 point mesh, which I think might be enough 
points, but POV choked.  (internal error)  An 800x800 mesh also choked.  
It claimed to generate an error log, but I couldn't find it. 

Multiple meshes might be a workaround, but I would be concerned about 
getting them to line up without gaps.

> the macros, you don't have to have the mesh resolution the same as the 
> image...because it uses a function, you could just use a lower 
> resolution for the macro and let the image_map interpolation take care 
> of things. 

sure.  My  image map is 5K x 5K pixels (actually, I've got versions from 
500x500 to 10K x 10K).  I'm not trying to make THAT many mesh points--
that would kill anything  :)   I guess that's one of the advantages of a 
height field--high res...if it's smoothing would work at that zoom 
level.

But even a 1000 x 1000 point mesh would probably be good enough.  But 
that seems to kill POV--I don't think it's memory--the task manager 
reports plenty still free and usage still under 300MB.  But something 
inside POV dies.

> If you need a higher resolution for a specific area, you 
> could generate a smaller, higher resolution height field for that area.

no, I pretty much need that much detail across the whole thing, 
unfortunately.  I'm pushing things to the breaking point, it seems.

Post a reply to this message