Hi Juilien, On 7 February 2018 at 18:59, Julien Valentin <[email protected]> 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. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
