Hi Pov fans!

I've made a shutter glass interface hardware and created some stereo
pictures with PovRay. I'm faced with a serious shortage of Pov, namely the
unability to "shift" the camera viewport. The right and up vectors are
always at 0.5, so I've to shift the resulting images after rendering to
match the left and right eye views at the screen plane. (see "The
perspective camera" in Pov help at "Placing the Camera" topic)

Is there any way to shift the image plane during the rendering process?

Important: The shift operation is not equivalent with camera translation. I
cannot use ortographic camera, because stereo rendering is theoretically
based on the perspective one.

>>> My scene:

#version 3.5;

#include "colors.inc"
#include "math.inc"

global_settings {
  assumed_gamma 1.0
  max_trace_level 5
}

// ----------------------------------------

camera {
  #local pp=clock*2-1;
  #local dd=0.06;
  #local xx=-dd*0.5*pp;
  #local yy=0.4;
  #local zz=0.6;
  location  <xx, yy, -zz>
  right     x*image_width/image_height
  look_at   <xx, 0.0,  0.0>
}

sky_sphere {
  pigment {
    gradient y
    color_map {
      [0.0 rgb <0.6,0.7,1.0>]
      [0.7 rgb <0.0,0.0,0.2>]
    }
  }
}

light_source {
  <0, 0, 0>            // light's position (translated below)
  color rgb <1, 1, 1>  // light's color
  translate <-30, 30, -30>
}

// ----------------------------------------

union {
  intersection {
    plane {               // checkered floor
      y, 0
      texture
      {
        pigment {
          checker
          color rgb 1
          color blue 1
          scale 0.2
        }
        finish{
          diffuse 0.8
          ambient 0.1
        }
      }
    }
    cylinder {
      <0,-0.03,0>, <0,0.01,0>, 0.2
      pigment {color red 0.5}
    }
  }

  box {
    <-0.05,0.0001,-0.05>, <0.05,0.1,0.05>
    texture {
      pigment {
        color rgbft <0.1,0.9,0.1,0.5,0.2>
      }
      finish{
        diffuse 0.4
        phong 0.3
        ambient 0.2
        specular 0.1
      }
    }
    rotate 25*y
  }

  translate 0.0*z
}

>>> Render with these settings (quickres.ini):

[1024x768, AA 0.3 Stereo]
Width=1024
Height=768
Antialias=On
Initial_Frame=1
Final_Frame=2
Initial_Clock=0
Final_Clock=1
Cyclic_Animation=off

The center point of the checker pattern (the <0,0,0> point) must match on
the first and second frames (the left and right eye views). The camera can
be rotated such a way by modifying look_at to look_at <0.0, 0.0,  0.0>, but
this introduces a perspective distortion of the X axis. The images must be
shifted on the X axis by half eye-distance, but there's no way to do this in
Pov.

Sorry about my poor English.

Thanks for your help, Vic

Post a reply to this message

If I understand what you're saying correctly, this can be done with a matrix
transformation.

- Slime
[ http://www.slimeland.com/ ]
[ http://www.slimeland.com/images/ ]

Post a reply to this message

Vic <let### [at] fwhu> wrote:
> I've made a shutter glass interface hardware and created some stereo
> pictures with PovRay.

  Unrelated to the question in itself, but AFAIK the most accurate way
of getting a stereo image pair is precisely changing the location of the
camera while keeping the look_at where the camera is "looking at".
  This simulates what happens with your eyes and thus is the most correct
simulation of a stereo image.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

I've uploaded some scenes and rendered images of this problem to:

http://www.cx.hu/pov/stereo1/index.html

Thanks for your help - Vic

Post a reply to this message

I don't think you are trying to apply stereo images properly.  In your
images, what you are calling bad (Maintaining the look_at while moving the
camera) is actually proper.  The fact that it strains the eyes is reality.
Hold a plate to the bridge of your nose and try to focus on the front and
back edges at the same time... impossible.  This is effectively what should
happen to the disc in your picture. Since it is relatively flat compared to
the viewing angle, it should be difficult to focus in on the whole disc in a
stereogram just as in reality. Or maybe i misunderstand what you want to
achieve.

-tgq

Post a reply to this message

Hi!

> I don't think you are trying to apply stereo images properly.  In your
> images, what you are calling bad (Maintaining the look_at while moving the
> camera) is actually proper.  The fact that it strains the eyes is reality.
> Hold a plate to the bridge of your nose and try to focus on the front and
> back edges at the same time... impossible.  This is effectively what
should
> happen to the disc in your picture.

The effect you mentioned is reality, but my problem is not that. I
understand, that someone cannot focus to different distances at the same
time.

> Since it is relatively flat compared to
> the viewing angle, it should be difficult to focus in on the whole disc in
a
> stereogram just as in reality. Or maybe i misunderstand what you want to
> achieve.

The answer to my question affects my thesis at Technical University of
Budapest ( http://www.bme.hu ), so I keep on searching for an answer. Thank
you for your patience.

My problem is the tilt of the horizontal lines appears on my "bad" pictures,
not the depth of my objects. The effect is very similar (but not identical)
to a slight rotation around the Z axis. This renders the left and right
images wrong. Please compare the horizontal blue-white transitions on the
checker texture on the "bad" and "good" versions.

It seems to be impossible to render a part of the image plane other than
<-0.5,-0.5>-<0.5,0.5> (right and up vectors respectively). These limits
seems to be graven into stone when using a perspective camera. Using
rendering settings like start_row, end_row, start_column, end_column is not
enough, because they have only pixel precision and hard to integrate with
camera placement.

Is there a way to set the "viewport limits" to other values than
<-0.5,-0.5>-<0.5,0.5>?

I will try to make some material with more descriptive examples if the
problem is not clear enought.

Again: Thank you for your patience.

- Vic -

Post a reply to this message

In article <3cca6837@news.povray.org> , "Vic" <let### [at] fwhu> wrote:

> My problem is the tilt of the horizontal lines appears on my "bad" pictures,
> not the depth of my objects. The effect is very similar (but not identical)
> to a slight rotation around the Z axis. This renders the left and right
> images wrong.

But they are not wrong!  As soon as your eyes focus on something this is
precisely the effect you have.  What you are trying to generate is an image
infinitely far away, so your eyes have to look nearly parallel.

> viewport limits

As you keep talking about viewport limits I suppose your problems
understanding the correct behavior come from the use of z-buffer based
algorithms.  It is indeed true that for those when rendering stereo views the
viewport is commonly moved, but this is only an approximation necessary to
avoid having to transform the whole scene in order to keep the rendering fast.
The image you call "bad" is actually the correct image for a stereo view of a
human eye and the "good" one a simple approximation similar to those commonly
produced by a z-buffer based stereo renderer.

    Thorsten

____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

If you change the camera location but don't
change the look_at it will rotate the camera
and introduce "keystone" distortion. In the
real world our eyes do rotate (converge) when
we look at something close, and our perceptual
system (brain) compensates for the distortion.
Unfortunately, when we view stereo images our
viewing methods can't recreate this convergence
and as a result we see distortion. To avoid this
stereo pairs should be created with parallel
cameras.

The rare exception to keeping the cameras
parallel this is in electron microscopy where
the object itself is rotated. The resulting image
doen't have noticeable keystone distortion
because of the shallow depth of field.

Harolddd



Warp said:

>   Unrelated to the question in itself, but AFAIK the most accurate way
> of getting a stereo image pair is precisely changing the location of the
> camera while keeping the look_at where the camera is "looking at".
>   This simulates what happens with your eyes and thus is the most correct
> simulation of a stereo image.

Post a reply to this message

Thorsten said:
> But they are not wrong!  As soon as your eyes focus on something this is
> precisely the effect you have.  What you are trying to generate is an
image
> infinitely far away, so your eyes have to look nearly parallel.

That is true, our EYES see the images this way, but our brain does not.
I don't think he is trying to generate an image at infinity, but expects it
to look as if it were at infinity, because he (we) can't recreate the
viewing experience of looking at a scene close to our face. Also, it
is convergence that is the issue, not focus. The eyes cross (converge)
on close objects.

Our eyes begin to converge from parallel at about 2m (six feet), we
don't notice it until things are close, like 0.3m. Our perception
adjusts for geometric distortion and other issues when we focus
close and converge our eyes, for example we ignore the distant
background which is out of focus and can't be stereoscopically
fused (it is a "double image"). Minor keystone distortion is likewise
ignored. When we view a pair of images rendered from this geometry later
on the computer screen it is disturbing because we don't have the
ability to ignore or compensate for the distortions because we are
viewing it in a different context and with parallel eyes focused at a
different depth. That is why one should always generate stereo
pairs with parallel cameras. The issue becomes how to set the
"stereo window" which is the virtual frame created by the edge of
the image. I set the stereo window by trimming the left and right
edges of the stereo pairs.

> As you keep talking about viewport limits I suppose your problems
> understanding the correct behavior come from the use of z-buffer based
> algorithms.  It is indeed true that for those when rendering stereo views
the
> viewport is commonly moved, but this is only an approximation necessary to
> avoid having to transform the whole scene in order to keep the rendering
fast.
> The image you call "bad" is actually the correct image for a stereo view
of a
> human eye and the "good" one a simple approximation similar to those
commonly
> produced by a z-buffer based stereo renderer.

I know nothing of z-buffer based algorithms, but I would argue that the
image
Vic labeled as "good" was rendered correctly for stereo viewing, and the
"bad" image was rendered accurately for what the eye sees, but not for what
the brain perceives or for stereo viewing.

Harolddd

Post a reply to this message

In message <3cc9ce28@news.povray.org>, Vic <let### [at] fwhu> writes
>Hi Pov fans!
>
>I've made a shutter glass interface hardware and created some stereo
>pictures with PovRay. I'm faced with a serious shortage of Pov, namely the
>unability to "shift" the camera viewport. The right and up vectors are
>always at 0.5, so I've to shift the resulting images after rendering to
>match the left and right eye views at the screen plane. (see "The
>perspective camera" in Pov help at "Placing the Camera" topic)
>
>Is there any way to shift the image plane during the rendering process?
>
I was going to suggest changing the direction vector, but unfortunately 
this does not work at all logically.
The docs say "Note: that the up, right, and direction vectors should 
always remain perpendicular to each other or the image will be 
distorted.", but knocking up a short test scene I find the povray (3.5) 
*forces* the vectors to be perpendicular. Whilst non-perpendicular 
vectors do distort the scene, it does not do it in the way I would 
expect (and which allow the camera viewport to be shifted).

Slime suggests using the matrix transformation, which will allow you to 
shift the image plane.

matrix <1,0,sf,
         0,1,0,
         0,0,1,
         0,0,0>

where sf is the shear required (use +/- for R/L images respectively

    x
   ____      sf=x/z
   \   |
    \  |  z
     \ |
      \|

But this doesn't quite work as expected, causing a slight stretch in the 
image along the x-axis. The fix is to use

matrix <sqrt(1+sf^2),0,sf,
                    0,1,0,
                    0,0,1,
                    0,0,0>
>
>camera {
>  #local pp=clock*2-1;
>  #local dd=0.06;
>  #local xx=-dd*0.5*pp;
>  #local yy=0.4;
>  #local zz=0.6;
>  location  <xx, yy, -zz>
>  right     x*image_width/image_height
>  look_at   <xx, 0.0,  0.0>
>}
>

This ought to work:

camera {
   #local pp=cl0ck*2-1;
   #local dd=0.06;
   #local xx=-dd*0.5*pp;
   #local yy=0.4;
   #local zz=0.6;
   #local sf=xx/zz;
   location  <xx, yy, -zz>
   right     x*image_width/image_height
   look_at   <0, 0.0,  0.0>

   matrix <sqrt(1+sf^2),0,-sf,
                    0,1,0,
                    0,0,1,
                    0,0,0>
}

The other thing that doesn't work as expected is the look_at. I would 
have expected to look_at <xx,0,0> (parallel to the z-axis) and the 
matrix to deform the camera to look at the origin.


Can I have a new camera please, this one's broken (shakes it and hears 
glass rattling about inside).
-- 
Alex

Post a reply to this message