Shadow Mapping support about isgl3d HOT 12 OPEN

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

from isgl3d.

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

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

from isgl3d.

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.

from isgl3d.

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.

from isgl3d.

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

from isgl3d.

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.

from isgl3d.

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.

from isgl3d.

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.

from isgl3d.

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.

from isgl3d.

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

from isgl3d.

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.

from isgl3d.

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

from isgl3d.