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 > > [email protected] > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > E-Mails jetzt auf Ihrem Handy. www.yahoo.de/go _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
