Ron Parker wrote in message >
>
>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)


Phew; that's a relief.


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


Interesting coincidence -- a multi-chunk cache scheme
was the first thing I tried after the original post.
It floundered horribly; the number of chunks needed
to be kept present became too significant a percentage
of the entire imagemap, so all the memory savings evoporated.
No matter what, it was either have s-l-o-w rendering
or lots of memory being consumed.

I've now got a pure imagemap-driven system working,
and it's fast. The raytracer builds a depth map, the
imagemap enhances it with bumpmap data, and then a
final colorization pass whips over in two seconds.
Best of all, I can try different light positions/colormaps
afterwards and re-colorize instantly.


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

Agreed. Even a single heightfield with some bumps closer
than others gave the cache scheme the fits. The whole
paradigm of servicing pixels off the raytracing scanline
is probably unsuitable for some things. I'm not suprised
things like REYES, etc. are used.

Ray Gardener
Daylon Graphics Ltd.
http://www.daylongraphics.com/
"heightfield editing perfected"

Post a reply to this message