<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 29, 2015 at 7:39 PM, Alexander Romanov <span dir="ltr"><<a href="mailto:a.romanov@blend4web.com" target="_blank">a.romanov@blend4web.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span class=""><br></span>
I agree that BI material system is outdated, but at the moment we
(Blend4Web Team) are quite satisfied with BI state except some not
so deep imperfections. So we are going to correct that
imperfections. For example here is some refactoring proposal <a href="http://wiki.blender.org/index.php/Blender_Internal_Nodes_Refactoring" target="_blank"></a><a href="http://wiki.blender.org/index.php/Blender_Internal_Nodes_Refactoring" target="_blank">http://wiki.blender.org/index.php/Blender_Internal_Nodes_Refactoring</a></div></blockquote><div><br></div><div>I'd really like to be able to experiment with your new BI nodes to see how much they allow to do for NPR.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">I agree that it's hardly worth to port all nodes of cycles, but some
of them can be very useful because
there are no alternative.<br>
For example Vector Transform node is a general node for vector
conversion. I think it should appear in BI anyway. And another
useful node is Normal Map.</div></blockquote><div><br></div><div>Porting or writing additional nodes would be a good stopgap measure to give new features while a new system is implemented (yeah, I know, I'm stating the obvious :D )</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">BI and Viewport already have a lot of self-sufficient functionality.
Could refactoring of the current shader system be an alternative to
writing the whole system from scratch? I mean, we could
incrementally prepare the current architecture for further PBR
implementation. At the beginning, It could be just a PBR mode for
node and simple materials which will replace non-physical
inputs(diffuse , specular etc) with physical ones(metalness,
roughness etc).<br></div></blockquote><div><br></div><div>I fear the current system isn't flexible enough to allow decent use of typical patterns used in video games engines and NPR. We usually use as a comparison what was done in the game "Guilty Gear Xrd", because it's very good, it runs realtime on a PS3 and there are very good information available, but with the current node structure some things are not possible, others require a bunch of nodes to do a few simple math operations, ending up with horribly huge node trees instead of 50 lines of GLSL...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
But in any case removing deprecated OpenGL API is a good beginning.<span class=""><br></span></div></blockquote><div><br></div><div> Very true :-)</div><div><br></div><div><br></div><div>Roberto</div></div></div></div>