On Sat, 31 Jul 1999 10:32:36 -0700, Ray Gardener wrote:
>From just a quick look at the code in png_pov.c, I couldn't
>find any plain 16-bit support; there's always some conversion
>of color channels going on. But I'm not 100% sure; will
>have to look closer at it.


color = (int)floor(line_data[col][RED]   * 65535.0);

row_ptr[j] = color >> 8;
row_ptr[j + 1] = color & 0xFF;

(and three more just like it)

The color is pure sixteen-bit color at this point,
provided that the floating-point format of a COLOUR
structure is up to it. (the default is single-precision,
which ISTR has a 16-bit mantissa.  You could probably
get better color resolution with a double-precision 
custom compile.)  The two lines that bit-bang the 
result are just a portable way of explicitly handling
endianness issues in the resulting image file.

>Consider a scene with multiple objects (all using the
>same imagemap) at various distances from the camera.
>As the rendering scanline intersects more than one object,
>the access pattern to the imagemap becomes more random.

True, but there comes a time when you have to just accept 
that and move on.  Presumably the caching behavior would
be on an imagemap-by-imagemap basis, controlled by a keyword,
so small imagemaps would be no slower than ever.  And there's
no rule that says you have to keep only one current chunk.
If you kept the last n chunks for some (configurable?) value of 
n, you could still realize a performance improvement for the
vast majority of non-pathological scenes.

Actually, the worst scene I can think of is an infinite plane,
tiled with your bitmap of choice.  Samples near the horizon
will be almost completely random.

Post a reply to this message