[Bf-viewport] GLSL Node

[Olivier Parisy]

Well, didn't want to clutter the list, but since you're asking for a
feedback... ☺

My understanding is that this would be a productive, modern way to design
GLSL shaders, due to an expressive combination of "classical" nodes and
code fragments and real-time feedback. Very empowering, and I suppose this
could even be used for postprocessings or, as a strech, "demo-like"
oddities à la shadertoy.

In this regard, being able to export generated GLSL code, even unoptimized
(as is currently possible) would be a must.

One question: do you feel control structures such as branching or loops
would complicate matters? I suppose they would be a good use case for GLSL
script nodes. Those nodes may also be a way to code shaders in a more
modular way, without resorting to tricks such as a preprocessor.

As already stated, automatic creation of typed inputs/outputs for those
nodes will require some GLSL parsing capabilities. Does the blender code
base already contain such a parser? If not, what is the preferred parsing
strategy in blender? Grammars compilers / code generators? Ad-hoc,
handcrafted ones?

Regards,
Olivier.

Le lun. 8 juin 2015 23:59, Mike Erwin <significant.bit at gmail.com> a écrit :

> 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
>>
>
> _______________________________________________
> 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/20150609/b617b9bf/attachment-0001.htm