[GEM-dev] help with glsl abstractions

[Jack]

Le 02/09/2013 16:05, Patrice Colet a écrit :
>
> Colet Patrice
>
> ----- Mail original -----
>> De: "Jack" <jack at rybn.org>
>> À: "Cyrille Henry" <ch at chnry.net>
>> Cc: "gem-dev" <gem-dev at iem.at>
>> Envoyé: Lundi 2 Septembre 2013 14:26:46
>> Objet: Re: [GEM-dev] help with glsl abstractions
>>
>> Le 02/09/2013 12:58, Cyrille Henry a écrit :
>>>
>>> Le 01/09/2013 11:31, Jack a écrit :
>>>
>>>> number of texunit available is return by
>>>> GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS.
>>>> Here on Intel HD 4000, GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS is 32.
>>>> And on NVidia GTX660M is 160.
>>> do we have the possibility to ask for the next free texture Id?
>>> so we could have objects that automatically deal with texture Id.
>>>
>>> cheers
>>> c
>>>
>> Hello Cyrille,
>>
>> I don't know if it is possible to ask for the next free texture ID.
>>
>
> Hello, I think this could be done with usual pd objects, by prepending a sender name to texunit, this name would be set in abstraction's arguments, then a receiver name for shaders that needs to process texunit would retrieve the right number anytime
If we try to avoid argument in abstraction (to have similar pix_* object
and glsl_* (or an other name) abstractions), maybe an external could help...
++

Jack


>
>> But :
>> - what happen if you decide to erase a 'glsl_abstraction' ? Other
>> 'glsl_abstraction' should keep their own 'texture ID'. I think, it is
>> very important if you pass a uniform sampler variable to
>> [glsl_program]
>> somewhere else in your patch ?
>> - we need to keep informed about the 'texture ID' choosen if we want
>> to
>> use it somewhere else for a uniform sampler variable (should be easy
>> with GOP and number box) ?
>> - what happen, if you don't want to assign a specific value as
>> texture
>> ID because you already store a uniform sampler variable to
>> [glsl_program] somewhere else (this aspect is not very complex to
>> solve,
>> we just need to change the value of the variable send to
>> [glsl_program]) ?
>>
>> Maybe there are other questions ?
>> ++
>>
>> Jack
>>
>>
>>
>> _______________________________________________
>> GEM-dev mailing list
>> GEM-dev at iem.at
>> http://lists.puredata.info/listinfo/gem-dev
>>