Ron Parker wrote in message <37a98c03@news.povray.org>...
>>
>>Do you know what characteristics the depth map
>>would have (i.e., what information it would
>>store for each pixel)?
>
>What information do you envision it needing?
>

Having the UV coord is necessary, as well as
a bit flag indicating a dependency on the
bumpmap. The two could be folded by having
an "impossible" UV coord value double as
the dependency flag.

The pseudocode for rendering would be:

    reset depthmap
    for all screen pixels
        if pixel dependant on large bumpmap/imagemap
            mark dependency
            compute and store UV coord
        else
            colorize the pixel
        endif
    next screen pixel

    if any bumpmap dependencies occurred
        for all bumpmap (or imagemap) chunks
            for all dependant depthmap pixels with UV coord in chunk space
                fetch and compute bump map normal
                call raytracer to compute final color for screen pixel
            next depthmap pixel
        next bumpmap chunk
    endif

Essentially, the raytracer postpones coloring
dependant pixels, when the bumpmap normal is
obtained later. In the first pass, the raytracer
can stop calculating a dependant pixel the moment
it knows of the dependency, because it will be
called by the bumpmapper later on anyway. The
most redundant tracing occurs for reflections,
because the dependency is known late instead of
early. Fortunately, the reverse is true for
shadows, where penumbral tracing might be needed.
In a typical landscape scene, reflections usually
occur only for water.

If the depthmap stores more data, the raytracer
can be spared having to re-intersect the bumpmapped
object (in my case, a heightfield). So storing
the intersection point would be useful too.
For a large scene (or an antialiased scene),
this may make the depthmap overly large. But
even if retracing is needed, intersecting a
heightfield twice is still much faster than the
best bumpmap file cache scheme -- the CPU is
so much quicker than the I/O.

Antialiasing presents interesting complications.
An easy way is to simply render an oversize
scene and resample it down. Another is to
mark a dependency on a screen pixel if any
of its scene sampling rays (primary and jitter)
depend on the bumpmap. This makes retracing dependant
pixels extra long, but the depthmap would not have
to be larger. The jitter rays, of course, have to
be fired exactly the same way on each pass, so
the sampling pattern is either regular, or random
with a known generator seed.

In this scheme, the tracer would need a modification
to let it be called by the bumpmapper (or imagemapper).
It would work as usual for the most part, but when
it needed data from a bumpmap/imagemap, it would
call a previously supplied callback function,
instead of going the usual route and looking for
the object's loaded bumpmap/imagemap data.
Since the callback scheme can be used to handle
normal-sized bumpmaps/imagemaps, the modification
could elegantly handle both cases. Essentially,
no assumptions are made about where the bumpmap/imagemap
data is coming from.

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

Post a reply to this message