(I think, I should post this here as well,
 because discussion on patches rather goes on here)
 -----------------------

Hi all,

as promised, I am now working on the POV 3.5 based release of
my Stereo-Tracing-Patch. After a first review of the new sources,
it seems not so hard a work, as I had feared. THANKS TO POV-TEAM!
(especially for not including post-processing :-P )


The feedback of the users (I got much more feedback, than I expected
for such a exotic patch) did not uncover bugs I didn't alredy know.
But it showed, that the usage of my stereoscopic cameras can be
difficult, especially when trying to trace existing scenes not
specifically designed for real-3D-viewing.
So I want to introduce some new parameters or "convinience shortcuts"
to the cameras. With this I mean parameters of the sort of POV-Ray's
"look_at": It adjusts the camera vectors at parse time, but doesn't
alter the internal working of the camera.

I want to do a proposal and hope to get some further suggestions.


_EXPLANATION_

StereoPOV 0.1 was based on POV 3.1g. It is here:
http://wwww.geocities.com/StereoPOV/

In principle, it is very easy to create stereoscopic images with
standard POV-Ray. Simply shift the camera laterally by a small
amount and trace a second image. If you later on e.g. want to make
slides out of this images, you normally have to crop the two half-
images in an image manipulation programm in order to set a
stereoscopic window. In most cases, this can be done intuitively,
by looking at the result (cross-eyed view, wall-eyed view, LCD
shutter glasses...).

StereoPOV comes in where this simple aproach has its limitations.
- It computes both half images simultaneously and shares
  lighting and texturing computations between both halfs.
- The latter ensures that both sides get the same results.
  This is especially important on small, anti-aliased structures
  and enables the use of area lights with jitter.
- Stereoscopy is built into the cameras; this allows for non-standard
  camera types specifically designed for creating stereoscopic output.
  The cameras are defined in a way that the resulting images are
  alredy adjusted for viewing on a screen of a given size.


The last point seems to cause the troubles, because it forces
the user to consider the dimensions and locations the objects
shall show up with respect to the intended, final presentation
of the image.

All cameras in StereoPOV conform to the following rule:
The user explicitely sets a stereo_base. The stereoscopic
window is located in the image plane, i.e. (location + direction)
and it has the size given by the up and right vector.
StereoPOV makes *no* assumptions as to what is the
relation of 1 POV-Ray unit to the real-world eye-distance
of the viewer. It is up to the user to use sensible units
and parameters.


_PROPOSAL_

In order to ease the use and selection of the right camera
parameters, I want to propose the following extensions:

(a) a heuristic to guess the stereo_base. Somewhat like
    the "1:30" or - better - the "1/f"-Rule (empirical
    rule well known and approved in stereoscopy).
    I am not quite clear at this point, because the
    named rules seem implicitely to contain a relation
    to fixed units (format of the film in camera, focal
    length, size and aspect ratio of "normal" projection

Post a reply to this message

Hi Patrick Elliott,

I tried to respond to your email, but the message was undeliverable.
Since you read my post, I will post my answer here.

 >
 > Umm.... Having taken a look at your page... I have to wonder why you
 > couldn't have simply added behaviour that didn't emply a stereo
 > cache? ...

What you describe would be perfectly feasible and can be implemented
on one evening. But then the question would be, why bother to make a
stereo-patch at all? Generating stereoscopic pairs with POV-Ray is
simple and indeed I (and many other stereo-enthusiasts) are doing
it since the first days of POV-Ray. Some people use special macros for
camera placement or rendering of the two half images in an animation
loop.

But with increasing quality demands I ran into the following problems
- rendering time (six days instead of three)
- jitter in area lights shows up in stereo (same with photons)
- problems with small features coming out rather different on both
    halfimages.

Besides that, implementing new camera types (and creating complicated
data structures) ist fun.

 >
 > Since either method would be using the normal means of generating
 > images, usually used by the crop and paste method, and the final
 > camera should actually be the same as with it off, I would think you
 > wouldn't get any of the image glitches you mention and lighting from
 > refracting and the like would still work.
 >

Maybe I should have mentioned the following more clear on my webpage:
- StereoPOV uses the normal means of generating images. Only *after*
    calculating the intersection for the second halfimage, it hooks in
    and re-uses some results from the first one.
- you can switch off the StereoCache (with the option stereo_cache=0).
    Then you basically get two independent renders going on
    side-by-side
- reflection and refraction *do* work. Only the StereoCache doesn't
    work on reflected/refracted rays. So you there get the artefacts on
    area lights, that you would have gotten on the whole image without
    using the cache.
- the glitches when using no backgound or skysphere are a known bug;
    I think, they will be fixed in the version I am currently working
    on. The irregularities on antialiased borders seem a rather minor
    problem to me, but rather hard to fix though.

 > .... but I would tend to think that
 > the problems that result from it kind of outway the gains.

Really can't judge this. For me, the patch is an improvement and
likely I will be building some further features on it.
 From the users feedback I got the impression that people
have rather problems setting up the camera (which is indeed
non-trivial with real world stereoscopic photography as well),
then having any troulbe with image glitches.


 > Then I could just be blowing smoke.
 > I am by no means an expert on how POV or 3D works.

never mind, I am appreciating all sorts of suggesions, critics etc.

Hermann


 >
 > -------
 > main ()

 >     call functional_code()
 >   else
 >     call crash_windows();
 >   }
 >
great idea for a POV patch, but portability seems to be a problem...

Post a reply to this message

On Fri, 09 Aug 2002 22:24:54 +0200, Hermann Vosseler <Ich### [at] webde> wrote:
> Hi Patrick Elliott,
> 
> I tried to respond to your email, but the message was undeliverable.
> Since you read my post, I will post my answer here.
Odd.. Must have put my name in, instead of my address when I sent.... Some of the
'features' of opera, which I use to read news groups, tend to leave a bit to be
desired.
Should you reply to this post, you will see one of the most annoying. It doesn't
correctly
direct followup postings and thus answering it apparently requires hand editing a
field.
Of course I also have to hand edit it to get it to post to the correct thread, so
everyone
gets annoyed.

I have another program installed, but I hate using it, because desipte all the
glitches in
Opera's news reader, I can look at binary attachments within the actually document.
Using the one I downloaded I can't reliably have it decode the bloody things (if I
have
it try it then refused to display any text). :p Oh, well.. One of these days hopefully
either
Opera will fix its goofy reader or someone will figure out that being able to view
attachments,
that contain 'only' pictures, is both safe and a lot more convenient than having to
hit decode
every bloody time. ;)

> But with increasing quality demands I ran into the following problems
> - rendering time (six days instead of three)
Yeah. I had kind of figured that. For myself I would rather get it right and not
need post work, than have to fiddle with them in PSP or photoshop to fix them,
but that is just me.

> 
> Besides that, implementing new camera types (and creating complicated
> data structures) ist fun.
Actually creating new ones is not needed, you already mention below that your
patch already does what I was thinking.

> - you can switch off the StereoCache (with the option stereo_cache=0).
>     Then you basically get two independent renders going on
>     side-by-side
See ;)

> - reflection and refraction *do* work. Only the StereoCache doesn't
>     work on reflected/refracted rays. So you there get the artefacts on
>     area lights, that you would have gotten on the whole image without
>     using the cache.
Ah, yes this one item is a bit confusing. As it reads, your site seems to imply that
no method exists with you patch that doesn't have that problem.


Hmm.. Actually, I am fairly certain that MicroSloth already has a trademark on my
tagline,
I am 99% certain it is in the main execution block of nearly every OS component they
publish. ;) lol
---------
main ()

    call functional_code()
  else
    call crash_windows();
  }

Post a reply to this message