[Bf-committers] Stereoscopy Implementation Proposal

Ton Roosendaal ton at blender.org
Sat Apr 6 11:12:44 CEST 2013 

Hi,

> ** pass->ui_name : name without the view part [diffuse.R and diffuse.R]
> ** pass->exr_name : name to use for writing back in the exr
> [diffuse.right.R and diffuse.R ]


I would be very careful storing UI assumptions in data.

The current system already has layer names and pass names. The 'view' names can be defined in the UI, and how it's all stored and retrieved internally software can handle transparently. That way you don't regret design decisions when things change internally after all.

Another good trick is to look at code design in a way "what would break if we remove the feature". If things can get added and removed without bad versioning, you're much safer for future.

Forcing the render result to always store views is in this category. "Views" are optional, and can best stay that way - if possible.

Anyway - the proof of the concept is in the coding - usually you find out new or better ways during checking the impact of changes in Blender :)

-Ton-

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

On 6 Apr, 2013, at 10:50, Dalai Felinto wrote:

> I had a talk with Ton on IRC to clear the "storage" part of his
> proposal and the transcript is here:
> http://dalaifelinto.com/ftp/tmp/ton_irc_chat.pdf
> 
> Basically he suggested to store the just like any other pass. So we
> still would have RenderResult->RenderLayers->RenderPass
> 
> @Ton: after some exploratory coding, I think we can stick to your idea
> (it simplifies implementation) but it would help a lot to store the
> name in the pass in 2 to 3 ways:
> 
> For example the *diffuse.right.R* and *diffuse.R* channels (in this
> case left is the default view):
> 
> ** pass->name : full name of the patch with the view [diffuse.right.R
> and diffuse.left.R]
> ** pass->ui_name : name without the view part [diffuse.R and diffuse.R]
> ** pass->exr_name : name to use for writing back in the exr
> [diffuse.right.R and diffuse.R ]
> 
> pass->exr_name may not be needed since it's only required at writing
> time when can be obtained with insertViewName(pass->name, multiView,
> view_id).
> 
> Additionally we can store the view_id for the passes (pass->view_id).
> 
> And we need to store the view list in the ExrHandle as a StringVector
> multiView. To sync with that RenderResult also needs to store a
> multiView list, though it would be a ListBase.
> 
> The other idea of renderresult->renderview->renderlayer->renderpass is
> more elegant than the juggling needed for handling views. However the
> pay off of your idea is still worth I think. Note however, that there
> is a chance IML/Weta pick this design simply because of their need of
> backward-compatibility.
> 
> Anyways, any new feedback is welcome. I will tackle this new approach tomorrow.
> --
> Dalai
> 
> blendernetwork.org/member/dalai-felinto
> www.dalaifelinto.com
> 
> 
> 2013/4/4 Ton Roosendaal <ton at blender.org>:
>> 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:
>> 
>> RenderLayer_001.diffuse.left.R
>> RenderLayer_001.diffuse.right.R
>> 
>> And not
>> 
>> left.RenderLayer_001.diffuse.R
>> right.RenderLayer_001.diffuse.R
>> 
>> 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-
>> 
>> ------------------------------------------------------------------------
>> 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
>> 
>> _______________________________________________
>> 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