Christopher James Huff wrote:
> 
> Ok, I did. My method worked. Yours didn't. The interpolated version does 
> what's expected, it gives the isosurface a smooth function to work with, 
> and the result is something that closely resembles the original.

It seems to do in case of image_maps, the case where i originally had 
problems with it was image_pattern (because it uses GREY_SCALE()).  This 
also makes it clear why using two separate images for low and high byte 
works.

Note the code did not even work with final POV-Ray 3.5, for some reason 
image_pattern is not allowed in pattern functions (it is commented out 
in Parse_PatternFunction()).

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 11 Jan. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

In article <rdg### [at] tritonimagicode>,
 Christoph Hormann <chr### [at] gmxde> wrote:

> It seems to do in case of image_maps, the case where i originally had 
> problems with it was image_pattern (because it uses GREY_SCALE()).  This 
> also makes it clear why using two separate images for low and high byte 
> works.

I don't know what you were using image_pattern for...the .hf feature 
takes a vector function, almost always a pigment function. It will never 
work with image_pattern, because pattern functions return a single float 
value. And image_pattern won't return any sort of sensible result from a 
red-green 16-bit data file.


> Note the code did not even work with final POV-Ray 3.5, for some reason 
> image_pattern is not allowed in pattern functions (it is commented out 
> in Parse_PatternFunction()).

#declare InterpFn = function {pigment {image_map {tga "hfimage.tga" 
interpolate 4}}}

isosurface {
    function {y - InterpFn(x, z, y).hf}
...

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

Christopher James Huff wrote:
> 
>>It seems to do in case of image_maps, the case where i originally had 
>>problems with it was image_pattern (because it uses GREY_SCALE()).  This 
>>also makes it clear why using two separate images for low and high byte 
>>works.
> 
> 
> I don't know what you were using image_pattern for...the .hf feature 
> takes a vector function, almost always a pigment function. It will never 
> work with image_pattern, because pattern functions return a single float 
> value. And image_pattern won't return any sort of sensible result from a 
> red-green 16-bit data file.

Not for 24 bit tga images (which are a bad choice for heightfield data 
anyway)  If everything works as it should image_pattern in combination 
with a 16 bit grayscale format (png or pgm) would be the most elegant 
solution for this purpose:

#declare fn_Image =
   function {
     pattern {
       image_pattern {
         png "hfimage.png"
         interpolate 2
       }
     }
   }

isosurface {
   function { z - fn_Image(x, y, 0) }
   ...
}

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 11 Jan. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

In article <p76### [at] tritonimagicode>,
 Christoph Hormann <chr### [at] gmxde> wrote:

> Not for 24 bit tga images (which are a bad choice for heightfield data 
> anyway)  If everything works as it should image_pattern in combination 
> with a 16 bit grayscale format (png or pgm) would be the most elegant 
> solution for this purpose:

I don't know what you're talking about. Your assertion was that .hf and 
interpolation didn't mix. Then you started talking about image_pattern, 
which can't be used with the .hf feature. Now you're talking about 24 
bit RGB and 16 bit grayscale images as if it makes a difference...it 
doesn't. A 16 bit grayscale image isn't useful as input for the .hf 
feature, and makes it unnecessary. The red-green 16 bit grayscale TGA 
format is not useable as input for the image_pattern pattern, but I 
never said to use it as such. None of this has anything to do with 
interpolation.

Yes, a 16 bit grayscale PNG or PGM would be ideal height field input, 
but I don't see what it has to do with this discussion, which is about 
TGA files. A red-green grayscale TGA with interpolation and the .hf 
feature will work just as well, and you could recover the wasted space 
of the blue channel by storing something else in it.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message