[fixed]COpenGLFBODepthTexture GL_DEPTH_COMPONENT

You discovered a bug in the engine, and you are sure that it is not a problem of your code? Just post it in here. Please read the bug posting guidelines first.
Post Reply
devonsoft
Posts: 8
Joined: Thu Oct 04, 2012 2:01 am

[fixed]COpenGLFBODepthTexture GL_DEPTH_COMPONENT

Post by devonsoft »

I recently gave up on trying to get fixed function user clip planes into the right transformation space under opengl Irrlicht 1.7 and just put the clip space clipping plane in the vertex shader and then discarded the dotted result in the pixel shader. But that resulted in some depth clip aliasing issues on Mac. I eventually found the problem. When creating a COpenGLFBODepthTexture (line 819 in COpenGLTexture.cpp on svn) Irrlicht 1.7 and 1.8 calls glRenderBufferStorage with GL_DEPTH_COMPONENT.

Code: Select all

        Driver->extGlRenderbufferStorage(GL_RENDERBUFFER_EXT,
                GL_DEPTH_COMPONENT, ImageSize.Width,
                ImageSize.Height);
I believe GL_DEPTH_COMPONENT is supposed to select the "optimal" depth component available. Unfortunately what is optimal is OS/Driver dependent. So on Windows 7 on my ATI card OpenGL 4 it selects the highest one available (32-bit). The same computer on OSX 10.7 OpenGL 2 it selects 16-bit. I don't know what the best solution to this is. You could allow users to give a depth hint/argument when creating the render buffer texture, try to create the highest (32-bit) by default and trying lower values if this fails, or get the current depth of the screen and use that. Just using GL_DEPTH_COMPONENT24 fixes all of my problems:

Code: Select all

        Driver->extGlRenderbufferStorage(GL_RENDERBUFFER_EXT,
                GL_DEPTH_COMPONENT24, ImageSize.Width,
                ImageSize.Height);
OSX 10.7 (Macbook Pro 2011):
Image

Windows 7 (Same Macbook Pro 2011):
Image
Nadro
Posts: 1648
Joined: Sun Feb 19, 2006 9:08 am
Location: Warsaw, Poland

Re: COpenGLFBODepthTexture GL_DEPTH_COMPONENT

Post by Nadro »

I think that GL_DEPTH_COMPONENT24 is the best solution, because it's the most universal option (optionally we can use 16 bit depth component when at device creation process we selected 16 bit depth option). Maybe Hybrid have some more info about cons of this solution, if not we'll change it for current trunk.
Library helping with network requests, tasks management, logger etc in desktop and mobile apps: https://github.com/GrupaPracuj/hermes
hybrid
Admin
Posts: 14143
Joined: Wed Apr 19, 2006 9:20 pm
Location: Oldenburg(Oldb), Germany
Contact:

Re: COpenGLFBODepthTexture GL_DEPTH_COMPONENT

Post by hybrid »

Yes, this would also be my idea. Since we have no parameter set for now to configure the RTT, we should use the framebuffer settings to choose the value. So starting from the FB depth value, going down to 16, and in the end probably just the general DEPTH_COMPONENT value as fallback.
Nadro
Posts: 1648
Joined: Sun Feb 19, 2006 9:08 am
Location: Warsaw, Poland

Re: COpenGLFBODepthTexture GL_DEPTH_COMPONENT

Post by Nadro »

I fixed it in the latest trunk. A GL_DEPTH_COMPONENT is depend on ZBufferBits value from SIrrlichtCreationParameters. It support 16, 24, 32 and "auto/best - GL_DEPTH_COMPONENT" options.
Library helping with network requests, tasks management, logger etc in desktop and mobile apps: https://github.com/GrupaPracuj/hermes
Post Reply