[Bf-viewport] GLSL Node

Wed Jun 10 10:11:18 CEST 2015

I was not advocating for nodes to express loops and branching; I feel
instead that they would be better expressed with GLSL scripts nodes.

I am just wondering what inputs/outputs of scripts containing such loops
would look like. It's probably best to restrict script node to have a
standard "main" function and uniforms/variables indeed. That's an easy to
understand and well defined way to modularize code.

Le mer. 10 juin 2015 08:30, Daniel Stokes <kupomail at gmail.com> a écrit :

> Lots of discussion here, sorry I am a little slow to respond here.
> Hopefully I hit most of the things covered so far:
>
> Jacob, I am not sure what you are referring to with a core profile with
> regards to shaders. There is an OpenGL core profile, but there is no point
> in us restricting ourselves by following (better to use the compatibility
> profile).
>
> I certainly see GLSL node(s) being mixed with existing nodes. They would
> be a great way to create utility nodes or otherwise allow users to patch
> gaps in node system.
>
> I agree that GLSL export would be a nice to have.
>
> I am not sure about adding too many new nodes for things like branching
> and looping. Mostly I am concerned about adding nodes that a renderer
> doesn't actually use. I still don't see how that is intended to be handled.
>
> I don't see much need for a wrapper language, we might as well use
> straight GLSL. The inputs and outputs should be easy to parse, and is
> something we already have if we are only looking at the in and out
> variables of functions (as opposed to uniforms and in/out variables). We
> may add some custom language things via pragmas, but that is likely as far
> as we would go with any kind of custom language.
>
> I am still a little confused about when the GLSL node will be available.
> Mostly, what render engine needs to be selected in order to use it, or will
> that selection even matter?
>
> Regards,
> Daniel
>
>
> On Tue, Jun 9, 2015 at 4:10 AM, Khalifa Lame <khalibloo at gmail.com> wrote:
>
>> Here's an idea then. Use a "wrapper language" like unity's shaderlab.
>> this wrapper language can simply be a python class written by the user,
>> that defines the input variables for the GLSL shader and their ui
>> layout/representation.
>>
>> also, i think there should be a way to load in shader code from text
>> files via the materials panel (without using nodes).
>>
>> as for the shader stages, what if we had "node subtrees"? the user
>> selects the glsl node tree and then he has the option to select a vertex
>> shader subtree or a fragment/tessellation subtree. the outputs from a
>> vertex shader subtree for example, can be fed into the next subtree by
>> simply declaring inputs with similar IDs.
>>
>> On Tue, Jun 9, 2015 at 11:07 AM, Antony Riakiotakis <kalast at gmail.com>
>> wrote:
>>
>>> 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
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Bf-viewport mailing list
>>> Bf-viewport at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-viewport
>>>
>>>
>>
>>
>> --
>> khalibloo®
>>
>>
>> _______________________________________________
>> 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/20150610/f306ebd0/attachment-0001.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: emoji_u263a.png
Type: image/png
Size: 1681 bytes
Desc: not available
Url : http://lists.blender.org/pipermail/bf-viewport/attachments/20150610/f306ebd0/attachment-0001.png 