Hi Robert, > Thanks, these changes look more robust now and are merged > and submitted to SVN. > > I'm still not 100% happy with this approach, and feel > that perhaps > some of the functionality really should be pushed back into > the base > classes.
I understand you and share the same feeling. The problem is, that the normal PBO class is also used in a very strict way in the osg::State, which makes it harder to change the implementation because of possible incompatibility to older version. > I can't say exactly how it should look > without working > directly on end user code that uses the classes in the ways > such as > you're using it. When I get to quieter spell I'll > have another look > at the custom PBO code that I put into the osgscreencapture > example, > as this might be able to use your new class and should give > me a > better feel. > Actually changing the PBO class to its general definition isn't that hard task. However changing the code depending on it, is more complicated. I'll try another implementation before osg 2.8 and let you know, whenever I have a better solution. > Another area that it'd be nice to have supported is the > ability to > render to a PBO and then bind this as a VBO to give a > render to vertex > array solution. > This shouldn't be a big problem. The good thing with PBOs is that just changing its target will change its functionality. Hence I think, it shouldn't be a big issue to just bind the PBO as VBO before one does need it (assuming there is correct data in the PBO). Art > Robert. > > On Sun, Nov 30, 2008 at 5:25 PM, Art Tevs > <[EMAIL PROTECTED]> wrote: > > Hi, > > > > OK, here is a changed version supporting mode per > context. Take a look. > > > >> BTW, how are you passing in/out data to the new > >> PixelDataBufferObject? > >> Are you subclassing from PixelDataBufferObject > yourself? > > > > In current implementation no, however this is of > course also possible. > > Currently I just bind the buffer into read or write > mode and also bind the texture I want to write or to read > from respectively. Then I do either call > > glTexSubImage if buffer is in read mode (hence write > from buffer into texture) or glGetTexImage if buffer is in > write mode (hence read from texture). > > This enables me texture data moving in/out to the PBO. > > > > My first implementation was something like the current > PBO but with a texture attached, so that the texture was > used instead of the image. However this would also > specialize the PBO and isn't that general. > > > > > > As future specialization of the new PBO we could > derive new classes like PixelBufferObjectImage and > PixelBufferObjectTexture enabling moving data between PBO > and image or texture, I think. > > > > > > Cheers, > > Art > > > > > > --- Robert Osfield <[EMAIL PROTECTED]> > schrieb am So, 30.11.2008: > > > >> Von: Robert Osfield > <[EMAIL PROTECTED]> > >> Betreff: Re: [osg-submissions] General PBO > implementation for GPU only memory handling (usefull for > CUDA interoperability) > >> An: [EMAIL PROTECTED], "OpenSceneGraph > Submissions" > <[email protected]> > >> Datum: Sonntag, 30. November 2008, 18:07 > >> Hi Art, > >> > >> On Sun, Nov 30, 2008 at 4:58 PM, Art Tevs > >> <[EMAIL PROTECTED]> wrote: > >> > This was also my thoughts: to rewrite > >> PixelBufferObject for more general implementation. > However, > >> this could make it backward incompatible, hence I > wrote this > >> new class. As I said before, this is one of the > points to be > >> included into major version step todo list. > >> > >> Once you I've done a full review of your > changes > >> I'll look at the what > >> merging them would do in terms of API. > >> > >> BTW, how are you passing in/out data to the new > >> PixelDataBufferObject? > >> Are you subclassing from PixelDataBufferObject > yourself? > >> > >> > >> > The mode variable do just specify in which > current > >> mode (read/write/normal) the buffer object is. > True, one > >> need to buffer the value for each context, you are > right. > >> > >> Could you implement this. Please note you'll > need to > >> implement any > >> resize of the GL buffers to cope with new contexts > being > >> introduced. > >> Once this change is made I'll have another > bash at > >> merging. > >> > >> Robert. > > > > > > > > _______________________________________________ > > osg-submissions mailing list > > [email protected] > > > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > > > > > _______________________________________________ > osg-submissions mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
