Hi Art, I don't think the OSG has itself issues here, rather its what you are doing at you end is introducing problems that don't exist otherwise. For instance normally users will use FBO as an attachment to an osg::Camera, and the OSG rendering backend with do the glClear as specified by the osg::Camera settings.
If you have custom code that uses FBO's and needs to do a glCear then you'll need to add this call yourself such as via subclassing of osg::FrameBufferObject, or by create a RenderStage for the FBO as part of the rendering backend. Robert. On Wed, May 7, 2008 at 11:04 AM, Art Tevs <[EMAIL PROTECTED]> wrote: > Hi Robert, > > > > > > If you want a specific image in osg::Texture then > > just attach an > > osg::Image containing > > black pixels. > > > Of course I could do this, however I do not want to > for several reasons: > - long upload time > - the image is not needed at all, I am interested > only in an empty texture > - using more system memory to holding the image data > > > > > W.r.t call glTexImage?D with a null pointer, this > > just allocates the > > memory, as far as I'm > > aware there is no formal rules about initialization > > of it, and as such > > its undefined so getting > > random data is prefectly valid. > Yes, it is. It is in deed valid. > > > > The intention of > > this null pointer > > support in glTexImage is > > purely for allocation, its intended that it'd be > > followed up with > > glTexSubImage calls to set it, > > if you don't have this in your own code and are > > getting random results > > it down to a bug > > in your code. > > > Even if I would have this in my code, uploading data > to the texture is not so straight forward with osg, > because of all that context and state things (I have > to proivde a state for applyTexImage2D_subload, but > where do I get it from during the creating of that > texture) > > I completly understand, that getting random values is > a valid behaviour in respect to specifications. > However I also want to have something like a clear > method on a texture, to allow filling the texture with > some predefined value during the apply. Of course this > would stay completely orthogonal to existing texture > behaviour. > > > My idea was to do following as soon as user request > clear on the next apply: > - if user hardware supports FBOs then create a > temporary fbo, setup clear color with glClearColor and > call glClear. This will write predefined value into > that texture pretty efficient (of course don't forget > to bring the gl pipeline in the previous state back) > > - if hardware do not support fbo, then do this in the > image way, hence create temporary an array holding the > default color value and upload it to the texture. This > would be slower however will also work. > > > Cheers, > Art > > > > > > Robert. > > > > On Wed, May 7, 2008 at 12:17 AM, Art Tevs > > <[EMAIL PROTECTED]> wrote: > > > Hi folks, > > > > > > I think I've found an improvement or a possible > > bug > > > for the textures in osg. If one do allocate empty > > > textures (not from images) then the texture is > > created > > > with glTexImageXD call and with 0 as pixel > > pointer. > > > > > > As per OpenGL 1.1 specification the texture is > > > allocated but the data in the texture is not > > defined. > > > On some machines this is not an issue, since the > > > freshly allocated texture do contain just 0 for > > every > > > pixel. However on some setups the texture do > > contain > > > random data. > > > > > > For my case I do need to assume that the fresh > > > allocated textures do contain 0 as values. Hence > > I > > > need something like cleanup function, which do > > bring > > > the texture in a defined state after it was > > allocated. > > > Therefor I would like to write a patch for the > > texture > > > classes which do fill the texture with some > > defined > > > value (default 0) during the allocation if user > > whish > > > this. > > > > > > Any comments, ideas or suggestions? > > > > > > > > > Best regards, > > > Art > > > > > > > > > > > > > > > > > > > > > > > > E-Mails jetzt auf Ihrem Handy. > > > www.yahoo.de/go > > > _______________________________________________ > > > osg-users mailing list > > > osg-users@lists.openscenegraph.org > > > > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > > > _______________________________________________ > > osg-users mailing list > > osg-users@lists.openscenegraph.org > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > > > > E-Mails jetzt auf Ihrem Handy. > www.yahoo.de/go > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
