[Bf-committers] Multiview branch feedback

Brecht Van Lommel brechtvanlommel at pandora.be
Mon Jun 17 13:54:14 CEST 2013


Hi Adriano,

On Mon, Jun 17, 2013 at 6:33 AM, Adriano Oliveira
<adriano.ufrb at gmail.com> wrote:
> Schneider's approach relies in Composite for obtain stereo results. This is
> perfect for my outputs because it offers me control and uses what is right
> there in Blender already. My stereo outputs are: (1) Side by site or over
> under composites to preview in my 3d TV and web delivering; (2) separated
> L/R files for blu-ray and DCP authoring.

(2) works in the branch I think. (1) does not at the moment but would
fit as a file save option.

> Nevertheless, even with a good camera, sometimes we need to “lie” to get
> good results. For example, to certain shot to work in stereo I may need to
> control convergence of objects and background separately. Imagine a space
> scene: camera close to an alien pilot in the cockpit, a second spaceship 10
> meters way, and the star field in the background… No real camera rig would
> get this right in one shot. We better control convergence plane by plane in
> composite.
>
> Other example: take a real footage stereo shot, track it and try to place
> 3d elements over it. Having access to R/L views from Render Layers is
> essential for a good match.

Ok, as far as I can tell all that fits in the current design.

> When producing a stereo film, I miss these things:
>
> 1. A real stereo camera (or a good L/C/R camera rig) with numeric and
> visual convergence/safe areas controls. Schneider's add-on is a good
> starting point.
> 2. OpenGL stereo preview of viewport, based on camera rig convergence. (I
> think corrected color anaglyph or b/w anaglyph is the most useful here).
> 3. Easy way to render L/R views with Cycles speed optimizations: not
> calculating geometry twice, for instance.
> 4. Easy way to access L/R views from Render Layers in Node Editor for me to
> compose whatever I want. The Stereo Node that I proposed is not essential,
> but something user-friendly as a ubbershader.
> 5. EXR support for L/R views archiving, no doubt.

2,3,5 are implemented, 1,4 are planned I think. See here for the todo list:
https://github.com/dfelinto/blender/issues

> 1. Separate stereo preview in Blender's viewport (OpenGL / 3D View) from
> render output in Image Editor. We don’t need automated multiview in Image
> Editor, because the way it is done just masses with node editor/composite
> output.
> 2. Let me do my stereo composites in node editor. If you want to help
> newcomers, create a Stereo Node, as I have proposed.
> 3. I need to access views from a Render Layer the same way I have access to
> render passes.
> 4. Let us use the great work Dalai is doing with EXR 2 and go further by
> adding ways to merge and insert new layers in composite output. This way we
> could work views from Render Layers separately and recompose them to save
> in EXR. The same functionalities would allow me to add/merge other new
> layers (corrected mattes for instance) to composite output, so I can save
> as EXR as well. This would be helpful for communicating with other
> software, or among different teams.

As far as I can tell, this all boils down to a different workflow than
the branch has now. Instead of running the compositor once for each
view, you want the compositor to run once and manually make a setup
that applies nodes to both layers and merges them.

But can you explain to me specifically why that is better than the
workflow used in the branch? I understand it may be quite different
than your current workflow and that it may be hard to transfer your
existing nodes setups, but that doesn't make it invalid. I still don't
see why you think it doesn't work, you can still do different things
depending on the view with the Switch View node, you can compose a
non-3D background, etc.

Even then, you could create a separate scene to do compositing of both
views in a single node setup at the same time, once the Render Layer
node has a view option?

> 5. We don’t need a SELECT VIEW in Image Editor, just the list of the true
> layers in the image. No matter it may seams repetitive, it is just more
> correct and informative. In addition, if we implement a node do add/merge
> new layers in the composition, we will need to see them listed in Image
> Editor's SELECT PASS.

But why? How is this different from the RenderLayer/RenderPass
distinction we have already?

> Small points:
>
> 6. Let’s change any reference to "3-D" to "Stereo" or "Multiview".
> 7. I would prefer not create a new Render Views tab in Properties panel.
> It's functions may better be relocated to recently created Render Passes
> tab.

6 seems reasonable, 7 is planned.

Brecht.


More information about the Bf-committers mailing list