3.1 Sneak peek : Light culling and Single pass lighting

As many of you knows, JME 3.0 only has a Forward rendering pipeline. One of the major drawbacks of such a pipeline is that it basically does one geome
[See the full post at: 3.1 Sneak peek : Light culling and Single pass lighting]

11 Likes

The link to the full post does not work for me…

Hm the above post links to itself :stuck_out_tongue:

@Empire Phoenix said: Hm the above post links to itself :P

Nah, it’s linking to a blog post… which I can see. So I wonder if it just hasn’t been officially “published” yet or something if others are having problems seeing it.

For us, it just links back to this thread, thus like a page refresh almost, except that instead of beginning with /forum/topic/ the URL begins with the date, but instantly redirects to here.

EDIT: BTW, CAN SOMEBODY EXPLAIN TO ME WHAT THE F*** IS GOING ON WITH THE WORDPRESS THEME? Thank you.

Looks like the post wasn’t published but was made public. Should work now, please try again.

Yep that works alright now. Thx

Very interesting Rémy! Keep it up! :smiley: +1’ed because this is awesome.

@.Ben. said: EDIT: BTW, CAN SOMEBODY EXPLAIN TO ME WHAT THE F*** IS GOING ON WITH THE WORDPRESS THEME? Thank you.

We’d be glad to put the theme back but everyone was complaining about 5 minute load times. Apparently it’s one or the other.

What? But why? It’s just a theme, I mean, could anybody please just profile the god damn PHP script and get rid of the stupid MYSQL query that takes 3 seconds to load? Put a LIMIT clause or create some index in phpMyAdmin. For god’s sake, WTF?

@.Ben. said: What? But why? It's just a theme, I mean, could anybody please just profile the god damn PHP script and get rid of the stupid MYSQL query that takes 3 seconds to load? Put a LIMIT clause or create some index in phpMyAdmin. For god's sake, WTF?

If it was that easy to fix it would be solved long time ago…

See my comments in this thread http://hub.jmonkeyengine.org/forum/topic/website-in-flux/ for further details.

Very nice - I was always wondering about singlepass implementation being only half there.

Regarding disadvantages versus deferred (for reasonable amount of lights) - I would probably list:

  • more complicated custom shaders for objects as they all need to implement this logic to be efficient
  • tricky to implement decals reacting to light
  • shadowcasting lights are not going to be solved by that

Advantages other direction you have already listed :wink:

Mhh…ok…
Idk how this thread has been created, i accidentally published the post yesterday and unpublished it right away as it was still in draft mode…I guess the post is an automatic thing.
Well…anyway, it done now, so feel free to comment or ask questions here.
And please keep the wordpress theme discussion out of here.

@abies said: Very nice - I was always wondering about singlepass implementation being only half there.

Regarding disadvantages versus deferred (for reasonable amount of lights) - I would probably list:

  • more complicated custom shaders for objects as they all need to implement this logic to be efficient
  • tricky to implement decals reacting to light
  • shadowcasting lights are not going to be solved by that

Advantages other direction you have already listed :wink:


Thanks.

  1. Yes custom shaders, I’ll write a in depth doc to explain how light data is sent to the shader.
  2. not sure why decals would be an issue with this.
  3. I’d like to resolve this, but yeah it’s not completely related. Resolving shadows in the lighting pass potentially requires to send a big amount of data to the shader. (for each light 1 to 6 texture and 1 to 6 transform matrix). I’d like to try to use Uniform buffers, but that’s opengl 3.1 min.

Great result! Guys you rock!

@nehon could you make a test scene with more polygons? Cube is not good for testing. Could you test Spheres with 300 triangles each instead of Cubes?
We need to make a good StressTest for these lighting features.

Nice, singlepass performance looks quite good. Wonder why in the second screenshot the performance decreased? It doesnt look like there where more lit pixels on the screen.
Also since now there is build ability to get a list of all lights adding deferred lighting might be more easy in the future. Going to take a look at the sources when i have time…

Good work, and a very good idea to improve the lighting system.

A bit OT, but from what i know the lighting methods are imported during the shader loading, do you think it would be possible to select the injectable code? Like when it comes to lighting, it would be cool to owerwrite the glsl lib reference somehow. (Changing lighting mode from phong to gaussian for example for all shaders loading the “LightCalculations.glslib”) Just a random tough i had. Maybe a simple assetmanager hack could to the trick already…

@mifth said: Great result! Guys you rock!

@nehon could you make a test scene with more polygons? Cube is not good for testing. Could you test Spheres with 300 triangles each instead of Cubes?
We need to make a good StressTest for these lighting features.


it’s actually a good test case. I wanted to test the impact of draw calls, so having low poly mesh is fine. Also, the new shader does light calculation in the frag shader, meaning it’s now done for each pixel instead of for each vertex. So this test case is actually one of the worst case scenario for single pass, and even in that case it greatly outperforms multi pass.
But if you absolutely want to test it, the Test case in in the repo, replace the cubes with spheres and see what it does.

@zzuegg said: Nice, singlepass performance looks quite good. Wonder why in the second screenshot the performance decreased? It doesn't look like there where more lit pixels on the screen.
I was also surprised the first time, but there is actually a lot more pixels shaded yes :p.
@zzuegg said: A bit OT, but from what i know the lighting methods are imported during the shader loading, do you think it would be possible to select the injectable code? Like when it comes to lighting, it would be cool to owerwrite the glsl lib reference somehow. (Changing lighting mode from phong to gaussian for example for all shaders loading the "LightCalculations.glslib") Just a random tough i had. Maybe a simple assetmanager hack could to the trick already...
This change is coming along a big clean up in our lighting shaders code, with refactoring of functions in glsllibs and deletion of some unused or barely used features (High quality, low quality, LATC, Mineart, etc...) I want to rewrite the shaders in Shader nodes, that's why I started by cleaning them up. With shader nodes it should be easy to switch the light calculation in the j3md. However, idk if a global way to change it would make sense...

O.o wonderful!
Put a kilt on that Scottish monkey… I can’t seem to get under v-sync 59 fps whatever I do, however badly I do it :D.

I would test it. But i have 3.0. And i can’t compile all this stuff.
Could you still make this test? As it will be faster for you. You have all this stuff.