Le 02/09/2013 16:05, Patrice Colet a écrit : > > Colet Patrice > > ----- Mail original ----- >> De: "Jack" <j...@rybn.org> >> À: "Cyrille Henry" <c...@chnry.net> >> Cc: "gem-dev" <gem-dev@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@iem.at >> http://lists.puredata.info/listinfo/gem-dev >> _______________________________________________ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev