[osg-users] render to a texure bound to an FBO and re-generate mipmaps every frame

Julius Ziegler ziegler at atlatec.de
Wed Apr 11 01:24:19 PDT 2018

Ok, I have solved it. It was my poor understanding of the OpenGL 
extension mechanism. I discovered the osg way to handle extensions and 
now I call glGenerateMipmap like this:

osg::GLExtensions* ext = renderInfo.getState()->get<osg::GLExtensions>();

With this, mipmapping in the osgprerender example works!

I now will try this in my more contorted development code...

On 04/11/2018 10:00 AM, Julius Ziegler wrote:
> Hello Robert,
> the first issue that I mentioned, and the sefault of the attempted fix, 
> can be reproduced by slightly adapting the osgprerender.cpp example 
> (attached). I set the texture filtering to something mipmap-ish:
> ...
> texture2D->setFilter(osg::Texture2D::MIN_FILTER,osg::Texture2D::LINEAR_MIPMAP_NEAREST 
> );
> texture2D->setFilter(osg::Texture2D::MAG_FILTER,osg::Texture2D::LINEAR);
> ...
> When zooming out, one of the lower mipmap layers becomes active and the 
> content of the flag becomes static.
> As I said, I do not consider this a bug. I know that, on the OpenGL 
> side, an extra call to glGenerateMipmap is required.
> My first clumsy approach to inject this glGenerateMipmap call was to 
> attach a callback to the flag-drawable:
> struct CreateMipmapCallback : osg::Drawable::DrawCallback
> {
>    void drawImplementation( osg::RenderInfo& renderInfo, const 
> osg::Drawable* dwbl ) const override
>    {
>      // these three clears I made to be able to spot
>      // them in a trace of the GL calls
>      glClear( GL_DEPTH_BUFFER_BIT );
>      glClear( GL_DEPTH_BUFFER_BIT );
>      glClear( GL_DEPTH_BUFFER_BIT );
>      // this crashes
>      // glGenerateMipmap(GL_TEXTURE_2D);
>      // just decorate the existing draw function.
>      dwbl->drawImplementation(renderInfo);
>    }
> };
> But glGenerateMipmap segfaults. To be able to call it, I included and 
> linked GLEW. Could that be the problem? I somehow have the impression 
> that I am following an invalid function pointer here.
> I have attached the modified osgprerender source code. GLEW must be 
> linked to it. I build with this cmdline
> g++ osgprerender.cpp -o osgprerender `pkg-config --libs --cflags 
> openscenegraph` -std=c++11 -lGLEW -lGL
> I have tested this with OSG 3.4.0 on Linux 14.04 with an nvidia driver. 
> glxinfo | grep OpenGL shows this:
> OpenGL vendor string: NVIDIA Corporation
> OpenGL renderer string: GeForce GTX 750 Ti/PCIe/SSE2
> OpenGL core profile version string: 4.3.0 NVIDIA 384.111
> OpenGL core profile shading language version string: 4.30 NVIDIA via Cg 
> compiler
> OpenGL core profile context flags: (none)
> OpenGL core profile profile mask: core profile
> OpenGL core profile extensions:
> OpenGL version string: 4.5.0 NVIDIA 384.111
> OpenGL shading language version string: 4.50 NVIDIA
> OpenGL context flags: (none)
> OpenGL profile mask: (none)
> OpenGL extensions:
> This is a "vanilla" build of OpenSceneGraph with no special build settings.
> My actual target system is more complicated, since for various 
> compatability reasons (Intel driver without proper compatability 
> profile) I had to both build a GL3 version of OSG, and use a recent 
> repository version of it. This might be the reason for the second 
> problem I have, but we can discuss this later.
> How do I properly call glGenerateMipmap?
> Thanks!
> Julius
> On 04/10/2018 10:06 PM, Robert Osfield wrote:
>> Hi Julius,
>> There isn't much we can do to help at this stage as you don't provide
>> any information about the hadware, OS, driver, OSG version, all we
>> know is that you are using a render to texture technique and there is
>> some issue with mipmapping and some unspecified hardware, OS and OSG
>> version.  We don't have your sofftware, data or hardware configuration
>> to test against.
>> It could be a driver bug, it could be a scene graph set up issue, it
>> could be a data problem, it could be an OSG  bug, at this stage that's
>> all anyone could say with the information provided.
>> The most productive way for others to help would be if you could
>> provide a small test program that illustrates the problem so that
>> others can run this test on their own systems to see if problem
>> appears, this then should shine more light on the nature of the
>> problem and give us a better chance of getting a solution.  Sometimes
>> issues like this turn out to hardware/driver/OS specific so wider
>> testing can show this.  If it's a OSG bug then we can then use this a
>> unit test for testing any fixes that will be made.
>> Failing a means to tests things ourselves, the only workaround I an
>> suggest is to not using mipmapping on the texture you are rendering
>> to.
>> Robert.
>> On 10 April 2018 at 20:45, Julius Ziegler <ziegler at atlatec.de> wrote:
>>> Dear OSG-friends,
>>> I currently have a scene graph set up where a pre-render camera renders
>>> content to a texture via an FBO, and the main camera uses this 
>>> texture to
>>> texture a quad with it. This works, in principle.
>>> However I need mipmapping for that texture, and all but the 0th 
>>> mipmap level
>>> of the texture are empty.
>>> With an apitracer, I found out that the glGenerateMipMap call happens
>>> 1. only in the first frame (but I want it to be called every frame).
>>> 2. before any draw calls towards the FBO (but I want it after the draw
>>> calls).
>>> I tried to inject a glGenerateMipMap via a DrawCallback which I 
>>> attached to
>>> the quad, and which just extends the original draw implementation
>>> (glGenerateMipMap immediately before the original draw implementation).
>>> With the apitracer, I validated that, at the position where I 
>>> injected the
>>> glGenerateMipMap
>>> a. the correct texture is bound
>>> b. the frame buffer is un-bound.
>>> But glGenerateMipMap just seg'faults. Because of the seg'fault (I 
>>> mean we
>>> are all used to GL_ERRORS, but seg'faults?) I suspected a driver 
>>> issue, but
>>> I tried it on an alternative platform (one is Intel Graphics, one is 
>>> Nvidia,
>>> both on Linux). Both to the same result.
>>> Can you please help? Maybe I overlooked a simple osg-ish way to 
>>> achieve this
>>> (maybe I just have to set something dirty()?)
>>> Thanks!
>>> Julius
>>> _______________________________________________
>>> 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
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Dr.-Ing. Julius Ziegler

Phone:  +49 151 722 026 63
E-Mail: ziegler at atlatec.de
Web:    www.atlatec.de

Atlatec GmbH
Haid- und Neu-Strasse 7
D-76131 Karlsruhe

Sitz der Gesellschaft: Karlsruhe | Registergericht Mannheim
Handelsregisternummer: HRB 718673 | USt-IdNr. DE293003755
Geschäftsführer: Dr. Henning Lategahn

More information about the osg-users mailing list