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); Cheers, Martin 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 <[email protected]> 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 > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
