ingo wrote:
>using the option to use bitmaps as a function
>for an isosurface object in the
>superpatch might be what you're looking for

Using the isosurface patch is probably
unnecessary for what I'm trying to do.
It would basically shift the process
from bumpmapping to displacement mapping,
and although the results would look good,
the additional rendering time would negate
the benefits severely. But in the future,
it's an area definitely worth exploring.
Actually, what I'm proposing should be
seamlessly usable by the isosurface patch
anyway.

My proposed changes basically enhance the
use of imagemaps/bumpmaps so that really
large (e.g., 128 MB) maps can be used
without taking memory.

Why large maps? For terrain, I use
fractal plasma bumpmaps, and initially
I was calculating them dynamically
during the rendering process. But this
is really slow, and it's difficult to
get the overall map to look right.
When I realized I was using the same
bumpmap data repeatedly, it made sense
to generate a large map once, thereby
caching all that computation.

The map has to be large so that close-up
views look good. If you've ever walked up
close to a wall in Quake, you know
what I mean -- the texture breaks down
into obvious pixels. Given today's
big and cheap hard drives, storage of
large maps is no longer a problem.

POV-Ray doesn't support large maps well;
it assumes they can be loaded entirely
into memory and kept around for the duration.
This is okay for simple scenes, but for
complex scenes, it doesn't make sense to
share memory with a large imagemap/bumpmap.
Virtual memory doesn't help either, since
it's not optimized for the type of caching
the maps need (and on a complex scene,
the VM is needed for other objects anyway).

So that's basically it. One nice thing is
that the visible impact on POV-Ray would
be minimal -- there's no language changes
or anything new to learn. All that happens
is that if you're using a large bumpmap/imagemap,
it gets used in an optimum way that leaves
memory for the rest of the scene. Adding
support for a true 16-bit bumpmap/grayscale filetype
would be nice, and that would be the only
language modification.

Ray
Daylon Graphics Ltd.
http://www.daylongraphics.com/

Post a reply to this message