[Bf-viewport] GLSL Node

[Mike Erwin]

Re: multiple shader stages

Some of the wireframe shaders I prototyped are multi-stage, with work split
between vertex and fragment. So yes we'll need to do *at least* those.
Geometry stage in the near future or maybe for the initial release. How do
we visually designate stages in the UI, since as Daniel points out most so
far could be lumped into the fragment category?

Here's what I see in my head:
Inputs to the vertex shader node come from geometry data source (as
attributes) or from other nodes (as uniforms). Inputs to the fragment
shader node come from vertex shader outputs directly or from other nodes
(again as uniforms). Use consistent input/output names and wires
automatically connect. So in the basic case we have 3 things wired
together: data source --> vertex --> fragment. Can't wait to see this on
screen!

Does anyone else here envision mixing of the new GLSL shader nodes and
existing nodes?

Watching the Guilty Gear Xrd presentation now...

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire

On Mon, Jun 8, 2015 at 5:00 PM, Antony Riakiotakis <kalast at gmail.com> wrote:

> Hi Daniel,
>
> The idea is to make a new system that will be powerful enough allow
> the game engine to use it, but I expect the game engine to adapt to it
> rather than the opposite. The initial plan was to not have blender
> internal compatibility at all.
>
> The node system already has compatibility flags so nodes can set the
> engine(s) they are compatible with. I expect many existing nodes will
> need little modification to run on new OpenGL. Most of the code that
> needs to be changed is the uniform and attribute declarations and this
> is handled internally in the gpu_codegen module.
>
> For the script nodes, initial plan was to make a fragment shader node
> at first, but of course we should make it possible to hook more shader
> stages, perhaps by using many text data blocks on the node itself. If
> there are constraints that would be nice to have now would be the time
> to express them I guess. The problem of compatibility is again
> bypassed by ignoring it. Any shiny new shader nodes go only to new
> viewport. Obviously shader stages can only be executed in a system
> that supports them. Might be worth defining alternative node trees for
> system without some shader stages but this becomes too technical very
> quickly and can get out of hand.
> Let's focus on high level functionality first.
>
> For the material panel it's more of a UI issue. I agree it would be
> nice to expose an interface in a more meaningful way. I think node
> groups can give us some tools to optimize this workflow somewhat if we
> can expose their input interface in the material panel.
> _______________________________________________
> Bf-viewport mailing list
> Bf-viewport at blender.org
> http://lists.blender.org/mailman/listinfo/bf-viewport
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-viewport/attachments/20150608/cbc7617f/attachment.htm