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