[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