[Bf-viewport] GLSL Node

[Antony Riakiotakis]

We already have a custom parser in gpu_codegen.c, see
gpu_parse_functions_string. This can be improved upon if needed.
I don't think loops or conditionals will complicate things but any "out"
variables of a shader function will need to be written to, to guarantee
there are no garbage values. But this will be up to the author of the
shader.

On 9 June 2015 at 07:58, Olivier Parisy <olivier.parisy at gmail.com> wrote:

> Well, didn't want to clutter the list, but since you're asking for a
> feedback... [image: ☺]
>
> 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
>>
>
> _______________________________________________
> 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/7826e3c9/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 1681 bytes
Desc: not available
Url : http://lists.blender.org/pipermail/bf-viewport/attachments/20150609/7826e3c9/attachment.png