Forward+ Render Pipeline

I stumbled over this interesting lighting method called “Forward+” while researching deferred rendering. It supposedly maintains all the advantages of traditional forward rendering has over deferred rendering (such as transparency) while still being able to handle thousands of lights at once.

In a nutshell, it splits the screen into 16x16 tiles (in pixels), and uses a compute shader to calculate which lights contribute to which tiles (one work group per tile, one thread per pixel per tile). The contributing lights’ indices are stored by tile in global gpu memory. The fragment shader then looks up which lights to use for the current pixel for lighting calculations.

Since this technique is essentially an extension of forward rendering, I don’t think this will be nearly as difficult to integrate into Jme as deferred rendering. I would like to begin work on this myself since I’m the one bringing this up, but I am too unfamiliar with Jme’s rendering process to even know where to start.

Any thoughts?

5 Likes

The main issue with all the rendering tech integrations is that there is no clean entry point in jme. Mainly Viewport or RenderManager and the shaders of course.

That does not change much between deferred or forward+ or forward++.

Usually in forward plus you make a depth only prepass, with selected geometries to allow light culling. The ++ variant uses a 3d grid for storing the light data while as you mentioned the + variant uses a 2d data structure.

One of the things you need access to is to replace the filling of the renderqueues since it is optimised for forward rendering and the per spatial lighting is not supported by any of the modern techs.

JohnKkkk implemented forward+ for jme already so the shader code is already available.

Add: One of the build in special cases is the waterfilter and the pbr env probe. Those have to be taken into account.

1 Like