Terry, Sort of. I set up an FBO of a fixed size and render to the size I need. To use and select only that smaller area I use an osg::TexMat to scale it up to the size I need, to essentially push off everything that wasn't in my viewport when I first rendered it. Sounds kind of convoluted but it was actually pretty easy.
Actually my problem is that the rendered to texture, or image, not sure which, is 1/4 the width it is supposed to be. Any ideas? So, do you know if I can use an INTENSITY_16F or LUMINANCE_16F texture as a render target? I'm having mixed success. -B --- RSC BDC > -----Original Message----- > From: Terry Welsh [mailto:[EMAIL PROTECTED] > Sent: Monday, September 11, 2006 3:38 PM > To: Brad Colbert > Cc: osg users; Robert Osfield > Subject: Re: [osg-users] Render to Image still clamping > > Hey Brad, > My problem was that I was trying to specify a viewport that was > smaller than the FBO, so I would only draw to a subsection of the FBO. > Are you doing anything with viewports? I never figured out the bug; > Robert magically solved it before I got that deep into the code. > -- > Terry Welsh - mogumbo 'at' gmail.com > www.reallyslick.com | www.mogumbo.com > > On 9/11/06, Brad Colbert <[EMAIL PROTECTED]> wrote: > > Ok, I should be flogged, repeatedly. If I simply make the call... > > > > setRenderTargetImplementation(osg::CameraNode::FRAME_BUFFER_OBJECT); > > > > when setting up the CameraNode that renders to the image, then I get > > unclamped values. Yeah! > > > > But, and there is always a but, it appears that the FBO is only half the > > width of the that it should be? Very strange. Is this similar to the > > issue that Terry Welsh was dealing with about 3 or 4 months ago? > > > > Humbly yours, > > Brad > > > > --- > > RSC > > BDC > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] [mailto:osg-users- > > > [EMAIL PROTECTED] On Behalf Of Brad Colbert > > > Sent: Monday, September 11, 2006 2:06 PM > > > To: osg users > > > Subject: RE: [osg-users] Render to Image still clamping > > > > > > Hi Robert, > > > > > > So, is for the render to image execution path, is the CameraNode > > > rendering to an FBO and then glGetPixels is called, or is it to the > > > framebuffer? The reason I ask is that I believe I set up the image > > like > > > this: > > > > > > _capImage->allocateImage(width, height, 1, GL_RGB, GL_FLOAT); > > > _capImage->setInternalTextureFormat(GL_RGB16F_ARB); > > > > > > I specify it as the target, and I still get a clamped image. If I > > > understood were the image is coming from, that may help. Is it the FB > > > or is it an FBO (texture)? > > > > > > Also, is there a callback I can set up for the CameraNode that, when > > it > > > is executed, the render context, whether it be FB or FBO, is still > > bound > > > so that I may make my own glReadPixels, or better yet glGetTexImage, > > > call? > > > > > > Thanks Robert, > > > Brad > > > > > > --- > > > RSC > > > BDC > > > > > > > -----Original Message----- > > > > From: [EMAIL PROTECTED] [mailto:osg-users- > > > > [EMAIL PROTECTED] On Behalf Of Robert Osfield > > > > Sent: Monday, September 11, 2006 12:19 PM > > > > To: osg users > > > > Subject: Re: [osg-users] Render to Image still clamping > > > > > > > > Hi Brad, > > > > > > > > You need to sift through the OpenGL extension docs up on > > opengl.org's > > > > extension registry for hints about the clamping behavior. By > > default > > > > OpenGL clamps all colours to the 0 to 1 range. I recall there being > > > > extensions that relax this, and certain pixel formats may do this by > > > > default. > > > > > > > > Robert. > > > > > > > > > > > > On 9/11/06, Brad Colbert <[EMAIL PROTECTED]> wrote: > > > > > > > > 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- > > > > [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] > > > > <mailto:[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] > > > > <mailto:[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://openscenegraph.net/mailman/listinfo/osg-users> > > > > http://www.openscenegraph.org/ > > > > > > > > > > > > > > _______________________________________________ > > > osg-users mailing list > > > [email protected] > > > http://openscenegraph.net/mailman/listinfo/osg-users > > > http://www.openscenegraph.org/ > > _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
