Le 02/09/2013 14:09, Jack a écrit :
Le 02/09/2013 12:32, Nicolas Montgermont a écrit :
>
Le 26/07/2013 14:03, IOhannes m zmölnig a écrit :
On 07/26/13 11:44, Jack wrote:
Hello,
I would like to create GLSL abstractions in the help directory,
which
would replace pix_ objects when possible. The name would start with
glsl_ instead of pix_.
sound good.
I was wondering, isn't a name connected to pix could be better suited?
for example
pix_alpha -> pix_alpha_sl
instead of
pix_alpha -> glsl_alpha
Cause it's here to replace pixes, no? And we can imagine having glsl
abstraction not working specially in the field of texture...
This way the help directory will be alphabetically directly ordered...
and one can imagine new pixes effect without any need for a
corresponding pix_* object
best,
n
This aspect is important.
Problem : often pix_* objects are for pixes using CPU. With shaders in
GLSL we deal with textures on GPU (to replace pixes).
So here, a list of possibilities to replace, for example, [pix_2grey] :
[glsl_2grey] (easy to find equivalent of [pix_2grey])
[tex_2grey] (also easy to find equivalent of [pix_2grey])
[glsl_tex_2grey] (quite easy to find equivalent of [pix_2grey])
Now if we need to work on vertex/fragment in the future, it would be
possible to use a specific name with glsl_ and not with tex_ (which is
for texture), for example if we need to change z position of vertices
according to the color of a texture :
[glsl_vertex_displacement]
So, I think we should always start names with [glsl_].
Then, distinguish the work on texture, vertex, fragment and geometry.
Then maybe something starting with :
glsl_tex_*
glsl_vertex_*
glsl_fragment_*
glsl_geometry_*
this name releft the technical stuf insite the abstraction.
i wouls prefere name that mean something for someone who did not know what glsl
is.
c
++
Jack
_______________________________________________
GEM-dev mailing list
GEM-dev@iem.at
http://lists.puredata.info/listinfo/gem-dev
_______________________________________________
GEM-dev mailing list
GEM-dev@iem.at
http://lists.puredata.info/listinfo/gem-dev
