Thorsten Froehlich <tho### [at] trfde> wrote:
: I don't use hfields (or POV-Ray) a lot, and I actually don't have a problem
: with either way.  If there are more requests to make it convert to grayscale
: for 16-bit per color component images, I would be happy to do so...

  I don't think that the current behaviour is that problematic. I think that
the biggest problem is that this behaviour is not clearly documented. I have
read the heightfield documentation countless times during these years, and I
never realized this behaviour.
  Of course I can't speak for anyone else, but it seems to me that the user
(well, in this case me) gets the impression that this kind of b/w conversion
must be done when creating the heightfield... I don't know where did I get
that impression, but that's what I thought. I think that the documentation
lacks a clear and unambiguous description of the exact algorithm used for
the pixel to height conversion with true color images (what happens with
indexed images is a lot better documented).
  Perhaps a more visible note about this conversion could be added with some
examples of useful usages of this feature.

  On the other hand, I wouldn't mind that the b/w conversion would be used
to create the heightfield from the image. Note that this way you get *more*
than 256 heights, which makes the heightfield more accurate even with 24-bit
images.

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message