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.
Goodnight 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: http://forum.openscenegraph.org/viewtopic.php?p=73210#73210 _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org