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

Nieminen Mika <war### [at] cctutfi> writes:

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

Yeah, sure.  That was just to show the point (it's more explicit to
show the result of the parsing of the loop than to show the loop).

  Anyway, I would not do it with a #while loop, rather with a Perl
program.  If I ever need to write such a program, I guess it could
easily be made universal enough so that it be able to take any POV-Ray
scene file (with the textures and all) and change everything to the
convenient z-buffer texture.  No need to make it by hand!

Roland.
-- 
Roland Mas

Sauvez les castors, plantez des arbres.

Post a reply to this message

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

But size of color_map is limited.

Post a reply to this message