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