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 <[email protected]>: > 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 [email protected] 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 <[email protected]> >> >>> 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 >>> [email protected] >>> http://lists.blender.org/mailman/listinfo/bf-committers >>> >> _______________________________________________ >> Bf-committers mailing list >> [email protected] >> http://lists.blender.org/mailman/listinfo/bf-committers > > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
