On Tue, 2007-08-14 at 14:35 -0700, Wesley Smith wrote:
If you want a good place to look for ideas, download Jitter from cycling 74 and look at the shader folder. There are a ton of shaders in there that can be borrowed from. Some have copyright notices, so you just need to leave those in the files to distribute them.
That sounds interesting, but I can't seem to break into the installer package on linux.
I think that in an ideal world we'd build a structured library of shaders - potentially with standard functions for the illumination models etc, and naming conventions to make it easier for people to play with.
However, having a grab bag of shaders (under a free licence) with some documentation for people to try out and experiment with, under any platform/app, is a more realistic target at this point.
It would be nice if they came from this community too I think.
I've been working on an audiovisual composition system using Lua
I've fought with the idea of embedding glsl in scheme, but doing this makes it harder to share - although maybe it's not too bad if we can extract the code easily. I quite like treating shaders like any other assets though, and having them in search paths like textures.
cheers,
dave
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.
By wrapper code do you mean XML or do you mean scripting languages?
wes
On 8/16/07, chris clepper cgclepper@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.
I mean anything other than GLSL spec code. That includes XML.
On 8/16/07, Wesley Smith wesley.hoke@gmail.com wrote:
By wrapper code do you mean XML or do you mean scripting languages?
wes
On 8/16/07, chris clepper cgclepper@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.
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@gmail.com wrote:
I mean anything other than GLSL spec code. That includes XML.
On 8/16/07, Wesley Smith wesley.hoke@gmail.com wrote:
By wrapper code do you mean XML or do you mean scripting languages?
wes
On 8/16/07, chris clepper < cgclepper@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.
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@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@gmail.com wrote:
I mean anything other than GLSL spec code. That includes XML.
On 8/16/07, Wesley Smith wesley.hoke@gmail.com wrote:
By wrapper code do you mean XML or do you mean scripting languages?
wes
On 8/16/07, chris clepper < cgclepper@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.
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@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@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@gmail.com > wrote:
I mean anything other than GLSL spec code. That includes XML.
On 8/16/07, Wesley Smith wesley.hoke@gmail.com wrote:
By wrapper code do you mean XML or do you mean scripting languages?
wes
On 8/16/07, chris clepper < cgclepper@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.
I'm not sure if GEM has support for geometry shaders yet, but how do you imagine handling the program parameters like GL_GEOMETRY_VERTICES_OUT_EXT, GL_GEOMETRY_INPUT_TYPE_EXT, and GL_GEOMETRY_OUTPUT_TYPE_EXT without some kind of extra information since these things aren't inherent to the shader code yet most geometry shaders are written for particular input and output types?
wes
GEM doesn't support geometry shaders at this point. It could turn out that they won't work well with the Pd/GEM environment, but there are other aspects of GL that don't work either. GL was clearly not designed to do what GEM does, so there is a lot of work to be done for each new feature added to GL. There is a lot of compromise needed to fit the latest and greatest into a framework over a decade old.
On 8/16/07, Wesley Smith wesley.hoke@gmail.com wrote:
I'm not sure if GEM has support for geometry shaders yet, but how do you imagine handling the program parameters like GL_GEOMETRY_VERTICES_OUT_EXT, GL_GEOMETRY_INPUT_TYPE_EXT, and GL_GEOMETRY_OUTPUT_TYPE_EXT without some kind of extra information since these things aren't inherent to the shader code yet most geometry shaders are written for particular input and output types?
wes
On 8/16/07, chris clepper cgclepper@gmail.com wrote:
GEM doesn't support geometry shaders at this point. It could turn out that they won't work well with the Pd/GEM environment, but there are other aspects of GL that don't work either. GL was clearly not designed to do what GEM does, so there is a lot of work to be done for each new feature added to GL. There is a lot of compromise needed to fit the latest and greatest into a framework over a decade old.
True. Not sure if you have seen what's on the horizon for OpenGL 3, but the new object model will definitely make things easier to partition and manage in visual programming environments. I'm very much looking forward to it.
best, wes
I like the solution we have now as it requires nothing beyond GLSL code to run shaders. I prefer having these things in the patch since that is exactly how Pd is supposed to work. Is it so odd to make objects conform to specs rather than making up your own?
On 8/16/07, Wesley Smith wesley.hoke@gmail.com 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@gmail.com wrote:
I like the solution we have now as it requires nothing beyond GLSL code to run shaders. I prefer having these things in the patch since that is exactly how Pd is supposed to work. Is it so odd to make objects conform to specs rather than making up your own?
It's perfectly reasonable to have things this way but I think it's going too far to say that having something like an XML schema is a "design flaw". To each his own.
wes
On Thu, 16 Aug 2007, 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.
I think it fits more with pd to use the pd patch format itself to configure that kind of thing. It's more fitting than XML except if the aim is to support existing Jitter files.
In general, Pd has a strong sense of reusing the same format for different things: the contents of an objectbox, the contents of a messagebox, the whole file format, the netsend/netreceive format and messages from the GUI to the message-system, are five things which share essentially the same syntax.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
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@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@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@gmail.com > wrote:
I mean anything other than GLSL spec code. That includes XML.
On 8/16/07, Wesley Smith wesley.hoke@gmail.com wrote:
By wrapper code do you mean XML or do you mean scripting languages?
wes
On 8/16/07, chris clepper < cgclepper@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@iem.at http://lists.puredata.info/listinfo/gem-dev
------------------------------------------------------------------------ ----
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@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@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@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@gmail.com > wrote:
I mean anything other than GLSL spec code. That includes XML.
On 8/16/07, Wesley Smith wesley.hoke@gmail.com wrote:
By wrapper code do you mean XML or do you mean scripting languages?
wes
On 8/16/07, chris clepper < cgclepper@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@iem.at http://lists.puredata.info/listinfo/gem-dev
http://at.or.at/hans/
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
-
Alexandre Quessy -
chris clepper -
Dave Griffiths -
Hans-Christoph Steiner -
Mathieu Bouchard -
Wesley Smith