Terry,
Sorry, I covered way too many topics. Let's step back a second.
The 1/4 issue:
It appears that when I set up a CameraNode with:
setRenderTargetImplementation(osg::CameraNode::FRAME_BUFFER_OBJECT);
and
attach(osg::CameraNode::COLOR_BUFFER, _capImage.get());
I get only 1/4 of the rendered area. I'm not sure why. The image is
set up thusly:
_capImage = new osg::Image;
if (!_capImage.get())
return false;
_capImage->allocateImage(width, height, 1, GL_RGB, GL_FLOAT);
_capImage->setInternalTextureFormat(GL_RGB16F_ARB);
I had this same problem with OSG 1.0 (but didn't realize it until
later).
Any ideas on were to look? Could it be that glReadPixels isn't reading
enough?
-B
Let's talk about the viewport issue in another thread.
---
RSC
BDC
> -----Original Message-----
> From: Terry Welsh [mailto:[EMAIL PROTECTED]
> Sent: Monday, September 11, 2006 4:00 PM
> To: Brad Colbert
> Cc: osg users; Robert Osfield
> Subject: Re: [osg-users] Render to Image still clamping
>
> Don't know if I fully understand you. So 3/4 of your FBO gets nothing
> rendered to it? How do you render to a size smaller than the whole
> FBO, using Viewport or TexMat?
>
> I have used LUMINANCE_16F before, but not with OSG.
>
> On 9/11/06, Brad Colbert <[EMAIL PROTECTED]> wrote:
> > 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/
> > > >
> >
>
>
> --
> Terry Welsh - mogumbo 'at' gmail.com
> www.reallyslick.com | www.mogumbo.com
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
