OpenSceneGraph Forum Forum Index OpenSceneGraph Forum
Official forum which mirrors the existent OSG mailing lists. Messages posted here are forwarded to the mailing list and vice versa.
 
   FAQFAQ    SearchSearch    MemberlistMemberlist    RulesRules    UsergroupsUsergroups    RegisterRegister 
 Mail2Forum SettingsMail2Forum Settings  ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
   AlbumAlbum  OpenSceneGraph IRC ChatOpenSceneGraph IRC Chat   SmartFeedSmartFeed 

[Toward BindImageTexture completness]


 
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> General
View previous topic :: View next topic  
Author Message
mp3butcher (Julien Valentin)
Appreciator


Joined: 17 Feb 2010
Posts: 462
Location: France

PostPosted: Wed Feb 07, 2018 8:56 pm    Post subject:
[Toward BindImageTexture completness]
Reply with quote

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:
Quote:
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

Edit: what could be done is virtualize getModifiedCount(uint)...bof...

Cheers,
Julien
Back to top
View user's profile Send private message Visit poster's website
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 12027

PostPosted: Thu Feb 08, 2018 12:14 pm    Post subject:
[Toward BindImageTexture completness]
Reply with quote

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.

Robert.

On 7 February 2018 at 20:56, Julien Valentin <> wrote:
Quote:
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:

Quote:
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








------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> General All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum

Similar Topics
Topic Author Forum Replies Posted
No new posts BindImageTexture Crash dcfennell General 10 Thu Feb 01, 2018 4:19 pm View latest post


Board Security Anti Bot Question MOD - phpBB MOD against Spam Bots
Powered by phpBB © 2001, 2005 phpBB Group
Protected by Anti-Spam ACP