[GEM-dev] help with glsl abstractions

[Jack]

Le 02/09/2013 22:33, Cyrille Henry a écrit :
>
>
> Le 02/09/2013 14:26, Jack a écrit :
>> 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.
>>
>> 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 ?
>
> i don't see any problem.
> if we could automatically find a free texture Id, then we can make
> abstraction that automatically deal with all of this.
> it's not very hard to imagine somthing flexible enouth to get the Id,
> or to force a specific Id, or whatever else you may wish.
> the only problem imo is getting a free Id.
I don't see any problem too :) It was just a warning on the behavior
when you remove an abstraction, close the patch and re-open it, you need
to keep the texture ID as before. If it is OK with that behavior and to
get a free texture ID, then it should work.
The second and third point are easy to add/correct in the patch 'domain'.
++

Jack


>
> c
>
>
>> ++
>>
>> Jack
>>
>>
>>