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
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
