HI Julien,

I have replied on the original thread, it provides all suggestions
there, now you have started a new thread, arggg,   I'm not going to
double post as well as it's really not helpful to contribute to a
bifurcated thread.


On 7 February 2018 at 20:56, Julien Valentin <julienvalenti...@gmail.com> wrote:
> Hi,
> (Sorry to spam ML but I modified a lot my last post trying to be clearer
> and i also though a dedicated topic would be better..)
> So to sum up the problem:
> BindImageTexture stateattribute is not a textureattribute (_imageunit != 
> _textureunit) but it sometimes have to bind texture object on a textureunit 
> in case data of the associated texture has gone dirty
> The current implementation relies on user to setup 
> BindImageTexture::_targettex as texture attribute of "the same stateset" (and 
> then relies on this texatt to upload dirtied data if required)
> It works well but involves a systematic texture->apply (texobj.bind) overcost 
> at each use...
> to make BindImageTexture "autonomous", We then need:
> - a way to know if texture have to be applied :
> - a textureunit on which to applied
> What I've proposed :
> - clarify semantic given to textures::_modifiedcount to be the 
> textureobjectmodifiedcount. So, as texobjs are owned by Texture, i putted 
> modifiedcount in Texture and removed it from daughter classes.
> - in LayeredTextures (cubemap, texture2Darray) i changed modifiedcount to 
> layermodifiedcount these flags doesn't have the same purpose as the 
> textureobjectmodifiedcount as it's just a inner mechanism not to upload 
> unchanged layer image (not related to the textureobject state).
> and Then I added a textureunit prop in BindImageTexture, this tu is used to 
> applytexattribute(_targettex) if required.
> (Note it's user charge to set this prop correctely according other uses of 
> the _targettex as texattribute in the rest of your scenegraph)
> https://github.com/openscenegraph/OpenSceneGraph/pull/467
> My pr has been rejected:
>> Making _modifiedCount part of the base class is broken because you end up 
>> having to duplicate the data structure for the array version of texture.
>> Also I can grasp how 12 changed files could be at all a minimal change set. 
>> You've merged three set of changes into one commit.
>> Adding the texture unit as into BindImageTexture just feels like this class 
>> is getting more a more tightly coupled state that breaks the orthogonal 
>> design that the OSG and OpenGL try to maintain, the fact you are having to 
>> do this tight coupling suggests that approach is far from idea and may need 
>> revising at a fundamental level.
>> I'm closing this PR as it just contains too many different problems.
> so i'm now asking community reviews and insights because I can't see myself a 
> better compromise to finish BindImageTexture.
> Thanks in advance
> Cheers,
> Julien
> ------------------
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=72947#72947
> _______________________________________________
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
osg-users mailing list

Reply via email to