Vic wrote:
 > The camera setup in Stereo.inc is wrong. Harolddd wrote, that only
 > parallel left and right cameras gives good result. He is right.
 > Nonparallel direction vectors causes eye divergence at large to
 > infinite distances. Plus it's impossible to use vista buffer
 > because of the non-perpendicular camera vectors.
 >

Vic,

I would be carefull -- I don't consider this conclusion correct.
Maybe we need to be a bit more precise. Not the cameras as a whole
have to be parallel, but the image planes have to be parallel. This
is, because we want to present the final image on a single plane or
screen.
Now it is a property of the perspective projection, that shifting
the center of projection (is this the right word?) and moving the
"viewport", i.e. Image shift or cropping at one side are aequivalent.
You can't tell by the final result, if the image was shifted, or
the optical axis was non-orthogonal.
So we can't conclude that nonparallel direction vectors are causing
divergence in general. Divergence will result only if the alignement
of the final images is wrong. This can happen, if the images are
scaled (enlarged) without compensating the alignement.
If you make a stereo pair with parallel direction vectors and parallel
image planes and then crop and align the resulting image in order to
get a stereoscopic window, the resulting image will be exactly the
same, as you would get by converging direction vectors.
The only real difference is, that the aproach with completely parallel
cameras and adjusting by post-processing (cropping, aligning) the
images is much more simple to carry out. In many cases, you can make
the post-processing under "visual control", i.e. you crop and align
until the stereoscopic window looks right.

With non-orthogonal direction vectors, there are two issues.
(a) can't use look_at
(b) can't use vista buffer.

Both are not so important, in my opinion.
(a) You can use transformations in the camera definition.
Set up your camera at the origin, then orient your camera with
rotations and finally tanslate your camera to the location you
want it. With a bit of trial and error, you get it right this
way without using look_at. Of course, it will be more easy if
you first set up your camera ant then arrange the objects
accordingly. You can then make fine adjustments of the camera
by the transformations mentioned.
(b) Vista buffer has not to be confused with bounding slabs.
Bounding slabs are OK with non-standard camera types. Bounding
slabs give the big performance boost, vista buffer will be
important only if you use very much objects in your scene.
To put it a bit simplified: vista buffer is only a optimization
of the bounding slab calculations by precalculating some common
values for every line of piexels.


 > My conclusion: Cameras built into POV-Ray cannot render a stereo
 > pair properly.

I would not say that. I made a dozens of stereo pairs with converging
direction vectors. Results are perfect, window works out-of-the-box
and you have the big advance of precise control where the window will
be. For standard perspective camera, StereoPOV does the same
internally.

Short -- I consider your include file to be correct.

Hermann

Post a reply to this message

Vic wrote:
 > I've made a new Stereo.inc include file to support stereoscopic
 > windows.
 >
 > This perspective camera seems to work correctly with POV-Ray for
 > Windows RC2.
 >
 > Harolddd: Please try this one. Hermann: How did you calculate the
 > camera matrix in StereoPov?
 >
 > Every comments are welcome.
 >
 > - Vic -
 >

Vic,

below is the relevant section of the StereoPOV source code.
I edited it and removed all internal implementation details.
So, what you see is rather C-like pseudo code :-;

This section of code is called for every pixel. At this point,
the camera vectors are allredy set up; all transformations
are aplied while parsing the scene code.
(Btw: if Stereo_base is defined negative, you will get a cross-eyed
stereo pair, that can be converted to *.JPS or *.PNS directly).


Bottom line is: StereoPOV does the same your include file does.

hope this helps.





------------------------------------------------------------------
   /* Just some shortcuts. */

#define FCD Frame.Camera->Direction
#define FCR Frame.Camera->Right
#define FCU Frame.Camera->Up
#define FCL Frame.Camera->Location



   /* Precompute some constants for stereoscopy */

       Stereo_shift = VNormalize(FCR);
       Stereo_shift = Stereo_shift *  0.5 * Frame.Camera->Stereo_base;





   /* Convert the x coordinate to be a DBL from -0.5 to 0.5. */

   x0 = x / Frame.Screen_Width - 0.5;

   /* Convert the y coordinate to be a DBL from -0.5 to 0.5. */

   y0 = ((Frame.Screen_Height - 1) - y) / Frame.Screen_Height - 0.5;



       /* Create primary ray. */

          cam_Ll =  1.0 * FCL  - Stereo_shift;
          cam_Lr =  1.0 * FCL  + Stereo_shift;
          cam_Dl =  1.0 * FCD  + Stereo_shift;
          cam_Dr =  1.0 * FCD  - Stereo_shift;


         if (right_image)
         { /* right view */
           Ray->Initial   =  cam_Lr;
           Ray->Direction =  cam_Dr  +  x0 * FCR  +  y0 * FCU;
         }
         else
         { /* left view */
           Ray->Initial   =  cam_Ll;
           Ray->Direction =  cam_Dl  +  x0 * FCR  +  y0 * FCU;
         }

Post a reply to this message

Hermann Vosseler wrote:
 > (a) You can use transformations in the camera definition. Set up
 > your camera at the origin, then orient your camera with rotations
 > and finally tanslate your camera to the location you want it.

I forget to say: of course, you have to aply the transformations
to your stereo-shift (i.e. stereo base vector) as well. Because this
has to be done manually, it is error phrone and often causes 
frustration. But your macro alredy solves this problem.

Hermann

Post a reply to this message

"Harold Baize" <bai### [at] itsaucsfedu> wrote in message
news:3ccf181b$1@news.povray.org...
> Well, he recognizes the need for parallel cameras and
> has a formula for determining how much to trim from
> the rendered images, but doesn't describe a way to
> have POV render directly to the trimmed state, which
> is what we're trying to figure out. I think...

Yes. We're trying to find a solution to do this "trim", but not with pixel
precision. Correct camera setup can "trim" the images with sub-pixel
resolution, so things can be rendered at precise distance from the image
plane. - Vic

Post a reply to this message

Vic,
I don't see why anyone would need "sub-pixel" precision in
the placement of the view plane (stereo window). In the art
of stereoscopic photography the placement of the stereo
window is a matter of artistic license and aesthetic preference,
except when objects are eclipsed by the edge of the window.
To extend through the stereo window is fine, but when objects
are cut off by the edge of the stereo window it is considered bad,
and called "window violation". Great precision is not usually
required to avoid window violation.

Harolddd
ps. I've been distracted these last few days with that darn "real life"
thing, so haven't posted.

"Vic" <let### [at] fwhu> wrote in message news:3cd1486a@news.povray.org...
>
> Yes. We're trying to find a solution to do this "trim", but not with pixel
> precision. Correct camera setup can "trim" the images with sub-pixel
> resolution, so things can be rendered at precise distance from the image
> plane. - Vic
>
>

Post a reply to this message

Hermann,

Thank your for your help. Many critical paramateres have been enlightened by
your detailed description. Some of these are already known for me (such as
vertical alignment and the hard limit at infinity (avoiding divergence)). I
can't diverge my eyes, so I don't have almost "infinite" tolerance against
this kind of distortion. Your comments on this subject are invaluable
for me.

Anyway, the possibility of setting up a correct stereo window using only the
native POV-Ray distribution is a bit annoying. A fully custom camera type
can solve the problem, where the ray setup functions could be defined by the
user. At least the range of right and up vector multipliers should be
changed to produce a correct pair.

Best wishes, Vic

Post a reply to this message

in news:3cd18481$1@news.povray.org Harold Baize wrote:

> Great precision is not usually
> required to avoid window violation.
> 

In that case why don't you just render the stereo pair from an ini-file 
and use the post-frame command to starts a bat file that starts an 
application that crops the images (nconvert, image-magick, netpbm). Use 
the stereo include file to write the bat-file, depending on wether you 
render the right or left image and set the amount to be chopped off.

Ingo

Post a reply to this message

Well I do use ini files in the generation of stereo pairs, but have not
tried to automate using an application for post rendering cropping.
Usually I like to look at the image after it is rendered and decide on
where to place the stereo window. There are stereo image editing
programs for setting the stereo window using a GUI. I was addressing
Vic's call for stereo rendering without post-processing and the need
for high precision.

I'm intrigued by Ib Rasmussen's idea (see the "moving the vanishing
point" thread) of using  Start_Column and End_Column
parameters to effectively crop the image when rendered. It would
simplify the process considerably and save time. That may
prove more satisfactory to people like me who find the application
of camera vector shearing algorithms too confusing when applied
to existing POV scenes that don't use "real world" metrics. Although,
the placement of the stereo window would need to be decided upon
before rendering.

Harolddd



"ingo" <ing### [at] homenl> wrote in message
news:Xns### [at] povrayorg...
> in news:3cd18481$1@news.povray.org Harold Baize wrote:
>
> > Great precision is not usually
> > required to avoid window violation.
> >
>
> In that case why don't you just render the stereo pair from an ini-file
> and use the post-frame command to starts a bat file that starts an
> application that crops the images (nconvert, image-magick, netpbm). Use
> the stereo include file to write the bat-file, depending on wether you
> render the right or left image and set the amount to be chopped off.
>
> Ingo

Post a reply to this message

> I don't see why anyone would need "sub-pixel" precision in
> the placement of the view plane (stereo window).

Precision is "required", because I would like to place my object relative to
the plane of the screen (the image plane, the monitor, etc.). It is the
natural positioning system for me and it's the only fixed point on the Z
axis (depth).

This can be some kind of "maximalism". ;-)))

- Vic -

Post a reply to this message

> In that case why don't you just render the stereo pair from an ini-file
> and use the post-frame command to starts a bat file that starts an
> application that crops the images (nconvert, image-magick, netpbm). Use
> the stereo include file to write the bat-file, depending on wether you
> render the right or left image and set the amount to be chopped off.

Thanks for this idea, but it has been considered. I've decided to use the
already implemented correction in my stereo viewer and not to bother with
the camera setting this time. But I don't give up! It's essential to be able
to set up stereo camera pairs correctly in Pov. I'll wait for Hermann's
StereoPov patch to do this.

- Vic -

Post a reply to this message