Guillaume,
I don't exactly know what
combination you are referring to, but using an osg::Image as an attachment
does not allow unclamped float values. While I can attach a float
texture to an FBO and have it generate results in unclamped values, there is
no way to get those values out of the texture and into main memory as an
osg::Image. Using the float texture for subsequent drawing operations
works just fine.
The way I tested it out
was to modify osgprerender to add a fragment shader to the loaded model.
Snippet below. This shader just sets the pixel color to
(-1,-1,-1). I also added a line in the camera postDraw to print
something if the pixel is negative, which doesn't happen. If you examine
the output, you will see that the values get clamped to
(0,0,0).
// Test out range of
returned buffer by setting results to -1. osg::ref_ptr<osg::Program>
program = new osg::Program; osg::ref_ptr<osg::Shader> fragmentShader =
new osg::Shader(osg::Shader::FRAGMENT);
std::string frag = "void
main() { gl_FragColor.rgb = vec3(-1,-1,-1); }\n";
fragmentShader->setShaderSource(frag);
program->addShader(fragmentShader.get());
subgraph->getOrCreateStateSet()->setAttributeAndModes(program.get(),
subgraph->osg::StateAttribute::ON);
Run as: osgprerender
--image --hdr cow.osg
What I have been able to
do is modify Image::computeNumComponents() so that it recognizes the ARB
formats I am interested in. The other half of the problem was in
readImageFromCurrentTexture() when calling glGetTexImage with an ARB pixel
format. It was using the internal format of the texture, which was
throwing OpenGL errors (invalid enumerant). I remapped the ARB value to
the non-ARB version (GL_RGB). Those two changes allows
readImageFromCurrentTexture() to work with the ARB texture
formats.
Chuck
Seberino
-----Original
Message-----
From: Poirier, Guillaume
[mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 03,
2006 11:32 AM
To: osg
users
Subject: RE: [osg-users]
Retrieving texture contents from ARB float FBO RTT
Hi
Chuck,
I do bind an image with a
float texture without clamping in my code...
You do need to specify
proper internal and source formats, like GL_FLOAT when you call
osg::Image::allocateImage() and GL_FLOAT_R32_NV / GL_RED when you create the
texture.
guillaume
-----Original
Message-----
From:
[EMAIL PROTECTED] on behalf of Chuck
Seberino
Sent: Tue 10/3/2006
2:20 PM
To: 'osg
users'
Subject: RE: [osg-users]
Retrieving texture contents from ARB float FBO RTT
Robert,
I worked with osgprerender
to see if I could get the osg::Image readback to work. Unfortunately it
seems that using that approach, versus attaching a texture, causes the results
to be clamped to within [0,1]. The whole reason for using the ARB format
and FBO was to get the full floating point range. I believe that using a
texture attachment is the only way around the clamping.
Aside from patching
osg::Image to properly handle the ARB texture format, my only course seems to
be using glReadPixels while the FBO Texture is active. I looked into this, but
like I said before, there doesn't seem to be an easy
(clean) way to get
this. I have a post draw for the camera node that has access to the
SceneView pointer. From there I can get the RenderStage. My camera
is being drawn in a preRender, so it's RenderStage is tucked into the
preRenderList - of which there is no public access. There doesn't seem
to be a way for me to get the fbo handle so that I can enable it and read the
texels.
Looking at the code for
RenderStage, there already seems to be code ready to do glReadPixels. I
just need to give it a valid osg::Image via setImage. So it looks like my big
holdup is in figuring out and acquiring the RenderStage handle that applies to
my CameraNode. Any suggestions?
Chuck
-----Original
Message-----
From: Robert Osfield [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 02,
2006 1:25 AM
To: osg
users
Subject: Re: [osg-users]
Retrieving texture contents from ARB float FBO RTT
Hi
Chuck,
On 10/2/06, Chuck Seberino
<[EMAIL PROTECTED]> wrote:
I have some code that sets
up a CameraNode with a FBO as the target. The texture attached to the
FBO has a format of GL_RGB32F_ARB. This seems to work just great.
The problem is that I want
to be able to read in the value of the texture as an osg::Image after
drawing. I have used
image->readImageFromCurrentTexture(),
but osg::Image doesn't know about
image->the
ARB formats when
performing the bit size calculations. Is this a deficiency in
computNumComponents() or is there something I am missing? Even hacking
that method to calculate it correctly doesn't solve things. I didn't get
a chance to dig deeper to see what the next roadblock was.
Missing support for the
ARB pixel formats is obviously one missing element that will need addressing,
as for what other gotcha's could be causing problems its hard to point point
without digging into to debugging myself.
Is there a better way to
grab the texture back into main memory? In OpenGL-land I would call
glReadPixels while the FBO was active, but there doesn't seem to be an easy
way to do that in OSG either.
The osgprerender example
provides a path that attaches an osg::Image to the CameraNode, and this gets
read back in automatically so you can probably use this. There is also
support for post draw callback on CameraNode that you could use to implement
your own glReadPixels call.
Could you modify
osgprerender to use the pixel format you are having problem with and if this
recreates the problem then send the modified file along to me and I'll have a
go at debugging it.
Robert.
