[GEM-dev] shader library

[Alexandre Quessy]

Hi all,
(Nice to see Wesley here ! )
In Gem, it would be nice to have a way to be able to get all the
variables that we can change from a [glsl_vertex] in a list. This
would make it easy to use dynamic patching for creating arguments
wrappers (in list of floats, with different inlets, for instance.

a

2007/8/17, Hans-Christoph Steiner <hans at eds.org>:
>
> I think that it is a good idea to keep non-Pd wrapper methods out of
> those objects.  Using the core shader objects that chris describes
> allows you to do all the wrapping that you might want, but it would
> be done with Pd rather than XML or some scripting language.
>
> I am sure it would also be possible to write some supporting Pd
> objects which could handle various XML wrappers or scripting
> languages, then dump that into the Pd GLSL objects.
>
> .hc
>
> On Aug 16, 2007, at 10:19 PM, Wesley Smith wrote:
>
> > I don't think it makes it less flexible except in that vertex and
> > fragment shaders can't be arbitrarily matched (which they can't be
> > anyway unless the varyings are the same).  What it does provide is
> > automatic default values which is really nice.  With the scheme I
> > described earlier, sampler units can also be changed on the fly.  An
> > XML format does not prohibit such things.  In addition, one can add
> > text descriptions to the shader and parameters which depending on your
> > taste may or may not be useful.
> >
> > wes
> >
> > On 8/16/07, chris clepper <cgclepper at gmail.com> wrote:
> >> We have a system that loads GLSL and ARB_fragement/vertex shaders
> >> with no
> >> need to add or alter the shader code from spec.  Why would we add
> >> code to
> >> change that?
> >>
> >> In GEM you can set the samplers' texture units on the fly in the
> >> patch which
> >> follows the design of Pd.  Your suggestion makes that less flexible.
> >>
> >>
> >>
> >> On 8/16/07, Wesley Smith <wesley.hoke at gmail.com> wrote:
> >>> I'm curious why you say this.  From my point of view, wrapping the
> >>> shader in XML allows for something that reads it to easily link
> >>> together vertex, geometry, and fragment shader and set both program
> >>> parameters as well as uniform parameters with default values in
> >>> addition to autmatically defining what messages the shader can
> >>> receive.  It's very similar to the cgFX files in this sense but
> >>> without the GUI descriptions or other things you can do with those
> >>> files.  Among other things, it make multitexturing in shaders
> >>> painless
> >>> because you can assign in the file what units go to what samplers.
> >>> For a usability standpoint, I see great benefits to wrapping the raw
> >>> shader code in extra information, so I'd be curious what you see as
> >>> the design flaws with such a system.
> >>>
> >>> wes
> >>>
> >>> On 8/16/07, chris clepper <cgclepper at gmail.com > wrote:
> >>>> I mean anything other than GLSL spec code.  That includes XML.
> >>>>
> >>>>
> >>>>
> >>>> On 8/16/07, Wesley Smith <wesley.hoke at gmail.com> wrote:
> >>>>> By wrapper code do you mean XML or do you mean scripting
> >>>>> languages?
> >>>>>
> >>>>> wes
> >>>>>
> >>>>> On 8/16/07, chris clepper < cgclepper at gmail.com > wrote:
> >>>>>> Just a quick note on GLSL and GEM: only GLSL spec shaders can be
> >> used
> >>>> with
> >>>>>> GEM, no wrapper code or hacks will ever be supported.
> >>>>>> Frankly, the
> >> apps
> >>>>>> that use these things have design flaws.
> >>>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >
> > _______________________________________________
> > GEM-dev mailing list
> > GEM-dev at iem.at
> > http://lists.puredata.info/listinfo/gem-dev
>
>
>
> ------------------------------------------------------------------------
> ----
>
>                                                http://at.or.at/hans/
>
>
>
> _______________________________________________
> GEM-dev mailing list
> GEM-dev at iem.at
> http://lists.puredata.info/listinfo/gem-dev
>


-- 
Alexandre Quessy
http://alexandre.quessy.net
http://www.puredata.info/Members/aalex