An implementation of tiled forward shading using libgdx

[Mollymus]

Not sure if I should put this here or in the showcase, or anywhere else, but I'll try my luck here.

I have just posted our first blogpost at our new website. It's about an efficient light model for top down 3d (and possibly 2d) games.
The idea:
The idea is based on tiled forward shading, but as the usecase is a top down game we can avoid the prepass and just cull the light sources very simply and basic on the cpu so that only light sources that are affecting the environment are used for the shading. Because we do not need a prepass I believe this approach can be used with great success on mobile devices, and our tests show that this assumption is correct.

The source (which can be found further down) is somewhat documented, but if there are any unclarities we would love to try and answer your questions. Any suggestions for improvements are also welcome!

Performance:
Here's a table over the maximum amount of lights we can support with 60(30) fps on the devices we have so far tested on.
Device: . . . Normal Shader - Our Shader
Galaxy s3 . . 9(20) . . . . . . . . 17(38)
Galaxy s2 . . 11(23) . . . . . . . .19(45)
Nexus 4 . . . X (22) . . . . . . . . 22(X)


From what we read/hear, fragment shaders are limited to a maximum amount of vec4 uniforms (i cant recall the results when I tested this myself..) and that is why the maximum supported light sources are 48 for our method (and 24 for the normal point light method, as that one needs to send radius and color in uniforms aswell.). We will work towards removing this cap in a later version by sending the positions aswell as the color and radius in the texture that now contains only the color and radius. We have not yet done this because it will require some testing (of how many channels are needed for each position float) to make sure that the precision is high enough. We suppose this will also depend on the size of the gameworld.

One important aspect to take into consideration when considering this technique is: the smaller part of the screen that each light affects, the more we benefit from this method!
Loads of small lights = use this!
Loads of superlarge lights = it might not matter too much which approach you pick.

We would love it if you guys would test the -> DEMO<- and provide some info about how well the shader performs on your device.



Source:
The source can be found -> HERE <- and contains all source for the desktop version of the demo, including shaders and assets.

[lyeeedar]

I just want to relay some of the results from my tests to you:

Linux nvidia drivers on my university lab machines crashed when passing in greater than 14 vec3's, 14 floats and 2 mat4's.
My desktop divers crash when passed greater than 42 vec4's, 42 floats and 2 mat4's.

Hope this is useful

[Mollymus]

Thanks for testing!

Did you run the desktop application from source?(Is there some way to run APK on desktop that I dont know of? or how did you know the amount of vecs / floats / mats? )

What rendermodes did the crashes occur with? Did you get any output why the crashes happend or is it just a memory-limitation in your drivers? Having trouble understanding why you'd be passing floats when there's not a single uniform float:( (except vectors and matrixes that use them..)

I have yet to crash it on my desktop, and the amount of light sources doesnt seem to affect it:( (Just tried with 200:p)

[bosoni]

Hi, tested that .apk with my galaxy mini. Dont know fps because it was outside of the little screen. And these TFS, NORM, Add, Del -buttons are so big that I couldn see much whats happening.
NORM was about 1fps, TFS was alot faster (I did see these light-dots moving, but background flickered).

[BurningHand]

On my Nexus 4, while using the TFS, I added enough lights to drop below a steady 60 FPS. That number was 22 (at 23 I dropped to 59-60 FPS so I went back to 22). Then I switched to the norm, which dropped me to 34 FPS. There was no noticeable visual difference between the two (execpt for the norm being visibly slower), so good job.

[lyeeedar]

Thanks for testing!

Did you run the desktop application from source?(Is there some way to run APK on desktop that I dont know of? or how did you know the amount of vecs / floats / mats? )

What rendermodes did the crashes occur with? Did you get any output why the crashes happend or is it just a memory-limitation in your drivers? Having trouble understanding why you'd be passing floats when there's not a single uniform float:( (except vectors and matrixes that use them..)

I have yet to crash it on my desktop, and the amount of light sources doesnt seem to affect it:( (Just tried with 200:p)

Oh sorry for the confusion, I didn't run your code, I was just posting some values from my own tests in writing shaders and trying to run them on various machines :p Mainly just a heads up that passing that many vec3's will crash a few drivers :p

[Mollymus]

Hi, tested that .apk with my galaxy mini. Dont know fps because it was outside of the little screen. And these TFS, NORM, Add, Del -buttons are so big that I couldn see much whats happening.
NORM was about 1fps, TFS was alot faster (I did see these light-dots moving, but background flickered).

Sorry about that, I will update the apk with a version that has scaling buttons and text sometime during the weekend, been very busy with an exam today and will be tomorrow aswell. I wonder what would cause the background to flicker, I have yet to experience that in any of my tests (mostly been doing PC tests though..). Does anyone have any ideas on the flickering?
Also, how many lights did you run it with? 4 lights at 1fps seems very very low:p

On my Nexus 4, while using the TFS, I added enough lights to drop below a steady 60 FPS. That number was 22 (at 23 I dropped to 59-60 FPS so I went back to 22). Then I switched to the norm, which dropped me to 34 FPS. There was no noticeable visual difference between the two (execpt for the norm being visibly slower), so good job.

Awesome, thanks for the test-data! Edited my initial post to include Nexus 4. We chose to let the lights move depending on framerate rather than time in order to visualise fps drops.

Thanks for testing!

Did you run the desktop application from source?(Is there some way to run APK on desktop that I dont know of? or how did you know the amount of vecs / floats / mats? )

What rendermodes did the crashes occur with? Did you get any output why the crashes happend or is it just a memory-limitation in your drivers? Having trouble understanding why you'd be passing floats when there's not a single uniform float:( (except vectors and matrixes that use them..)

I have yet to crash it on my desktop, and the amount of light sources doesnt seem to affect it:( (Just tried with 200:p)

Oh sorry for the confusion, I didn't run your code, I was just posting some values from my own tests in writing shaders and trying to run them on various machines :p Mainly just a heads up that passing that many vec3's will crash a few drivers :p

Right! Thanks for clearing that up! Had me scared for a while.. Yeah we are aware about limitations with sending uniforms to the gpu, and that is why we're going to send the positions as well in textures. (This is also why we already send color and radius in a texture rather than in vec4 uniforms for the TFS.)

Thanks for testing, both burninghand and bosoni!

[bosoni]

Played little more, scaled images smaller and compiled this by myself and now I see whats happening.

TFS: There is background all the time, so it wasnt that what flickers. It is some random pixels which flickers. 4lights 24fps.

NORM: it does not render lights, not even random pixels. 0lights = 1fps, more lights=0fps.

[Mollymus]

Thanks for playing with it! Could it perhaps be some limitation because of allocating so much (2x24 / 1x48) vec4s on the GPU? (Even though we only send 2 / 1 per light..) Anyone know if that could cause problems?

I just tested on my dad's superold xperia mini, and with TFS it could only support 1 light at 60 fps. With normal shader 1 light is at 4 fps though, and the shading doesn't even seem to work in normal mode.. I also experienced the flickering when I added more than 1 light in TFS mode.. Trying to think of what could cause this.. The flickering occurs "tile-wise".. I'm having trouble understanding what would cause it though.. Will continue thinking about it, now that I've seen it myself.. But then again, maybe 3d games with multiple light sources are not suited for low-end devices like this anyway..

Will try executing at very low resolution at my desktop later to see if its resolution-related, but I think not. Would love some more tests, especially from higher performing devices (because we use this technique in our game and we target devices equal to or stronger than Galaxy s2)!