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.mar...@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@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
> _______________________________________________
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
Bryan Thrall
FlightSafety International
bryan.thr...@flightsafety.com
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
