Have some mixed feelings about this change.

Even keeping code aside, did i get it right that using stereo 3d implies using spherical mapping? If so,why it's nt a panorama type?

Leaving code aside for now.

Why it's not a panorama type?

This is a method that can be used for Fisheye renders as well, so to have it as its own 'panorama' type would imply on having "equirectangular / equirectangular omnidirectional / fisheye / fisheye omnidirectional" which (as far as UI goes) is not ideal.

Did i get it right that using stereo 3d implies using spherical mapping?

Not really. If someone is mixing real captured fisheye stereo footage with rendered fisheye renders the traditional method is required. If someone is doing 100% fisheye/panorama render than the present method is preferable.

Sharing comments done form debalie review session.

This is a confusing logic. First of all, you define render engine to have bl_use_spherical_stereo, and then in the engine itself you call use_spherical_stereo() which not only checks camera settings but also does render engine verification. This is totally redundant.

The only case where such flag might do difference is in the camera shift/matrix calculation, so enabling spherical stereo doesn't affect other engines. But even then, wouldn't it make more sense to pass a boolean argument to those function about whether you're interested in spherical case or regular one? Could simplify code for the Cycles i think:

bcam->use_spherical = b_engine.use_spherical_stereo();
bcam->matrix = b_engine.camera_matrix(bcam->use_spherical)

Or something like that. Just trying to simplify API and make it more clear.

And i'm still not sure why not to get rid of StereoEye all together by just multiplying distance according to the eye? You can call it interocular_offset. You can calculate this offset in Camera's update_device() and tag camera for the device once the view changed.

Alright, a new update coming. I didn't have time to test it (and won't until Tuesday), so there is a chance left and right eyes are flipped. Apart from that it is now close to what you suggested (I still have stereo_eye around, but it's outside the kernel).

And I'm no longer passing the interocular_distance directly to the kernel, but I'm instead pre-processing it to account for the stereo eye.

Hi,
are there any new builds available? The last build I found is 2.74-d33764b from this article: https://code.blender.org/2015/03/1451/ (which is no longer available). The problem with this build is that it outputs very noisy renders compared to standard panorama made in recent 2.76b (official).

Here is an image for comparison: The left is made with the recent 2.76b and on the right is the 2.74-d33764b with stereo panorama enabled.

@Marek Moravec (marek) you can find more recent builds at: http://www.dalaifelinto.com/?p=1009 (see the link on the post). See if the same issue is there with those builds.

@Dalai Felinto (dfelinto) Thank you very much! The recent build renders just fine. I found a bug with border rendering but I guess it is better to fill a separate bug report. Anyway, thank you for your work on this!

Looks rather good to me now. Some further cleanup is possible, but could happen after the commit as well.

Some notes tho:

• Seems Spherical Stereo is only used when camera is panoramic. In this case it makes sense to hide the option for perspective camera.
• Not sure we need bl_use_spherical_stereo, render engnes can simply hide options from the interface and pass false to the render engine when they need to calculate matrix.

Worth poking Rambo to review rna art of the changes.

Looks good, minor note about comments.

@Sergey Sharybin (sergey), spherical stereo is also used when rendering cubemaps, not just panoramas. so it does make sense to have it :)