Um, since I've opted for the depthmapping solution
to the large bumpmapping cache problem, is there
any work being done on making POV-Ray generate depthmaps?
I did a search of previous postings but didn't find
anything.

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

Post a reply to this message

On Tue, 3 Aug 1999 19:38:41 -0700, Ray Gardener wrote:
>Um, since I've opted for the depthmapping solution
>to the large bumpmapping cache problem, is there
>any work being done on making POV-Ray generate depthmaps?
>I did a search of previous postings but didn't find
>anything.

It's been done, and it's not too difficult at all.  It would take
a few minutes to put all the appropriate stuff in all the appropriate
places to do it.  I've considered doing it in the next superpatch, but
haven't gotten to it yet.  Other than that, I don't know of any current
patches that make depth maps.

Post a reply to this message

What is a depth map? I saw in a magazine that they took pictures of
buildings in Chernobyl, then created depth-maps, and then turned that into
triangles to get a 3d image out of it, but they didn't go into detail.
Could you please explain this? Thanks in advance.

--
Anthony L. Bennett
http://welcome.to/TonyB

Non nova, sed nove.

Post a reply to this message

TonyB wrote in message <37A887CF.A622BAAF@panama.phoenix.net>...
>What is a depth map?

I don't know if there is a standard definition
of a depth map, but I'm interpreting it in this context
as a 2D array of all the intersection data generated
by a raytracing pass. For every screen pixel, a
block of information is stored that tells what
object (objects?) contributes light to that pixel,
what the intersection point and surface normal
on the object is, etc. Once a depth map is built,
another routine (what I call a colorizer for lack
of a better term) goes through the depth map and
plots the screen pixels.

The depth map is essentially a cache of the
raytracer's scene object intersection data. It
lets colorization occur rapidly afterwards
despite changes in the scene, as long as the
camera position or viewport size is not changed
(there are other qualifiers, but I don't want
to make this post overly long).

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

Post a reply to this message

Ron Parker wrote in message <37a83e5e@news.povray.org>...
>
>It's been done, and it's not too difficult at all.  It would take
>a few minutes to put all the appropriate stuff in all the appropriate
>places to do it.

Do you know what characteristics the depth map
would have (i.e., what information it would
store for each pixel)? If help is needed to
implement it I'm willing to assist.

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

Post a reply to this message

On Wed, 4 Aug 1999 17:06:33 -0700, Ray Gardener wrote:
>Ron Parker wrote in message <37a83e5e@news.povray.org>...
>>
>>It's been done, and it's not too difficult at all.  It would take
>>a few minutes to put all the appropriate stuff in all the appropriate
>>places to do it.
>
>Do you know what characteristics the depth map
>would have (i.e., what information it would
>store for each pixel)? If help is needed to
>implement it I'm willing to assist.

What information do you envision it needing?  The last time I did it
was to generate SIRDS, so I only needed the distance along the camera's
direction vector.  If you need much more, you'll likely find yourself
constrained by the output format, unless you create a custom output 
filetype to contain the extra data.  Extra data will also make the 
project a trifle more difficult, though not terribly so.

Post a reply to this message

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

On Thu, 5 Aug 1999 12:19:22 -0700, "Ray Gardener"
<ray### [at] daylongraphicscom> wrote:


Ah.  None of this is what I think of when I think of the term "depth
map."  To me, a depth map is a greyscale image you use to make SIRDS
or height fields.  What you're looking for is significantly more
complicated for many reasons, not the least of which is the POV
architecture's dependency on rendering things in order, left to right
and top to bottom.  That's because it writes the image to the disk as
it completes it, rather than keeping the whole thing in memory.

Post a reply to this message

Ron Parker wrote in message <37aa2014.71093169@news.povray.org>...
>
>Ah.  None of this is what I think of when I think of the term "depth
>map."  To me, a depth map is a greyscale image you use to make SIRDS
>or height fields.  What you're looking for is significantly more
>complicated for many reasons, not the least of which is the POV
>architecture's dependency on rendering things in order, left to right
>and top to bottom.  That's because it writes the image to the disk as
>it completes it, rather than keeping the whole thing in memory.



Well, it's good to find these things out.
I'm not advocating a wholesale rewrite of POV
by any means (it's not practical), but I
think some surgical changes could be useful.
What I could do is try a private patch, and
see how it goes, and make the result
available for evaluation. I'll preserve
the write-during-render behavior; thanks
for mentioning that.


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

Post a reply to this message