[Bf-viewport] Viewport and shader system patches

[Roberto Maurizzi]

On Mon, Dec 28, 2015 at 8:34 PM, Brecht Van Lommel <
brechtvanlommel at pandora.be> wrote:

> Hi Alexander,
>
> I'd like understand the big picture here, how we want the material
> system to evolve for 2.8 and where these changes fit. There's been
> talk about evolving Blender Internal into a high quality realtime
> rendering engine, and just adding more and more features to the
> existing system doesn't necessarily help us end up with the best
> design. The conclusion from such a discussion may be that it's fine to
> commit the patches more or less as is, but I would still like to
> understand everyone's ideas here.
>

For what it's worth (very little, since I'm still almost completely unable
to help) I quite agree with Brecht's position: I can't understand if there
is a plan about this.

Currently Blender is a strange beast with three different rendering engines
interfaced to the "bulk" of Bender using different interfaces, plus a
"pluggable" interface for external ones.

BI, Cycles and Viewport/OpenGL do similar things in different ways that
give the user a similar-but-not-quite-identical toolset to do most of the
same things in 3 different ways. As a result, most people use Cycles, some
use BI because it's better for special shading needs (toon-like shading, my
primary interest) or it's easier to port to the web (Blend4Web), many are
interested in having a better OpenGL engine for a number of reason
(internal game engine, realtime previsualization, developing/using GLSL
shaders, integrating their workflow with external game engines, trying PBR
approaches, etc.).

If I knew Blender like old-time devs, I'd probably try to see how to
reorganize all these renderers so that they use a common interface.
However, since I know the skill level of Blender's devs, I'm quite sure it
would be an almost impossible task and that's why it hasn't been done :-)

It is possible to design a new material system from scratch, but it
> seems to me there are not enough developers for this available, and
> the transition would be quite painful for users. So perhaps we should
> gradually improve the Blender and/or Cycles material systems for
> realtime rendering.
>

A worthy target for 3.0 :-)

The (non very well informed) impression I got from studying Blender's code
structure is that the best option probably is to "fix the fixable" for BI
but that it's so tightly coupled with everything else that to have it use
new standardized materials would mean rewriting it almost from scratch.
The best approach would be to leave it alone and design the "new"
OpenGL/GLSL renderer in a way that'll allow it and Cycles to share the
material system and, in general, a common interface with the rest of
Blender (so for example you can use the Compositor or the Video Sequence
Editor with both. In addition, adding other renderers would become an
almost decent undertaking). This new interface should allow for renderers
to have "realtime" and "high quality" modes, as Brecht is proposing.

So what do we do there, try to match the Blender renderer anyway,
> improve the Blender renderer and break compatibility, or use different
> settings or methods for realtime and offline? These questions come up
> when reviewing these kinds of patches, and so it would be good to have
> some sort of policy or plan here.
>

I agree 1000% on the "we need a policy" part  :-)

Personally I think the right solution is to build a new realtime
> lighting system using the Cycles shader nodes (which hopefully in the
> future will include a PBR / Disney principled BSDF node). This can
> then be gradually improved without breaking compatibility with the old
> Blender material system, which then can be dropped entirely when the
> replacement is good enough. But how high we can actually aim also
> depends on the resources we have.
>

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?

Roberto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-viewport/attachments/20151230/abc84252/attachment.htm