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/
