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
do.
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
mentionned)
-Fix the image less glTexStorage use case with
Code:
if( useTexStorrage)
{
//ensure _internalFormat is sized
GLenum sized_internalFormat = _internalFormat;
if(!isSizedInternalFormat( sized_internalFormat))
sized_internalFormat = assumeSizedInternalFormat(
sized_internalFormat, _sourceType ? _sourceType : GL_UNSIGNED_BYTE);
if(!sized_internalFormat)
OSG_FATAL<<"Texture2D : can't generate TextureStorage setup
fails: "<<std::endl;
extensions->glTexStorage2D( GL_TEXTURE_2D, (_numMipmapLevels
>0)?_numMipmapLevels:1, sized_internalFormat, _textureWidth, _textureHeight);
};
and
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:
http://forum.openscenegraph.org/viewtopic.php?p=74547#74547
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
