[osg-users] glActiveTextureARB in OSG

Thrall, Bryan bryan.thrall at flightsafety.com
Thu Mar 12 07:43:43 PDT 2009


Großer Martin wrote on Thursday, March 12, 2009 7:20 AM:

> Hello Robert,
> 
> first ist works fine with setActiveTextureUnit(0)! Now I would like to
> specify my request. I create my Scene and build on my scenegraph and
> render my scene with frame(). I use a gtk embedded viewer like the
> osgviewerGTK-Example. After the rendering I use a own "render to texture
> class". This class based on OpenGL only. I use glCopyTexImage2D to
> translate the renderdata in the texture and project the texture on a
> plane. But if the active texture unit > 0 it doesn't work. That is the
> reason to change the active texture after the rendering.
> 
> Thats my new line after frame():
> 
> _graphicWindow->getState()->setActiveTextureUnit(0);

Perhaps osgPPU would help do what you want? It uses a pbuffer (see also osg::Camera::attach()), which would be faster than glCopyTexImage2D.

> Am Donnerstag, den 12.03.2009, 10:45 +0000 schrieb Robert Osfield:
>> Hi Martin,
>> 
>> On Thu, Mar 12, 2009 at 10:36 AM, Großer Martin <grosser.martin at gmx.de>
>> wrote: 
>>> I'd like to use a OSG class. But I don't know which class I can use.
>>> There are no way to change the active texture in osg or can I reset the
>>> opengl state machine? After the rendering ( frame() ) the active texture
>>> is not TEXTURE0_ARB, but that is what I need.
>> 
>> Use osg::State::setClientActiveTextureUnit(unsigned int unit);
>> 
>> It's implementation as:
>> 
>> bool State::setClientActiveTextureUnit( unsigned int unit ) {
>>     if (unit!=_currentClientActiveTextureUnit)
>>     {
>>         if (_glClientActiveTexture && unit < (unsigned
>>             int)_glMaxTextureCoords)         {
>>             _glClientActiveTexture(GL_TEXTURE0+unit);
>>         _currentClientActiveTextureUnit = unit;         } else
>>         {
>>             return unit==0;
>>         }
>>     }
>>     return true;
>> }
>> 
>> 
>> I would however recommend using OSG objects to do rendering, as well
>> as my previously stated reasons it also will mean that you won't have
>> clunky high level code trying to manage drawing of the OSG and OpenGL
>> code.  For instance you meantion rendering after viewer.frame() which
>> suggests you're making the assumption that you are working on a single
>> graphics context single thread and that the viewer hasn't released the
>> graphics context.  You can do all of these things but you have to know
>> what you are doing.
>> 
>> If you do things in the scene graph, all the management of multiple
>> graphics contexts and threading will just fall out for free.
>> 
>> Robert.
>> _______________________________________________
>> osg-users mailing list
>> osg-users at lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> 
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org



-- 
Bryan Thrall
FlightSafety International
bryan.thrall at flightsafety.com



More information about the osg-users mailing list