Shadow Mapping support

[HolgerW1]

Currently broken, needs to be revised and fixed

[HolgerW1]

Found the root cause: MVP matrix for the shadow map shader is not calculated properly

[HolgerW1]

Support for shadow mapping in OpenGL ES 2.0 should now be working since 909635faccbd28e79ad519eeb03dd23570908a2e

PCF and OpenGL Es 1.1 support most likely won't make it into the next version

[ghost]

OpenGL ES Analyzer gives two errors (with a single cause) of the highest priority when meshes are rendered for shadow map: Non-Existent Framebuffer Attachment and Missing Framebuffer Attachments. I believe that is the reason why shadow map demo isn't running with 60 fps on the iPad 2. Will try to dig into it, but this isn't something I had much experience with previously.

Full description for the first: The framebuffer in use has an attachment that is referencing an object that no longer exists. This will cause an error and prevent the framebuffer from being usable. Check to see if this object was deleted.

And for the second: This framebuffer object has no attachments and therefore is not usable in its current state. You will need to attach at least one renderbuffer or texture in order to make it functional.

[HolgerW1]

I noticed the same error message reported by the OpenGL ES Analyzer during the testing phase before I released the updated version.

It seems that this is rather a Analyzer bug than a bug in the shadow mapping implementation. I guess the Anaylzer is unable to handle depth texture attachments of a framebuffer. If the Analyzer would be correct then the depth texture wouldn't be usable and the shadow map texture would be empty. But it actually does get rendered properly and the OpenGL ES debugger does show all attachements.

However, the error mesasge might indicate another problem I wasn't able to discover so far which might indeed have an impact on the performance. I unfortunately didn't have the time to investigate further.

Speaking of performance: shadow mapping does come with a significant performance loss, don't forget that another rendering pass along with some extra calculations during the final rendering are needed.

[ghost]

By the way, Non-Existent Framebuffer Attachment error exists even when fallback method is used without depth texture.

[HolgerW1]

Strange enough. I still think that the Analyzer does have some problems with the frame buffer texture attachments. Would be great if you could investigate further.

[ghost]

Yes, it is confirmed, we can ignore these two red square messages. Still, there is something wrong with performance. It is hard to believe that iPad 2 cannot handle shadow mapping with fps 60 on a reasonably complex scene, even after I switched it to the directional light to avoid perspective division and changing shadow coordinates in fragment shader. In my case I can even increase vertex shader workload 10 times without any changes in fps, seems like a bottleneck somewhere. I am still in the process to find it.

[HolgerW1]

Did you try to reduce the shadow map texture resolution?

A lot of calculations for the shadow mapping are done in the fragment shader which is always somehow problematic compared to the vertex shader (regarding performance). My experience is that it's almost impossible to get 60fps with the iPad2 and dynamic shadows using the shadow mapping technique, but at least 30fps seems to be achievable.

But I have to admit that I didn't do any deep profiling yet, so I don't really know what the real bottleneck is. Please keep me updated about your findings.

[ghost]

Yes, I tried different resolutions, and got interesting results. For iPad 2 256x256 and 2048x2048 give nearly the same framerate, whereas on iTouch 4G corresponding framerates are 31 and 22.

By some optimizations not directly related to shadow mapping I raised framerate on iPad to nearly 60 for my game (and what probably is more important here - I use directional light), but it is unstable and there is some twitching. This work is still in progress.

What is more interesting, is that on iTouch 4G, significant workload decrease has almost no effect on fps, whereas change of the texture resolution has a greater influence. Although if it's just a bandwidth limit - probably we cannot do much there and further investigation wouldn't help us with this issue on the newer devices. Still, I am going to continue to work in this direction either.

[ghost]

Found an interesting place in the results of a time profiling on iTouch. [Isgl3dView render] call takes 51.8%, 17.5% of which is clearing the texture (9.1% of total time. On iPad2 this value is 0.5%). Not yet aware of causes.

Running Time Self Symbol Name 2168.0ms 9.1% 1.0 -[Isgl3dGLDepthRenderTexture2 clear] 2148.0ms 9.0% 2.0 glClear 2145.0ms 9.0% 5.0 glClear_Exec 2030.0ms 8.5% 1.0 gleUpdateDrawFramebufferState 2028.0ms 8.5% 3.0 gpumUpdateDrawFramebuffer 2022.0ms 8.5% 1.0 glrBindContextDrawFramebuffer 2021.0ms 8.5% 3.0 sgxEndRender 2014.0ms 8.4% 3.0 sgxPatchDeferredFramebufferOffsets 1998.0ms 8.4% 4.0 sgxResolveDeferredFramebufferOffset 1979.0ms 8.3% 1.0 gfxIODataGetNewSurface 1975.0ms 8.3% 1.0 gliGetNewIOSurfaceES 1873.0ms 7.8% 76.0 _ZL29native_window_begin_iosurfaceP23_EAGLNativeWindowObject 1443.0ms 6.0% 8.0 usleep 1333.0ms 5.6% 57.0 __semwait_signal

[HolgerW1]

Interesting. Maybe clearing the color buffer causes some trouble in case no color buffer is available, i.e. if the pure depth rendering texture is being used. So you could try reducing the clear command to GL_DEPTH_BUFFER_BIT.

Discarding the buffer might help as well.

[ghost]

Tried clearing only depth buffer and discarding. Didn't help. Will ask on the Apple forum.