[Bf-viewport] GLSL Node

[Daniel Stokes]

Greetings Bf-viewport,

I would like to start some discussion on the customizable shading of the
viewport. This is an area that I have a strong personal interest in, and I
may be able to contribute development time toward it. From the first email
on this mailing list, I am referring to this item:

3) GLSL node/GLSL renderer node tree.

This sounds scary, but for now we can just add GLSL specific BSDF-like
shaders, reuse the existing node shaders and write a special GLSL node.
That node will act similarly to the OSL node, basically you will be able to
attach a tet file with GLSL code in it. The GLSL code will need a function
with a predefined name, which will be parsed for -in and -out variables and
sockets will be created in the node accordingly. Then users should be able
to write their own shaders to drive real time display. The system will be
able to request data from the meshes using the batch manager outlined in 1)
based on the inputs the user will plug into this shader. Those inputs will
be used to request mesh data during node tree compilation.

----------------------------------------------------------------------------------------------------------------------------------
Here are some of my initial thoughts on this:

1) The node system, as proposed, could be a great place for this since this
code is heavily shared with the Game Engine. This opens up the possibility
of making these custom shaders usable in the Game Engine with hopefully
little extra development cost. It is worthwhile to note that there are
several open material node bugs [1][2][3][4] that would be nice to look at
when considering better Game Engine integration.

2) How would we deal with adding nodes that aren't compatible with a
renderer? Furthermore, would the GLSL node be added to the nodes for
Blender Internal?

3) While the current node system works well for custom fragment shaders,
what about vertex, tessellation control, tessellation evaluation, geometry,
and compute shaders? Other than compute shaders, the remaining shader
stages could possibly be handled by new mesh node system. Again this brings
up the question of compatibility with a renderer.

4) While it may be beyond the initial scope of this project, I would like
to bring up the possibility of making more use of the material panel for
material nodes. It could be very useful to allow the author of a node
system to expose inputs to the node system that appear in the material
panel. This would make it easier for another user to use and adjust the
material without needing to know what the individual nodes do.

Finally, I would like to present a good case study for the usefulness of
this feature. At the 2015 Game Developer's Conference Junya Motomura, a
technical artist from ArcSystemWorks, talked about the shading used in
their game Guilty Gear Xrd [5]. In this talk, Motomura describes how the
shaders relied heavily on artist created content (a lot of which was stored
in vertex colors), and how it was essential for artists to see the effects
of their changes as they were making them.

I look forward to discussing these details and moving this project along.
For anyone who wishes to talk with me on IRC, I am usually lurking in
Blender channels, including #blendercoders, as Kupoman when I am not at
work. I am in the Pacific Time Zone.

Regards,
Daniel Stokes

[1] T17869 Geometry Node Material doesn't work properly with shared mesh in
BGE <https://developer.blender.org/T17869>
[2] T41829 Normal Map in Material Node going wrong
<https://developer.blender.org/T41829>
[3] T33730 Node Materials Won't Display Multiple UVs
<https://developer.blender.org/T33730>
[4] T34792 game engine node material bug with 2 vertex color channels
<https://developer.blender.org/T34792>
[5] http://www.gdcvault.com/play/1022031/GuiltyGearXrd-s-Art-Style-The
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-viewport/attachments/20150607/b43ce8e7/attachment.htm