[osg-users] [Toward BindImageTexture completness]

Julien Valentin julienvalentin51 at gmail.com
Wed Feb 7 12:56:42 PST 2018


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







More information about the osg-users mailing list