[osg-users] BindImageTexture Crash

[Robert Osfield]

Hi Juilien,

On 7 February 2018 at 18:59, Julien Valentin <julienvalentin51 at gmail.com> wrote:
> 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

It is a form of texture attribute, it relates directly to texture, the
only thing that decouples BindImageTexture from being a traditional
OSG style texture attribute is that you don't always need to apply the
texture unit when applying it as the interface provides this.  This
duality of concepts/implementation is down to OpenGL 4.x introducing
APIs that don't work like previous OpenGL APIs worked.

The only reason I can see for BindImageTexture attribute needing to
bind a particular texture unit being applying the texture would be to
avoid osg::State lazy state updating for not apply a texture for a
texture unit.

In normal OSG usage There are several things going on when you apply a
Texture::apply(), the create a texture object is not already created,
any data is uploaded to this texture object if required and the
texture object is made current to currently set up texture unit
(osg::State handles this part).  Once a texture is created doing a
Texture::apply() only really does the binding of the texture object to
the texture unit.

For BindImageTexture my guess is that if you do need to respond to the
dirty Texture by calling apply() is to just apply it on the current
texture unit and then may sure osg::State's lazy state updating knows
about it.  The osg::State::applyTextureAttribute(unsigned int unit,
const StateAttribute* attribute) method is the tool for the job.  The
actual texture unit is probably irrelevant as the OSG should
automatically reset if required so you could using unit=0 just fine,
or the value of osg::State::getActiveTextureUnit() if you want to
avoid changing as much state as possible,


> We then need a way to know if texture have to be applied:
>
> What I've propose :
> - clarify semantic given to textures::_modifiedcount to be the textureobjectmodifiedcount. Son as tos belong to Texture i putted modifiedcount in Texture and removed it from daughter classes

That's a dreadful idea given it directly conflicts with the
array/cubmemap version of texture subclasses, that alone should have
raised a red flag with your implementation not being appropriate.

Perhaps a virtual bool Texture::isDirty(const unsigned int contextID)
would be the way to implement a generic mechanism. This is the
standard object orientation way of decoupling interface from
implementation.


> -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 mecanism not t upload unchanged layer image (not related to the to)

modifiedCount implementation has the same function in all Texture
subclasses, of you tracking whether image data and associated texture
objects are in sync or not.