[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>();
ext->glGenerateMipmap(GL_TEXTURE_2D);
...
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