[GEM-dev] help with glsl abstractions

[Cyrille Henry]

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 at iem.at
> http://lists.puredata.info/listinfo/gem-dev
>