Hi all,


    Does anyone know of a way to output z buffer information along with
rendered images? It needs to be fairly accurate since another program is
going to superimpose realtime 3d shapes which need to interact properly with
the background. Thanks in advance

Post a reply to this message

Joan Lavoipierre <xdz### [at] dialpipexcom> wrote:
:     Does anyone know of a way to output z buffer information along with
: rendered images? It needs to be fairly accurate since another program is
: going to superimpose realtime 3d shapes which need to interact properly with
: the background. Thanks in advance

  Before somebody answers you with the classical answer "make a gradient
pigment from black to white with ambient finish set to 1 and apply it to the
whole scene in the direction of the camera" let me warn you a bit:
  This is one solution, but it's not an easy one. Also you have to be
careful. If you render the image normally, you will get only 256 z-values,
which isn't enough in most cases.
  Why isn't it easy?
  Usually you have all your scene already textured. You would have to comment
out all the texturing before you can apply the gradient texture to the scene.
If the scene is very complex, this may be a pain.
  If you do this, the easiest way to apply the pigment to the whole scene
may be using the #default directive.
  To get higher accuracy (ie. to get more than 256 values) you have to output
to PNG with color resolution of 16 bits per pixel (so you get 65535 z-values).
  The problem here is how do you read the PNG...
  I don't remember if targa supports 16 bits per pixel.

  I know of no other easy way to do this.

-- 
main(i){char*_="BdsyFBThhHFBThhHFRz]NFTITQF|DJIFHQhhF";while(i=
*_++)for(;i>1;printf("%s",i-70?i&1?"[]":" ":(i=0,"\n")),i/=2);} /*- Warp -*/

Post a reply to this message

On 16 Feb 1999 12:00:50 -0500, Nieminen Mika <war### [at] cctutfi> wrote:
>  To get higher accuracy (ie. to get more than 256 values) you have to output
>to PNG with color resolution of 16 bits per pixel (so you get 65535 z-values).
>  The problem here is how do you read the PNG...
>  I don't remember if targa supports 16 bits per pixel.

It does support the red/green format that POV understands for height fields.
You'll want to read up on the hf_gray_16 keyword.

Post a reply to this message

"Joan Lavoipierre" <xdz### [at] dialpipexcom> writes:

>     Does anyone know of a way to output z buffer information along
> with rendered images?

[I know, I saw Nieminen's post.  But I tried to post this *before* he
posted his thing (and did not manage).  This is a mere solution for
increasing the number of levels in the output, that needs no 16-bit
level.  Ju just use all the 24 bits.]

Colour-code it.  Render a second image with the same objects for which
the texture is changed to something like:

texture {
  pigment {
    gradient <grad-vector>
    colour_map {
      [0/256 1/256 colour rgb 0 colour rgb <0,0,1>]
      [1/256 2/256 colour rgb <0,1/255,0> colour rgb <0,1/255,1>]
      [2/256 3/256 colour rgb <0,2/255,0> colour rgb <0,2/255,1>]
      ...
      [255/256 256/256 colour rgb <0,255/255,0> colour rgb <0,255/255,1>]
    }
  }
  finish {
    ambient 1
    diffuse 0
  }
}

If <grad-vector> is correctly set to be parallel to your camera
direction, and if you translate your texture a bit, then you get a
colour depending on the distance from the focal plane.

The given example gives 65536 levels of accuracy.  If you need more,
you just have to fiddle a bit more and add a colour component on the
red channel.  You see the point.

> It needs to be fairly accurate

The last trick gives you 24 bit depth, that is 16 million or so.
Should be enough.

Roland.
-- 
Roland Mas


- Genki desu, ture en zinc.

Post a reply to this message

"Joan Lavoipierre" <xdz### [at] dialpipexcom> writes:

>     Does anyone know of a way to output z buffer information along
> with rendered images?

Colour-code it.  Render a second image with the same objects for which
the texture is changed to something like:

texture {
  pigment {
    gradient <grad-vector>
    colour_map {
      [0/256 1/256 colour rgb 0 colour rgb <0,0,1>]
      [1/256 2/256 colour rgb <0,1/255,0> colour rgb <0,1/255,1>]
      [2/256 3/256 colour rgb <0,2/255,0> colour rgb <0,2/255,1>]
      ...
      [255/256 256/256 colour rgb <0,255/255,0> colour rgb <0,255/255,1>]
    }
  }
  finish {
    ambient 1
    diffuse 0
  }
}

If <grad-vector> is correctly set to be parallel to your camera
direction, and if you translate your texture a bit, then you get a
colour depending on the distance from the focal plane.

The given example gives 65536 levels of accuracy.  If you need more,
you just have to fiddle a bit more and add a colour component on the
red channel.  You see the point.

> It needs to be fairly accurate

The last trick gives you 24 bit depth, that is 16 million or so.
Should be enough.

Roland.
-- 
Roland Mas

Sauvez un arbre, tuez un castor.

Post a reply to this message

Roland Mas wrote:


>- Genki desu, ture en zinc.

Which means? Is this phonetic for a normal French saying? Just curious. :-)
--
Rudy Velthuis

Post a reply to this message

"Rudy Velthuis" <rve### [at] gmxnet> writes:

> Roland Mas wrote:
> 

> >- Genki desu, ture en zinc.
> 
> Which means? Is this phonetic for a normal French saying? Just
> curious. :-)

Nope.  It's just a really old and cheesy French joke that has been
half-translated into Japanese.  I'm afraid I could not translate it
into English.

Sorry,
Roland.

PS: The saying in my signature is a Japanese one.  Translates into: if
it doesn't work when you push, try pulling.

R.
-- 
Roland Mas

Oshitemo damedara, hiite mina. -- Proverbe japonais

Post a reply to this message

Roland Mas schrieb in Nachricht ...
>"Rudy Velthuis" <rve### [at] gmxnet> writes:

>PS: The saying in my signature is a Japanese one.  Translates into: if
>it doesn't work when you push, try pulling.
>
>R.
>--
>Roland Mas
>
>Oshitemo damedara, hiite mina. -- Proverbe japonais

Perhaps the Japanese are right about that, but the other way doesn't work
(pushing instead of pulling). I'm a dentist, I should know.

--
Rudy Velthuis

Post a reply to this message

Roland Mas <rol### [at] casimirrezelenstfr> wrote:
:       [0/256 1/256 colour rgb 0 colour rgb <0,0,1>]
:       [1/256 2/256 colour rgb <0,1/255,0> colour rgb <0,1/255,1>]
:       [2/256 3/256 colour rgb <0,2/255,0> colour rgb <0,2/255,1>]
:       ...
:       [255/256 256/256 colour rgb <0,255/255,0> colour rgb <0,255/255,1>]

  Perhaps you could generate this automatically with #while-loops.

-- 
main(i){char*_="BdsyFBThhHFBThhHFRz]NFTITQF|DJIFHQhhF";while(i=
*_++)for(;i>1;printf("%s",i-70?i&1?"[]":" ":(i=0,"\n")),i/=2);} /*- Warp -*/

Post a reply to this message

Joan Lavoipierre wrote:
> 
> Hi all,
> 
>     Does anyone know of a way to output z buffer information along with
> rendered images? It needs to be fairly accurate since another program is
> going to superimpose realtime 3d shapes which need to interact properly with
> the background. Thanks in advance

I did this once for povray 2.2.

I added a new commandline option, that set a global flag. In the tracing
engine, where the single rays are spawned, I checked after the first
intersection (or a missing intersection), whether the global flag was
set. If z buffer was wanted, I calculated the distance from the
intersection point to the screen pixel. The result was the z-buffer
entry.
I used the RGB value to code a 24bit float (16 bit mantissa, 8 bit
exponent) and returned this new RGB value instead of the color one. With
a little postprocessing (calculating min/max z values, normalizing), I
converted the 24 bit float image into a 16 bit grayscale image.

Unfortunately, I don't have the source any more.

Heiko.

Post a reply to this message