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

<snip>
> originally, it's DEM->TGA->edited image.  So yes, USGS data initially,
> then edit it, then make a very high res terrain from that.
    I think I see the problem, did you use more colors in the heightfield,
or did you just save as a higher resolution, then it wouldn't smooth and
would look like your picture does when two when the color changes more than
one shade.  Try lowering the number of colors in the picture you make the
heightfield from.  That seems to be your problem, although i'm not sure.
Try lowering the depth to the original.
<snip>

Post a reply to this message

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

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

Well...how about an isosurface? No more worrying about triangles at all.

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

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

> It claimed to generate an error log, but I couldn't find it.

???  POV-Ray does not generate error logs.  Are you sure you got thjis message
from POV-Ray?

What specific error does the message window / console output of POV-Ray show?

    Thorsten

Post a reply to this message

> ???  POV-Ray does not generate error logs.  Are you sure you got thjis message
> from POV-Ray?
> 
> What specific error does the message window / console output of POV-Ray show?

I ran it again.  I think it's a windows message, meaning it's log will 
be useless.  "pvengine has generated errors and a log will be created" 
or something.  It didn't look the the usual windows crash dialog(s), so 
I didn't recognize it.

Post a reply to this message