[Bf-committers] Stereoscopy Implementation Proposal

Ton Roosendaal ton at blender.org
Thu Apr 4 20:39:52 CEST 2013

Hi Dalai,

Usability aside - that's stuff we can test and feedback later as well - I think the main decisions to make is on storage and display level now.

OpenEXR proposes to put the views inside the layer names, as channel prefix... I don't fully grasp the benefit yet, but it's probably to be able to localize any layer or pass, and have software figure out the views. Following their approach, it would be in Blender:


And not


This proposal is supported by Weta and ILM - might be worth considering carefully.

** RenderLayers

Following this approach, the Scene itself can next to (outside) renderlayer name/setting definitions, store a list with "View" names and settings. Which would be for stereo "left" and "right" but it can be "middle" and whatever views people like to have (I know 3d displays out there that need 9 views). For each view cameras could be assigned, or a single camera with stereo/multiview properties.

For each view, the Render engine then runs a complete loop to go over the the (already prepared) scene, set camera transforms and do the render. 

This then results in a complete filled RenderResult, which can save out to MultiLayer exr, to temp buffers and FSA alike.

If no views are set, the naming can be as usual. That also keeps render result work as usual, and stay compatible for non-stereo cases.

That means neather (1) or (2) or (3) as you proposed below btw!

** Compositor

The compositor internally can stay nearly fully same. It gets a new (optional) property for "current view", which then gets used to extract the correct buffers from Render Result, from Image nodes, and sets the right buffers to RenderResult back, or saves to files.

This makes the need for "join" or "split" nodes not needed either. For cases where people want to input own footage, we can find ways to have the "current composite view" map to the right name for input. It also keeps compositor flexible for other multi-view cases.

** Regular images

We can also internally handle special case regular images - like side-by-side, or top-bottom, or whatever people can come up with. 

This then could become a property for the Image block, like right now for Generated, Sequence, etc. The API can follow "acquire_ibuf" using "current view" as well. Internally it can store, cache, or not, whatever is needed.

** Drawing images

Support for OpenGL (3D drawn) based stereo (using shutterglasses or red/green) we can quite easily add in the 3d window. This can be per-3d window locally even. 

Support for Image-based stereo we should only allow per-window in Blender. This window then should *entirely* do the display as set by the user (side by side, alternating, etc). This including a possible UI that's being drawn (with depth offset, if set).
This keeps a UI work in stereo mode, prevents ugly flicker for side-by-side monitors for example.

Next to that, the Image window then can get a shortcut/menu to go to "entirely blank" - not drawing UI at all, best for use in fullscreen/borderless of course. 

Drawing can simply use the "view" property again to extract the right buffers from RenderResult or Image blocks. No new "StereoVisual" concept needed.

Hope it's clear :) But I think the above would work nice and aligns fully your proposed and expected functionality.


Ton Roosendaal  Blender Foundation   ton at blender.org    www.blender.org
Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands

On 2 Apr, 2013, at 7:33, Dalai Felinto wrote:

> Thanks everyone for the feedback.
> @ Brecht:
>> OpenEXR in fact has native support for such stereo/multiview images, so
> it would make sense to be compatible with that and support saving and
> loading such EXR files.
> I think this also can be a good start for the project. The reading part can
> even make to trunk before the stereo code itself kicks in.
> Can we update trunk OpenEXR for the 1.7.1 version? All the API calls to use
> multi-view are there. (of course I can work locally with updated libs, but
> it's annoying if more people want to test/code)
>> I think we should add "views" in the same way that we have "layers" and "passes"
> now.
> The way OpenEXR organize the data seems a bit too loose (view can either be
> nested to a pass or be a top element, able to nest a layer or a pass
> directly).
> For Blender it would be easier if we stick to one of them:
> (the (1) seems to be the more logical in my opinion, but that also means
> the code will be more intrusive)
> (1)
> typedef struct RenderResult {
> - ListBase layers;
> +ListBase views;
> [ and make layers nested to RenderView ]
> (2)
> typedef struct RenderPass {
> + ListBase views;
> }
> [ and store the buffer itself (float *rect) in RenderView ]
> (3)
> Not sure how it would reflect in code, but we could have the views handled
> as passes (right.mist, left.depth, ...)
> --
> Dalai
> blendernetwork.org/member/dalai-felinto
> www.dalaifelinto.com
> 2013/4/1 Adriano <adriano.ufrb at gmail.com>
>> Loved to know about this proposal, Dalai.
>> I have been studing stereoscopy lately.
>> I use this addon a lot:
>> http://www.noeol.de/s3d/
>> I sugest the funcionalities in this Plugin for 3dsmax:
>> http://davidshelton.de/blog/?p=354
>> hope to contribute more soon.
>> Adriano
>> --
>> View this message in context:
>> http://blender.45788.n6.nabble.com/Stereoscopy-Implementation-Proposal-tp106106p106332.html
>> Sent from the Bf-committers mailing list archive at Nabble.com.
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

More information about the Bf-committers mailing list