[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.
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
More information about the osg-users
mailing list