[Bf-committers] Stereoscopy Implementation Proposal
ton at blender.org
Sat Apr 6 18:22:18 CEST 2013
I just prefer to see this added in a way it's not changing the regular render flow. MultiView render is a new feature, and only used (very) occasionally. If you add this in a way that keeps existing code and data structures work, it can be done with minimal risk. Bugs then stay in the stereo-render feature, not for all the rest of Blender.
Many ways to do it though.
It can also be via the 'get result' api, which then can give a complete render result from views (or just the old one).
That would be then more like:
render -> views -> renderresult -> layers -> passes.
Ton Roosendaal Blender Foundation ton at blender.org www.blender.org
Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands
On 6 Apr, 2013, at 13:55, Brecht Van Lommel wrote:
> On Sat, Apr 6, 2013 at 11:12 AM, Ton Roosendaal <ton at blender.org> wrote:
>> 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.
> Personally I think explicit views > layers > passes (or layers > views
>> passes) storage is better. My guess is that the way it's stored in
> EXR files is for compatibility / simplicity. EXR also has no concept
> of renderlayers and only stores them by name, yet we do have separate
> data structures for them in Blender. So why are views different?
> Maybe it requires a few extra code changes but I think the final code
> will be more clear.
>> 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.
> RenderResult is also not stored in files, so I don't think we need to
> worry about versioning. Maybe there's a few places in the UI like the
> image editor or some compositing node where you want to specify a
> view, but I think in that case you want to have the view as a separate
> setting from the pass anyway?
> So as far as I can tell, nothing would break if we remove this feature?
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers