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