Ho I haven't realized the root of existence of this function was the previous 
contribution to the implementation of glTexStorage.
So Now I can see where the contributor (sure it's Pawel Ksiezopolski) wanted to 

I don't know why there's so many comments and misses in sizedInternalFormats 
but it's same to add them at the end 

So my proposal is a 2 way process:
-add missing  sizedInternalFormats (ex:I found internalformat GL_RGBA16 never 
-Fix the image less glTexStorage use case with

  if( useTexStorrage)
            //ensure _internalFormat is sized
            GLenum sized_internalFormat = _internalFormat;
            if(!isSizedInternalFormat( sized_internalFormat))
                    sized_internalFormat =  assumeSizedInternalFormat( 
sized_internalFormat, _sourceType ? _sourceType : GL_UNSIGNED_BYTE);
                OSG_FATAL<<"Texture2D : can't generate TextureStorage setup 
fails: "<<std::endl;
            extensions->glTexStorage2D( GL_TEXTURE_2D, (_numMipmapLevels 
>0)?_numMipmapLevels:1, sized_internalFormat, _textureWidth, _textureHeight);


robertosfield wrote:
> Hi Julien,
> On Wed, 15 Aug 2018 at 23:44, Julien Valentin
> <> wrote:
> > if I read all that correctly it seams assumeSizedInternallFormat is only 
> > used to create Texture from Image...I think an improvment would be to move 
> > assumeSizedInternallFormat from Texture to Image and change its name 
> > (getSizedTexInternallFormat).. It would lever some confusion and improve 
> > readabitlity of the Texture.cpp code ....
> > 
> > What od you think about that?
> > 
> This is what I was roughly thinking of.  One can't move the function
> from Texture to Image as not all textures have images.  You could have
> it in both places, or just have a function in the osg namespace and
> provide all the input variables for it.
> As a general guide, a Object::getMethod() typically gets a property
> from an object, but if a method computes the value on the fly from
> input variables I nornally opt for Object::computeMethod().   assume
> is a bit wishy washy so probably isn't ideal - this was used in the
> original glTexStorage PR but I probably should have suggested a
> change.
> We have to think about both master and the 3.6 branch here.  The later
> the aim is to maintain binary compatibility so our options are more
> constrained.
> Cheers,
> Robert.
> _______________________________________________
> osg-users mailing list
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>  ------------------
> Post generated by Mail2Forum

Twirling twirling twirling toward freedom

Read this topic online here:

osg-users mailing list

Reply via email to