[GEM-dev] help with glsl abstractions

Patrice Colet colet.patrice at free.fr
Mon Sep 2 16:05:46 CEST 2013



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

> 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
> 



More information about the GEM-dev mailing list