[Bf-viewport] Viewport and shader system patches

[Brecht Van Lommel]

On Wed, Dec 30, 2015 at 1:38 PM, Roberto Maurizzi
<roberto.maurizzi at gmail.com> wrote:
> Would this be an additional separate renderer that uses Cycles' interfaces,
> or a "specialized mode" of an improved Cycles renderer? Would it be generic
> enough to also do NPR without requiring the users to write C++ code?

Cycles was designed using the PBRT / OSL model, with clearly defined
roles for lights, shaders, cameras, etc. You can get get physically
correct results but also clear handling of transparency, render
passes, etc.

With NPR you want to break a lot of those principles, and then the
pieces no longer fit together for global illumination, progressive
rendering, adaptive sampling, BDPT, etc. In my opinion Cycles should
not break its core principles, because it's going to complicate the
design too much and make future improvements too hard.

So I think there should be a separate NPR renderer. But maybe that is
just the realtime viewport renderer which uses the Cycles model as its
base and extends it, with e.g. more material nodes, freestyle line
drawing, compositing effects.

It's just not at all clear to me what the requirements are for an NPR
renderer. Obviously we can make a long list of features that would be
great to have, but it's the overall design I'm concerned about. For
example would you say, we don't want the restrictions imposed by using
closures and just want to arbitrarily manipulate colors, and we're
prepared to give up full global illumination for that? Or do you
somehow keep both anyway, and if so how?

Who knows, maybe it makes sense to have a core physically based
renderer, output a lot of render passes, and do NPR effects with deep
compositing? That way you can do all kinds of effects using
neighbourhood and global information that is not available for
shaders.

It's tricky, the PBR model can simplify workflows a lot, but we can't
just drop the old system if it's the only way to do NPR.