<p dir="ltr">I was not advocating for nodes to express loops and branching; I feel instead that they would be better expressed with GLSL scripts nodes. </p>
<p dir="ltr">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.<br>
</p>
<br><div class="gmail_quote">Le mer. 10 juin 2015 08:30, Daniel Stokes <<a href="mailto:kupomail@gmail.com">kupomail@gmail.com</a>> a écrit :<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Lots of discussion here, sorry I am a little slow to respond here. Hopefully I hit most of the things covered so far:<br></div><div><br>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).<br><br></div><div>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.<br><br></div><div>I agree that GLSL export would be a nice to have.<br><br></div><div>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.<br></div><div><br></div><div>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.<br><br>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?<br><br></div><div>Regards,<br></div><div>Daniel<br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 9, 2015 at 4:10 AM, Khalifa Lame <span dir="ltr"><<a href="mailto:khalibloo@gmail.com" target="_blank">khalibloo@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>also, i think there should be a way to load in shader code from text files via the materials panel (without using nodes).</div><div><br></div><div>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.</div></div><div class="gmail_extra"><div><div><br><div class="gmail_quote">On Tue, Jun 9, 2015 at 11:07 AM, Antony Riakiotakis <span dir="ltr"><<a href="mailto:kalast@gmail.com" target="_blank">kalast@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>We already have a custom parser in gpu_codegen.c, see gpu_parse_functions_string. This can be improved upon if needed.<br></div>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.<br></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On 9 June 2015 at 07:58, Olivier Parisy <span dir="ltr"><<a href="mailto:olivier.parisy@gmail.com" target="_blank">olivier.parisy@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Well, didn't want to clutter the list, but since you're asking for a feedback... <img goomoji="263a" style="margin:0 0.2ex;vertical-align:middle;max-height:24px" alt="☺" src="cid:263a@goomoji.gmail"></p>
<p dir="ltr">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.</p>
<p dir="ltr">In this regard, being able to export generated GLSL code, even unoptimized (as is currently possible) would be a must. </p>
<p dir="ltr">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.</p>
<p dir="ltr">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?</p>
<p dir="ltr">Regards,<br>
Olivier. </p><div><div>
<br><div class="gmail_quote">Le lun. 8 juin 2015 23:59, Mike Erwin <<a href="mailto:significant.bit@gmail.com" target="_blank">significant.bit@gmail.com</a>> a écrit :<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Re: multiple shader stages</div><div><br></div><div>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?</div><div><br></div>Here's what I see in my head:<div>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!</div><div><br></div><div>Does anyone else here envision mixing of the new GLSL shader nodes and existing nodes?</div><div><br></div><div>Watching the Guilty Gear Xrd presentation now...</div></div><div class="gmail_extra"></div><div class="gmail_extra"><br clear="all"><div><div>Mike Erwin<br>musician, naturalist, pixel pusher, hacker extraordinaire</div></div></div><div class="gmail_extra">
<br><div class="gmail_quote">On Mon, Jun 8, 2015 at 5:00 PM, Antony Riakiotakis <span dir="ltr"><<a href="mailto:kalast@gmail.com" target="_blank">kalast@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Daniel,<br>
<br>
The idea is to make a new system that will be powerful enough allow<br>
the game engine to use it, but I expect the game engine to adapt to it<br>
rather than the opposite. The initial plan was to not have blender<br>
internal compatibility at all.<br>
<br>
The node system already has compatibility flags so nodes can set the<br>
engine(s) they are compatible with. I expect many existing nodes will<br>
need little modification to run on new OpenGL. Most of the code that<br>
needs to be changed is the uniform and attribute declarations and this<br>
is handled internally in the gpu_codegen module.<br>
<br>
For the script nodes, initial plan was to make a fragment shader node<br>
at first, but of course we should make it possible to hook more shader<br>
stages, perhaps by using many text data blocks on the node itself. If<br>
there are constraints that would be nice to have now would be the time<br>
to express them I guess. The problem of compatibility is again<br>
bypassed by ignoring it. Any shiny new shader nodes go only to new<br>
viewport. Obviously shader stages can only be executed in a system<br>
that supports them. Might be worth defining alternative node trees for<br>
system without some shader stages but this becomes too technical very<br>
quickly and can get out of hand.<br>
Let's focus on high level functionality first.<br>
<br>
For the material panel it's more of a UI issue. I agree it would be<br>
nice to expose an interface in a more meaningful way. I think node<br>
groups can give us some tools to optimize this workflow somewhat if we<br>
can expose their input interface in the material panel.<br>
<div><div>_______________________________________________<br>
Bf-viewport mailing list<br>
<a href="mailto:Bf-viewport@blender.org" target="_blank">Bf-viewport@blender.org</a><br>
<a href="http://lists.blender.org/mailman/listinfo/bf-viewport" target="_blank">http://lists.blender.org/mailman/listinfo/bf-viewport</a><br>
</div></div></blockquote></div><br></div>
_______________________________________________<br>
Bf-viewport mailing list<br>
<a href="mailto:Bf-viewport@blender.org" target="_blank">Bf-viewport@blender.org</a><br>
<a href="http://lists.blender.org/mailman/listinfo/bf-viewport" target="_blank">http://lists.blender.org/mailman/listinfo/bf-viewport</a><br>
</blockquote></div>
</div></div><br>_______________________________________________<br>
Bf-viewport mailing list<br>
<a href="mailto:Bf-viewport@blender.org" target="_blank">Bf-viewport@blender.org</a><br>
<a href="http://lists.blender.org/mailman/listinfo/bf-viewport" target="_blank">http://lists.blender.org/mailman/listinfo/bf-viewport</a><br>
<br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
Bf-viewport mailing list<br>
<a href="mailto:Bf-viewport@blender.org" target="_blank">Bf-viewport@blender.org</a><br>
<a href="http://lists.blender.org/mailman/listinfo/bf-viewport" target="_blank">http://lists.blender.org/mailman/listinfo/bf-viewport</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div></div></div><span><font color="#888888">-- <br><div>khalibloo®<br><br></div>
</font></span></div>
<br>_______________________________________________<br>
Bf-viewport mailing list<br>
<a href="mailto:Bf-viewport@blender.org" target="_blank">Bf-viewport@blender.org</a><br>
<a href="http://lists.blender.org/mailman/listinfo/bf-viewport" target="_blank">http://lists.blender.org/mailman/listinfo/bf-viewport</a><br>
<br></blockquote></div><br></div>
_______________________________________________<br>
Bf-viewport mailing list<br>
<a href="mailto:Bf-viewport@blender.org" target="_blank">Bf-viewport@blender.org</a><br>
<a href="http://lists.blender.org/mailman/listinfo/bf-viewport" rel="noreferrer" target="_blank">http://lists.blender.org/mailman/listinfo/bf-viewport</a><br>
</blockquote></div>