Hi Alex!

> I was going to suggest changing the direction vector, but unfortunately
> this does not work at all logically.

Unfortunately, not.

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

Yes, it's in the documentation on the "matrix keyword" page and mentioned as
shearing.

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

I had to turn off vista buffer, because Pov refused to render the image
(camera vectors are not perpendicular).

Stereo images now look good and not shifted away!
Thanks, this works corretly as I expected.

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

There would be a camera modifier in PovRay supporting stereo images, like:

camera {
    ...
    eye_distance 0.06
    ...
}

This should generate two images for each frame: a left eye view and a right
eye view, such as:

Stereo.pov =>
Stereo01L.bmp
Stereo01R.bmp
Stereo02L.bmp
Stereo02R.bmp
...

This could simplify stereo animation, because on the one hand it's not
needed to calculate a new clock variable according to frame_number, on the
other hand left and right images can be separated and processed easily.

A command line/configuration paramter can also be useful to support stereo
view of existing scenes.

Thanks to the Pov newsgroup, my problem has been solved.

Special thanks to: Alex, Slime and Harolddd

- Vic -

Post a reply to this message

Thanks Harold!

You've described my problem successfully!
Alex and slime were able to solve my problem.
After reading your description?
;-)))

- Vic -

---------------------------------------------------------------

"Harold Baize" <bai### [at] itsaucsfedu> wrote in message
news:3ccb18a8@news.povray.org...
>
> 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 <3ccbc0a8@news.povray.org>, Vic <let### [at] fwhu> writes
>Hi Alex!
>
<snip>
>
>There would be a camera modifier in PovRay supporting stereo images, like:
>
>camera {
>    ...
>    eye_distance 0.06
>    ...
>}
>
I was rather expecting something along the lines of the following to 
work:

#declare offset=1   // +1 for left eye, -1 for right, (0 for cyclops!)
camera {
   right <4,0,0>
   up <0,3,0>
   direction <offset,0,4>
   location <-5*offset,0,-20>
   look_at <0,0,0>
   }

but all that happens is the 'right' vector gets rotated to be 
perpendicular to the direction vector, causing the keystone distortion 
mentioned elsewhere in this thread.

>This should generate two images for each frame: a left eye view and a right
>eye view, such as:
>
>Stereo.pov =>
>Stereo01L.bmp
>Stereo01R.bmp
>Stereo02L.bmp
>Stereo02R.bmp
>...
>
>This could simplify stereo animation, because on the one hand it's not
>needed to calculate a new clock variable according to frame_number, on the
>other hand left and right images can be separated and processed easily.
>
>A command line/configuration paramter can also be useful to support stereo
>view of existing scenes.
>
I'd just create a .pov file to render the left eye as stereoL.pov, then 
just modify it for the right eye and save as stereoR.pov. But I'm just 
lazy....

-- 
Alex

Post a reply to this message

Alex wrote:
> I was rather expecting something along the lines of the following to work:
> 
> #declare offset=1   // +1 for left eye, -1 for right, (0 for cyclops!)
> camera {
>   right <4,0,0>
>   up <0,3,0>
>   direction <offset,0,4>
>   location <-5*offset,0,-20>
>   look_at <0,0,0>
>   }
> 
> but all that happens is the 'right' vector gets rotated to be 
> perpendicular to the direction vector, causing the keystone distortion 
> mentioned elsewhere in this thread.
> 

Oh my God!
This *DID* work allways. I created dozens of stereo pairs with
POV-Ray versions prior to 3.5 by using this approach.

If the 3.5 perspective camera rotates the vectors, I would
consider this clearly a bug. What, if someone wants to make
a shift (like shift optics at real world cameras) ??

<rant>
I think, it is wrong to break a working feature that is
commonly needed by advanced users in order to make things
more easy for the newbies.
</rant>


Ok ok--
I shouldn't complain.

If  POV 3.5 's camera would be broken in this way,
all Stereo enthusiasts were forced to use my StereoPOV patch :-;

Post a reply to this message

Harold Baize wrote:
> 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.

Some time ago I saw a specialized stereo viewer that simulated
this cross converging for objects rather very near to the eyes.
It was used to show macro stereo images of some machinery or
technical constructions.
But such a thing only works with a stereo viewer with lenses.

For presenting stereo images on a computer monitor or on a
slide projection screen, we have to consider, that both half images
are presented on the same (screen) plane. Because of this, the
image planes used to create the halfimages need to be aligned as
well, otherwise you will get the keystone distortions Harold Baize
mentioned when bringing the two halfimages on a single plane for
presentation.

Btw., our eyes have a curved image plane (retina) and can be turned.
And the brain compensates as well.

When making stereoscopic images, we don't simulate the human eye/brain
system itself. But we rather create a view, that can be percepted by
the human eye/brain system in a way similar to the natural two-eyed
3D viewing.

Post a reply to this message

wrote:

> This *DID* work always.

No, the example you are quoting never worked.  When look_at was applied
POV-Ray always made the up and right vectors perpendicular.  If you didn't
want perpendicular up and right vectors, you could not use look_at.  The same
is still true in POV-Ray 3.5.

    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

Thorsten Froehlich wrote:

>>This *DID* work always.
> 
> No, the example you are quoting never worked.  When look_at was applied
> POV-Ray always made the up and right vectors perpendicular.  If you didn't
> want perpendicular up and right vectors, you could not use look_at.  The same
> is still true in POV-Ray 3.5.
> 

Thanks, I overlooked the "look_at".
I never used look_at when generating stereo pairs.

But if we omit look_at, we can use non-perpendicular right and
direction vectors, is this correct?

If this were correct, the mentioned problem could be solved this way,
without the need of a matrix transform.
Of course it is inconvienient to set up the camera without look_at,
but one could write a macro for this.

Hermann

Post a reply to this message

In message <3ccc75bc@news.povray.org>, Thorsten Froehlich 
<tho### [at] trfde> writes

>wrote:
>
>> This *DID* work always.
>
>No, the example you are quoting never worked.  When look_at was applied
>POV-Ray always made the up and right vectors perpendicular.

Ah, now that's interesting. Shame the beta's just expired, I was gonna 
experiment with this.

>If you didn't
>want perpendicular up and right vectors, you could not use look_at.  The same
>is still true in POV-Ray 3.5.
>
>    Thorsten

-- 
Alex

Post a reply to this message

Hi Pov fans!

Bad news: The "matrix" solution is wrong. It works only if the camera
direction vector is very close to the z axis. Sorry guys, other solution is
required. Other matrix values? Manual camera setup including a replacement
of look_at?


solution. Only stereo_base required and scene parsing and transformations
can be reused efficiently. The stereo cache has some problems (sky_sphere
and others), but it could be a good idea.

I'm trying to create my own "Stereo.inc" include file with a special camera
macro to set up a stereo camera. Left and right images are based on the
lowest bit of frame_number, so new clock and frame_number constants had to
be introduced. Animations always have a doubled number of frames, and so on.
This is only an "transitional" solution. Pov should provide support for
stereo_base camera modifier and a double-width output image format, like the
StereoPov patch.

I'll try to implement this feature if I have time to do this.
But now, I've to work on my thesis and 3 other applications.

Best wishes - Vic

Post a reply to this message

Vic wrote:
> Bad news: The "matrix" solution is wrong. It works
> only if the camera direction vector is very close
> to the z axis. Sorry guys, other solution is required.
> Other matrix values?

Yes. A single matrix transformation can be used to specify any possible
transformation. Place the camera at the origin facing in the +z
direction and then use just the matrix to align the camera. The first
three values are used for the x (right) vector, the next three the y
(up) vector, the next three for the z (direction) vector and the last
three for the location.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:  http://rsj.mobilixnet.dk (updated Apr 14)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Ring:  http://webring.povray.co.uk

Post a reply to this message