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

Vic,
I don't know which of us is confused, well
I know I'm confused... I hope I'm not just
telling you things you have already considered,
anyway...

when you change the look_at  or location without an
equal change in the other you effectively
rotate the camera, which is different from what
you describe as changing the "screen position"
or shifting the image plane.
The problem you are noticing could be
"keystoneing" which is the geometric distortion
created by rotating the camera.

I think what you want to do is set the
"stereo window".  By adjusting the
location of the boundaries of the image
you can place the z dimension relative
to the viewing plane. In stereoscopic
photography this is usually done when the
images are mounted.

Whenever I make stereo pairs I keep the
cameras parallel by shifting both the location
x dimension and the look_at x by the same
amount. Then there is no distortion. I set the
stereo window by trimming the edges of the
finished image.


patch to POV-Ray called Stereo POV 0.1.
It will create stereo pairs and set the stereo
window so you don't need to trim the
images after they are rendered. Unfortunately
I find his patch troublesome because it is
based on a specific "metric" and confuses
me because I have to design scenes based on
real world proportions, ie camera at 2m and
a stereo separation of 0.065m. I find it difficult
to adjust my existing scenes to fit this metric.

Try his patch and let us know what you think.

http://www.geocities.com/stereopov/

Harolddd

Vic <let### [at] fwhu> wrote in message news:3cca34ad$1@news.povray.org...
> 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

Hi!

> I don't know which of us is confused, well
> I know I'm confused... I hope I'm not just
> telling you things you have already considered,
> anyway...

Sorry about the new tree with the same problem, I accidentally pressed "New
post" instead of "Reply group".

> when you change the look_at  or location without an
> equal change in the other you effectively
> rotate the camera, which is different from what
> you describe as changing the "screen position"
> or shifting the image plane.

I see. It was not logical to me, but I've been lightened some of the
postings.

> The problem you are noticing could be
> "keystoneing" which is the geometric distortion
> created by rotating the camera.

Yes. It is.

> I think what you want to do is set the
> "stereo window".  By adjusting the
> location of the boundaries of the image
> you can place the z dimension relative
> to the viewing plane. In stereoscopic
> photography this is usually done when the
> images are mounted.

I rendered the left and right images independently, then adjusted the views
in my new viewer. But it was not precise, because this method has only one
pixel precision. This is not a big problem, but not correct anyway.

> Whenever I make stereo pairs I keep the
> cameras parallel by shifting both the location
> x dimension and the look_at x by the same
> amount. Then there is no distortion. I set the
> stereo window by trimming the edges of the
> finished image.

This method is used in my viewer also.


> patch to POV-Ray called Stereo POV 0.1.
> It will create stereo pairs and set the stereo
> window so you don't need to trim the
> images after they are rendered.
> Try his patch and let us know what you think.
> http://www.geocities.com/stereopov/

I've downloaded his entire page and read some details. It seems to be good
for my purposes, but supports only Pov 3.1g. I use Pov 3.5 with the improved
Windows GUI and don't want to fall back to Pov 3.1g. I've used Pov 3.1 a lot
2 years ago. I plan to put some of my scenes to a WEB page. I hope Hermann
will port his (at first look) excellent patch to 3.5 in the near future...

As far as I can see I have to write a simple include file with the matrix
transformation proposed by Alex & Slime in a recent posting. There will be
some problems with animation, so I will have to calculate my own "clock"
variable from frame_number. It is also possible to render left and right
animation independently. It's because I have to finish my thesis in three
weeks and I've no time to wait for a new patch. Sorry.

> Unfortunately
> I find his patch troublesome because it is
> based on a specific "metric" and confuses
> me because I have to design scenes based on
> real world proportions, ie camera at 2m and
> a stereo separation of 0.065m. I find it difficult
> to adjust my existing scenes to fit this metric.

The metric is offten confusing to me, but your problem is not clear to me.
In Stereo Pov these properties can be changed by setting stereo_base and the
right and up vectors according to it's documentation. What are the
difficulties with your scenes?

- Vic -

Post a reply to this message

more difficult to use than just rendering two
separate images. To see what I mean, try
rendering the standard benchmark scene
"skyvase". When I tried I could not get
a good stereo pair using Stereo POV, but
it was easy to make two separate left/right
images using my usual method.

To get a good stereo pair from "skyvase.pov"
I only need to use the 1:30 rule (one unit of
stereo base separation for every 30 units of
distance to the main subject of the image).
This 1:30 rule results in two renderings,
with the x dimension of location and look_at
set at 3.33 (right) and -3.33 (left). This makes
a stereo pair with just a little too much stereo
separation because it doesn't take into account
that skyvase.pov has a direction z of 2, which
would be the equivalent of a lens with a long
focal length.

Hermann tried and also had difficulty using
Stereo POV with the skyvase.pov scene,
but with some effort he found settings that
worked. To me it seemed much easier to do
it the old way, but I'll give Stereo POV a few
more tries. Hermann suggested that the problem
with skyvase.pov is that the original author
chose the camera location by trial and error.
I think Stereo POV should work as easily as
my old way, no matter what units are used for
the camera. I imagine a stereo patch to POV
that only requires the user to calculate (or guess)
the stereo base separation and provide a
location for the stereo window.

Give Stereo POV a try with the skyvase scene.

Harolddd

Vic wrote:


> The metric is offten confusing to me, but your problem is not clear to me.
> In Stereo Pov these properties can be changed by setting stereo_base and
the
> right and up vectors according to it's documentation. What are the
> difficulties with your scenes?

Post a reply to this message

Vic wrote:
> I've downloaded his entire page and read some details. It seems to be good
> for my purposes, but supports only Pov 3.1g. I use Pov 3.5 with the improved
> Windows GUI and don't want to fall back to Pov 3.1g. I've used Pov 3.1 a lot
> 2 years ago. I plan to put some of my scenes to a WEB page. I hope Hermann
> will port his (at first look) excellent patch to 3.5 in the near future...
> 

you can be shure I will try to port as soon as the source code for 3.5
is released. Of course I don't know how difficult this will be,
but based on the source code of Mega POV, I would guess, it's not so
difficult. For Mega POV, I would have the problem that the 
post-processing feature hooks in at exactly the same locations my 
patch does, but fortunately, POV-Ray 3.5 has no post-processing :-;

Hermann Vosseler

Post a reply to this message

Harold Baize wrote:

> more difficult to use than just rendering two
> separate images. To see what I mean, try
> rendering the standard benchmark scene
> "skyvase". 

I must admit, that I didn't consider this problem
while designing StereoPOV. Thanks to your Feedback,
Harold, and to the Feedback of some further useres,
that reported similar problems with comparable scenes,
I now have a more clear notion what users may want.

I for my part have the habbit to allways use real world
units in my scenes. In accordance with this, I define
    stereo_base 0.065
and define my objects with 1POV unit = 1 meter

Of course I don't want to force other users into this.

 > Hermann suggested that the problem
 > with skyvase.pov is that the original author
 > chose the camera location by trial and error.

Not the camera location.
The problem when tracing this scene in stereo is,
that the camera is defined at about 1 Unit
while the objects are one order of magnitude larger
(about 50 Units) and as a consequence, are placed at a very
large distance compared with the "direction" vector of the
camera.

In a mono trace, this won't show up, because there only
the aspect ratio and the image angle (focal length) matters.

But in stereo, this is quite different.
When you try to make stereo images of very large objects like
large buildings, mountains or landscapes, you will encounter
some problems. To get the whole view onto the image, you have
to use a large distance. At large distances, the stereo system
won't give much depth reolution anymore, because the separation
between the two eyes, i.e. the "stereo base" is small compared
with the distance.
One common trick is to bring in some foreground objects (trees,
flowers, a person) to show the relations.
Another solution is to increase the stereo base. This will reduce
the visual size of the object but at the same time increase the
depth resolution.

The problem here arises, because I designed all of my stereo cameras
in the Patch in a way, that the stereoscopic window is identical with
the image plane.
As a consequence, if we increase the stereo_base, but let the image
plane at the original dimensions, the both halfimages won't match
anymore. So we have to scale the whole camera as well.

 >
 > Hermann tried and also had difficulty using
 > Stereo POV with the skyvase.pov scene,
 > but with some effort he found settings that
 > worked.

The next step of course is to derive a rule
and than build a "convienience shortcut" into
StereoPOV, that allows to re-adjust the
placement of the window by internally scaling
all camera vectors.

 > I imagine a stereo patch to POV
 > that only requires the user to calculate (or guess)
 > the stereo base separation and provide a
 > location for the stereo window.

I think, the most simple aproach (for the user)
would be:
- you set the distance of the window
- SteroPOV derives the window adjustment
   and sets the stereo_base according to the 1:30 rule.

More advanced users should be able to manualy
set all properties of the stereo camera anyway.


 > I think Stereo POV should work as easily as
 > my old way, no matter what units are used for
 > the camera.
The main reason for me to do the patch was, that
some things are not possible in the "old way".
I mean: Crand,
         Area Lights with jitter
and:    Panoramic and Fisheye camera.

My patch supports this features.

Post a reply to this message

I'm looking forward to your new StereoPov patch with Pov 3.5. Binary
replacements are fine and easy to install. I'll try that one (and not the
3.1g version), because I've to finish my thesis in three weeks and I don't
have time for trial and error. I've used Pov for 3 years, so I'm very
interested in your next patch. - Vic


news:3CC### [at] webconde...
> Vic wrote:
> > I've downloaded his entire page and read some details. It seems to be
good
> > for my purposes, but supports only Pov 3.1g. I use Pov 3.5 with the
improved
> > Windows GUI and don't want to fall back to Pov 3.1g. I've used Pov 3.1 a
lot
> > 2 years ago. I plan to put some of my scenes to a WEB page. I hope
Hermann
> > will port his (at first look) excellent patch to 3.5 in the near
future...
> >
>
> you can be shure I will try to port as soon as the source code for 3.5
> is released. Of course I don't know how difficult this will be,
> but based on the source code of Mega POV, I would guess, it's not so
> difficult. For Mega POV, I would have the problem that the
> post-processing feature hooks in at exactly the same locations my
> patch does, but fortunately, POV-Ray 3.5 has no post-processing :-;
>
> Hermann Vosseler
>
>

Post a reply to this message

Vic,

Maybe when you are done and have time
to relax :-) you could let us know about your
thesis and how stereo POV rendering was part
of it.

Harolddd
"Vic" <let### [at] fwhu> wrote in message news:3cccfcc4@news.povray.org...
> I'm looking forward to your new StereoPov patch with Pov 3.5. Binary
> replacements are fine and easy to install. I'll try that one (and not the
> 3.1g version), because I've to finish my thesis in three weeks and I don't
> have time for trial and error. I've used Pov for 3 years, so I'm very
> interested in your next patch. - Vic
>

> news:3CC### [at] webconde...
> > Vic wrote:
> > > I've downloaded his entire page and read some details. It seems to be
> good
> > > for my purposes, but supports only Pov 3.1g. I use Pov 3.5 with the
> improved
> > > Windows GUI and don't want to fall back to Pov 3.1g. I've used Pov 3.1
a
> lot
> > > 2 years ago. I plan to put some of my scenes to a WEB page. I hope
> Hermann
> > > will port his (at first look) excellent patch to 3.5 in the near
> future...
> > >
> >
> > you can be shure I will try to port as soon as the source code for 3.5
> > is released. Of course I don't know how difficult this will be,
> > but based on the source code of Mega POV, I would guess, it's not so
> > difficult. For Mega POV, I would have the problem that the
> > post-processing feature hooks in at exactly the same locations my
> > patch does, but fortunately, POV-Ray 3.5 has no post-processing :-;
> >
> > Hermann Vosseler
> >
> >
>
>

Post a reply to this message

Hi Harold!

Yes, certainly. I'll send you some material. Unfortunately my thesis is in
Hungarian, so you'll be able to understand only the circuit diagram, the
images and some tables. :-(

I'll explain the main idea of it.
Stay tuned.

-Vic-


"Harold Baize" <bai### [at] itsaucsfedu> wrote in message
news:3ccd9bd4$1@news.povray.org...
> Vic,
>
> Maybe when you are done and have time
> to relax :-) you could let us know about your
> thesis and how stereo POV rendering was part
> of it.
>
> Harolddd
> "Vic" <let### [at] fwhu> wrote in message news:3cccfcc4@news.povray.org...
> > I'm looking forward to your new StereoPov patch with Pov 3.5. Binary
> > replacements are fine and easy to install. I'll try that one (and not
the
> > 3.1g version), because I've to finish my thesis in three weeks and I
don't
> > have time for trial and error. I've used Pov for 3 years, so I'm very
> > interested in your next patch. - Vic
> >

> > news:3CC### [at] webconde...
> > > Vic wrote:
> > > > I've downloaded his entire page and read some details. It seems to
be
> > good
> > > > for my purposes, but supports only Pov 3.1g. I use Pov 3.5 with the
> > improved
> > > > Windows GUI and don't want to fall back to Pov 3.1g. I've used Pov
3.1
> a
> > lot
> > > > 2 years ago. I plan to put some of my scenes to a WEB page. I hope
> > Hermann
> > > > will port his (at first look) excellent patch to 3.5 in the near
> > future...
> > > >
> > >
> > > you can be shure I will try to port as soon as the source code for 3.5
> > > is released. Of course I don't know how difficult this will be,
> > > but based on the source code of Mega POV, I would guess, it's not so
> > > difficult. For Mega POV, I would have the problem that the
> > > post-processing feature hooks in at exactly the same locations my
> > > patch does, but fortunately, POV-Ray 3.5 has no post-processing :-;
> > >
> > > Hermann Vosseler
> > >
> > >
> >
> >
>
>

Post a reply to this message

This is true. I know nothing of Hungary or
Hungarian, but I named my son Zolton!

Harolddd

Vic <let### [at] fwhu> wrote in message news:3ccdb82b@news.povray.org...
> Hi Harold!
>
> Yes, certainly. I'll send you some material. Unfortunately my thesis is in
> Hungarian, so you'll be able to understand only the circuit diagram, the
> images and some tables. :-(
>
> I'll explain the main idea of it.
> Stay tuned.
>
> -Vic-
>
>

Post a reply to this message