[GEM-dev] shader library

[Hans-Christoph Steiner]

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/