Hi folks, I was wondering if I could get a short description of how the render to image process works for a CameraNode. It appears that my images are still clamped and digging through the code I see that glReadPixels is being called, but I also see a call for glGetTexImage, but I'm unsure if this is used. Can anyone shed light on how the CameraNode does it's render to image? Also, is there a way to define a call back for a CameraNode that is rendering to an FBO so that the texture is still bound and then I can make the call to glGetTexImage. This would save me a ton of hassle
Thanks, Brad --- RSC BDC > -----Original Message----- > From: Eric Sokolowsky [mailto:[EMAIL PROTECTED] > Sent: Monday, September 11, 2006 9:58 AM > To: Brad Colbert > Cc: Eric Sokolowsky > Subject: RE: [osg-users] OpenSceneGraph-1.1 Release Candidate this week > > On Mon, 11 Sep 2006, Brad Colbert wrote: > > > Eric, > > > > Thanks, I'll keep poking around. I know it's not the drivers because I > > wrote a program in OpenGL as well as Vega Prime that downloads the > > images without alteration. One thing I did notice is that it looks like > > glReadPixels is being used instead of glGetTexImage. I wonder if this > > has something to do with it? > > This is probably the case. glReadPixels reads from the display frame > buffer which is probably NOT in a floating point format. glGetTexImage > reads > from a texture image which can be stored on the graphics card in a > floating > point format. Your rasterization step will generate values 0-255 which, > when read back as floating point, will be converted from 0-1. > > I do not know much about FBOs but I presume that they similarly are > implemented as a RGB[A] 8-bit integer buffer. > > > > > > -B > > > > --- > > RSC > > BDC > > > >> -----Original Message----- > >> From: Eric Sokolowsky [mailto:[EMAIL PROTECTED] > >> Sent: Monday, September 11, 2006 8:59 AM > >> To: Brad Colbert > >> Cc: Eric Sokolowsky > >> Subject: RE: [osg-users] OpenSceneGraph-1.1 Release Candidate this > > week > >> > >> On Mon, 11 Sep 2006, Brad Colbert wrote: > >> > >>> Hi Eric, > >>> > >>> There is still an issue with rendering to an image, where the image > > is > >>> clamped at 1.0 (for a floating point destination). It's a little > >>> difficult to follow the thread of where the image is being > > downloaded so > >>> I'm not sure at what point it is being clamped. I know my image > > isn't > >>> clamped in texture memory because when I change my destination to be > > an > >>> FBO and place a simple shader on the result that throws 0 - 1.0 into > >>> blue, 1.0 - 2.0 into green, and 2.0 - 3.0 into red I get the values > > I > >>> expect (blue fading into cyan and white). (BTW this basically how I > >>> have to get the image out now). > >> > >> Hmm. I'm afraid this is a little outside my expertise. I have not yet > >> tried out FBOs, and I haven't tried rendering to texture. I highly > > doubt > >> that OSG is doing the clamping, so it is probably in the OpenGL driver > >> somewhere. This is a complete guess. Most of my work was to help read > >> back compressed textures after they have been compressed by the > > hardware > >> and/or the OpenGL driver, in order to save them to disk for reuse. I > >> probably won't be able to help you much with your issue. > >> > >> Perhaps you could ask your OpenGL driver vendor. > >> > >>> > >>> I can modify the prerender example to do something similar if that > > will > >>> help. > >>> > >>> Thanks, > >>> Brad > >>> > >>> --- > >>> RSC > >>> BDC > >>>> -----Original Message----- > >>>> From: Eric Sokolowsky [mailto:[EMAIL PROTECTED] > >>>> Sent: Monday, September 11, 2006 8:44 AM > >>>> To: Brad Colbert > >>>> Cc: osg users; Eric Sokolowsky > >>>> Subject: RE: [osg-users] OpenSceneGraph-1.1 Release Candidate this > >>> week > >>>> > >>>> On Sat, 9 Sep 2006, Brad Colbert wrote: > >>>> > >>>>> Eric, > >>>>> > >>>>> Did your update or changes make it into the current tree? I'm > > still > >>>>> having the same problem of clamping when trying to capture an FP16 > >>>>> image. If not, what changes did you make? This is really a show > >>>>> stopper for me, since I need unclamped values to get the real > >>> statistics > >>>>> from my HDR scene. > >>>> > >>>> Yes, my changes made it into CVS. The > >>>> osg::Image::readImageFromCurrentTexture > >>>> API function now has an optional parameter at the end which defines > >>> the > >>>> type to > >>>> be used when reading. If not given it will default to > >>> GL_UNSIGNED_BYTE. > >>>> It > >>>> turns out that this value is not stored by OpenGL anywhere; it just > >>> reads > >>>> and > >>>> converts whatever is there to the format requested. I have also > > fixed > >>> some > >>>> state inconsistencies when reading textures this way. > >>>> > >>>> I believe the changes I made are sufficient for my purposes, but if > >>> there > >>>> is something else that needs to be done, I am willing to look again > > at > >>> it. > >>>> > >>>>> > >>>>> Thanks, > >>>>> Brad > >>>>> > >>>>> --- > >>>>> RSC > >>>>> BDC > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: [EMAIL PROTECTED] [mailto:osg-users- > >>>>>> [EMAIL PROTECTED] On Behalf Of Eric Sokolowsky > >>>>>> Sent: Wednesday, July 05, 2006 2:48 PM > >>>>>> To: osg users > >>>>>> Subject: Re: [osg-users] OpenSceneGraph-1.1 Release Candidate > > this > >>>>> week > >>>>>> > >>>>>> On Wed, 5 Jul 2006, Robert Osfield wrote: > >>>>>> > >>>>>>> Hi Eric, > >>>>>>> > >>>>>>> On 7/5/06, Eric Sokolowsky <[EMAIL PROTECTED]> > > wrote: > >>>>>>>> I have determined that when reading a texture back, > >>>>> Image::_pixelFormat > >>>>>>>> and Image::_internalTextureFormat should be set to the same > >>> value, > >>>>>> which > >>>>>>>> is obtained with a call to > > glGetTexLevelParameteriv(textureMode, > >>> 0, > >>>>>>>> GL_TEXTURE_INTERNAL_FORMAT, ...). That is fine. But I still > >>> haven't > >>>>>>>> found a way to get the pixel format from OpenGL. Perhaps we > > need > >>> to > >>>>> add > >>>>>>>> something to the osg::State to track this. > >>>>>>> > >>>>>>> I'm afraid I'm too cold on this topic to provide much insight. > >>>>>> > >>>>>> Well, the call to glGetTexImage() asks for a format and a type. > > The > >>>>>> format parameter can be obtained from OpenGL, but the type cannot > >>> be. > >>>>>> Therefore, it seems reasonable to add a "type" argument to > >>>>>> osg::Image::readImageFromCurrentTexture, instead of arbitrarily > >>>>> mandating > >>>>>> one type or another. The current implementation is buggy in that > > it > >>>>>> sets the type parameter to the same internal format that is used > > as > >>>>> the > >>>>>> format parameter. > >>>>>> > >>>>>> This should also help Brad Colbert with his texture read > > precision > >>>>>> problem. > >>>>>> > >>>>>> A changed file is forthcoming. > >>>>>> > >>>>>> > >>>>>>>> BTW, the set of images I was having trouble with were not a > >>>>> multiple of > >>>>>>>> four in size. OpenGL will report an error when trying to use a > >>>>>>>> compressed texture with glTexSubImage2D() if the subloaded > >>> texture > >>>>> is > >>>>>>>> not of a multiple of four in both dimensions. Is this something > >>>>> that > >>>>>>>> should be checked for by OSG? I have a workaround in my > >>> application > >>>>>> that > >>>>>>>> will disable texture compression on images that are not a > >>> multiple > >>>>> of > >>>>>>>> four in size. > >>>>>>> > >>>>>>> I believe the limit of a multiple of 4 is something related to > > the > >>>>>>> S3TC compression where it uses blocks of pixels as its block to > > do > >>>>> the > >>>>>>> compression. > >>>>>> > >>>>>> Yes, this is exactly the reason. The question is, is it > > worthwhile > >>>>> coding > >>>>>> a check for this condition in OSG? I don't want to code it if it > >>>>> stands > >>>>>> little success for inclusion in OSG proper. I already have a > >>>>> workaround > >>>>>> for > >>>>>> my application that deals with this situation, but the general > >>>>> solution > >>>>>> might be useful to others as well. The change would merely > > disable > >>> the > >>>>>> compression request for images that are not a multiple of four in > >>>>> either > >>>>>> dimension, when glTexSubImage2D() is called. > >>>>>> > >>>>>> -- > >>>>>> ____ __ Eric Sokolowsky (GST) NASA Goddard Space > >>> Flight > >>>>>> Center > >>>>>> / __/__/_/__ Visualization Programmer Scientific > >>> Visualization > >>>>>> Studio > >>>>>> / __/ _/ / _/ 301.286.3751 Mailstop 610.3 > > Bldg > >>> 28 > >>>>> Rm > >>>>>> E102 > >>>>>> /___/_//_/__/ [EMAIL PROTECTED] Greenbelt, MD > > 20771 > >>>>>> _______________________________________________ > >>>>>> osg-users mailing list > >>>>>> [email protected] > >>>>>> http://openscenegraph.net/mailman/listinfo/osg-users > >>>>>> http://www.openscenegraph.org/ > >>>>> > >>>> > >>>> -- > >>>> ____ __ Eric Sokolowsky (GST) NASA Goddard Space > > Flight > >>>> Center > >>>> / __/__/_/__ Visualization Programmer Scientific > > Visualization > >>>> Studio > >>>> / __/ _/ / _/ 301.286.3751 Mailstop 610.3 Bldg > > 28 > >>> Rm > >>>> E102 > >>>> /___/_//_/__/ [EMAIL PROTECTED] Greenbelt, MD 20771 > >>> > >> > >> -- > >> ____ __ Eric Sokolowsky (GST) NASA Goddard Space Flight > >> Center > >> / __/__/_/__ Visualization Programmer Scientific Visualization > >> Studio > >> / __/ _/ / _/ 301.286.3751 Mailstop 610.3 Bldg 28 > > Rm > >> E102 > >> /___/_//_/__/ [EMAIL PROTECTED] Greenbelt, MD 20771 > > > > -- > ____ __ Eric Sokolowsky (GST) NASA Goddard Space Flight > Center > / __/__/_/__ Visualization Programmer Scientific Visualization > Studio > / __/ _/ / _/ 301.286.3751 Mailstop 610.3 Bldg 28 Rm > E102 > /___/_//_/__/ [EMAIL PROTECTED] Greenbelt, MD 20771 _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
