<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 28, 2015 at 8:34 PM, Brecht Van Lommel <span dir="ltr"><<a href="mailto:brechtvanlommel@pandora.be" target="_blank">brechtvanlommel@pandora.be</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Alexander,<br>
<br>
I'd like understand the big picture here, how we want the material<br>
system to evolve for 2.8 and where these changes fit. There's been<br>
talk about evolving Blender Internal into a high quality realtime<br>
rendering engine, and just adding more and more features to the<br>
existing system doesn't necessarily help us end up with the best<br>
design. The conclusion from such a discussion may be that it's fine to<br>
commit the patches more or less as is, but I would still like to<br>
understand everyone's ideas here.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.).<br></div><div><br></div><div>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 :-)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It is possible to design a new material system from scratch, but it<br>
seems to me there are not enough developers for this available, and<br>
the transition would be quite painful for users. So perhaps we should<br>
gradually improve the Blender and/or Cycles material systems for<br>
realtime rendering.<br></blockquote><div><br></div><div>A worthy target for 3.0 :-)</div><div><br></div><div>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.</div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So what do we do there, try to match the Blender renderer anyway,<br>
improve the Blender renderer and break compatibility, or use different<br>
settings or methods for realtime and offline? These questions come up<br>
when reviewing these kinds of patches, and so it would be good to have<br>
some sort of policy or plan here.<br></blockquote><div><br></div><div>I agree 1000% on the "we need a policy" part :-)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Personally I think the right solution is to build a new realtime<br>
lighting system using the Cycles shader nodes (which hopefully in the<br>
future will include a PBR / Disney principled BSDF node). This can<br>
then be gradually improved without breaking compatibility with the old<br>
Blender material system, which then can be dropped entirely when the<br>
replacement is good enough. But how high we can actually aim also<br>
depends on the resources we have.<br></blockquote><div><br></div><div>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?</div><div><br></div><div>Roberto</div><div><br></div></div></div></div>