[osg-users] BAD design of TextureAttribute

Julien Valentin julienvalentin51 at gmail.com
Fri Mar 30 16:39:17 PDT 2018

Sorry all it's late and i began to fail

I rethink again and in fact I'm right, no meaculpa dude :)
Setting member of textureattribute to zero don't bother tu sharing as type do the trick in that particular case.


mp3butcher wrote:
> Sorry I forgot texgen et al...so mea culpa i can't say there no use case of tu sharing 
> so I can't say  getmember should be 0....mmh there's a strange design issue there:
> getMemberType must be a unique key in ss per tu attrmap but getmember is stateset dependent....
> Will think about it...
> mp3butcher wrote:
> > Hi,
> > Searching for the bug once again i found that there were changes in Texture base class....I will dig what was the purpose of this new design but i suspect its use is to conform with the pragma pipeline.
> > At first glance, making tu member of TextureAttribute is really a bad design but perhaps there a reason...
> > What's sure is that is no reliable to be use outside of the pipeline conformance path: so 
> > getMember {return _activetu} should really be removed!!
> > 
> > Further, I can't see a usecase whare TextureAttributes in the same ss share a common texture unit :~  so member of textures should stay 0
> > 
> > 
> > Thank you!
> > 
> > Cheers,
> > Julien

Read this topic online here:

More information about the osg-users mailing list