[Bf-viewport] GLSL Node
Olivier Parisy
olivier.parisy at gmail.com
Wed Jun 10 23:14:08 CEST 2015
I love the idea of being able to design a set of materials as a set of
nodes with a real-time feedback, while enjoying the modelling and
mapping possibilities of Blender. Understanding how the directions the
viewport is taking can help in this regard is what got me to register to
this mailing-list.
Once that is done, from a workflow point of view, it feels natural to
imagine being able to export the resulting design as a set of GLSL
shaders, with a sufficiently defined interface that hooking them to code
can be done in a predictable way. Note that I'm not taking the stance of
saying that the viewport should provide all fancy à la mode effects.
Quite the opposite, I mean that if the viewport could display a material
in real time, why not help people in achieving the same result in their
code? It would be invaluable for game assets design, and much more
expressive than using "standard" parameters and shaders.
Regards,
Olivier.
Le 10/06/2015 14:34, Antony Riakiotakis a écrit :
> I don't think that for blender a live import of the exported code is
> such a good idea since material shaders get invalidated quite often
> mostly from user tweaks. Apart from that we would surely be interested
> in fixes to the gpu codegen module
>
> On 10 June 2015 at 14:24, Neal Alexander <nhalxr at gmail.com
> <mailto:nhalxr at gmail.com>> wrote:
>
> Regarding GLSL export - please do not repeat the same mistakes
> from the current export mechanism. Due to certain basic bugs I've
> fixed in it, I suspect that few people are actively using it. This
> is a shame, because blender's code provides a lot of potentially
> reusable functionality.
>
> I've noticed people mentioning the need for a better way to swap
> blender materials. So, for the last month, I've been working on
> the current GLSL shader export pipeline to deal with several of
> it's shortcomings. One of the major issues with the old exporter,
> aside from being unusable "out of the box", was that several of
> the uniform inputs (for example lamp-energy, lamp-spotsize,
> lamp-spotblend) are silently modified by the renderer before being
> bound, and the python GPU/export module, and it's documentation,
> are always out of sync with whats actually happening in
> gpu_material.c.
>
> For GLSL shader export to work effectively in the long term, you
> need to export your uniform pre-processing code - either as a
> standalone C library, or as a side script included with the
> shaders. The most maintainable and bug free scenario is having
> blender's real-time renderer load materials directly from the same
> format that it exports, with zero internal conversion. The current
> method of simply documenting the engines internal conversion
> routines and forcing the users to roll their own isn't working
> out. It suffers from the aforementioned documentation de-sync, and
> also subtle state-update related issues - spending hours debugging
> visual discrepancies only to find out a vector was being
> implicitly normalized, in some far away unrelated code block,
> really sucks.
>
>
> I've solved some of these problems, but haven't discussed the
> project with anyone else, so I'm not sure how likely the changes
> will be merged. Right now, I have some blender materials with
> spotlights, buffer shadows, and textures working in OpenSceneGraph
> (arbitrarily chosen).
>
> A full specification of the input uniforms and their conversion
> from blender native values was required, so I extended the current
> python GPU export script to generate an AST, exporting it directly
> to s-expr format.
>
> The homoiconicity of that format allows for a lot of flexibility:
>
> - If the user wants to treat the text as a plain data format, it's
> equivalent to a compact instance of other tree based formats such
> as XML or JSON, yet more straight-forward to parse.
> - Functions for uniform conversion are included directly in the
> file. This helps as far as maintainability and compatibility are
> concerned - everything is self contained.
> - Since the format is simultaneously valid Scheme code, the user
> can setup a restricted environment, define what a few functions
> mean to their current context (uniform-bind) and execute the script.
> - Since a drastically reduced subset of Scheme is used, a variety
> of embedded interpreters and implementations are available, most
> of which are less code than an XML parser, and some of which
> provide native code compilation. The project currently is using
> s7-scheme, which is just one C file, though we can use something
> even smaller.
> - Since s-exprs are isomorphic to abstract syntax trees, source to
> source translation is made easier for people wanting to convert to
> another language. Currently, the project's C headers and s7 C-FFI
> binding code are auto-generated via this method.
> - Having executable code in file formats can be frowned upon, but
> were already doing it by providing shader code. Anyway, the
> uniform script is only executable if the user chooses to interpret
> it as so, and then only in a restricted environment where nothing
> can be performed but mathematical operations. In a sense, it is
> not much different than GLSL code.
>
> The intended outcome is that given an exported blender GLSL
> material, a user needs only to load the GLSL shaders, define a
> handful of callbacks, eval() the uniform
> script, and execute the shader program to produce a test render
> with the default params, looking identical to the result seen in
> blender's view-port or material preview. Material params and
> camera info are manipulated by modifying the scheme environment.
>
> On Wed, Jun 10, 2015 at 10:11 AM, Olivier Parisy
> <olivier.parisy at gmail.com <mailto:olivier.parisy at gmail.com>> wrote:
>
> 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
> <mailto: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 <mailto: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 <mailto: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
> <mailto:olivier.parisy at gmail.com>> wrote:
>
> 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
> <mailto: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
> <mailto: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
> <mailto:Bf-viewport at blender.org>
> http://lists.blender.org/mailman/listinfo/bf-viewport
>
>
> _______________________________________________
> Bf-viewport mailing list
> Bf-viewport at blender.org
> <mailto:Bf-viewport at blender.org>
> http://lists.blender.org/mailman/listinfo/bf-viewport
>
>
> _______________________________________________
> Bf-viewport mailing list
> Bf-viewport at blender.org
> <mailto:Bf-viewport at blender.org>
> http://lists.blender.org/mailman/listinfo/bf-viewport
>
>
>
> _______________________________________________
> Bf-viewport mailing list
> Bf-viewport at blender.org
> <mailto:Bf-viewport at blender.org>
> http://lists.blender.org/mailman/listinfo/bf-viewport
>
>
>
>
> --
> khalibloo®
>
>
> _______________________________________________
> Bf-viewport mailing list
> Bf-viewport at blender.org <mailto:Bf-viewport at blender.org>
> http://lists.blender.org/mailman/listinfo/bf-viewport
>
>
> _______________________________________________
> Bf-viewport mailing list
> Bf-viewport at blender.org <mailto:Bf-viewport at blender.org>
> http://lists.blender.org/mailman/listinfo/bf-viewport
>
>
> _______________________________________________
> Bf-viewport mailing list
> Bf-viewport at blender.org <mailto:Bf-viewport at blender.org>
> http://lists.blender.org/mailman/listinfo/bf-viewport
>
>
>
> _______________________________________________
> Bf-viewport mailing list
> Bf-viewport at blender.org <mailto: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/8cc6e256/attachment-0001.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/20150610/8cc6e256/attachment-0001.png
More information about the Bf-viewport
mailing list