Deferred Rendering (Lighting)2

Continuing the discussion from Deferred Rendering (Lighting):
Continue with this topic, I think delay pipeline is necessary for mainstream engines, so will this aspect be improved in the future :face_with_monocle:

I don’t know much about lighting, and I don’t know the history of this feature in JME, but I found a file that may be relevant:

JME v3.1 had a material definition named ā€œDeferred.j3mdā€:
jmonkeyengine/Deferred.j3md at v3.1 Ā· jMonkeyEngine/jmonkeyengine Ā· GitHub

Issue 1361 may also be relevant.

1 Like

I guess there had been some attempts on this

2 Likes

As far i remember: it is not possible to make such deep changes as drop in replacement. at the very least you have to replace all materials used.

i think all gbuffer techniques implemented in jme where loosing the ability to have single object lighted.

I have not implemented shadowing.

More advanced game specific rendering techniques have the need for additional gbuffer data. also in such cases a common library is harder to design.

As far i remember getting a simple deferred lighting system to work was fairly simple without any core modifications.

There are at least 3 completely different pipeline approaches each with pros and cons.

In my technique it was not possible to use per object light equations. in a pbr env. probably not a big problem.

transparency is still a issue, eighter you still use forward rendering on those or you would have to implemet more complicated techniques.

all in all i it was simple to add the required features for my special need easily and i have by far not the knowledge on how to implement a general purpose solution

the thread regaring yadef:Yadef, Yet Another DEFerred renderer

  1. time flies
5 Likes

Thanks for the tip, but it seems that this shader has not completed the integration of delayed rendering in jme3. :slightly_smiling_face:

Thank you for your valuable experience. I will try your delayed rendering technique.

Thanks for the tip, I will try these two delayed rendering techniques. :grinning:

my lib was written against 3.0.0 of jme i think. i guess there where a few braking changes.

My technique also uses very! large uniform arrays without checking if the gpu actually supports such a big size. hardcoded if my brain does not trick me.

it does also not support post processing i think. it was a proof of concept nothing more. you might can use it as starting point. however i strogly advice against usage in an actual project. no failsaves no checks no documentation. only the fun part

Thank you, I use it as a reference case. In fact, I think the future version of jme3 should provide a shader script, just like fx script in Dx3d, because advanced shading is multi-pass, I don’t know how you think about this idea. :grinning:

never heard of fx script

:joy:Like u3d, a material shading script (pass1 shading to pass2 shading, then to pass3 shading). I know I can use SceneProcess to write java code to achieve multi-pass coloring, but I hope jme3 will provide similar material script definitions in the future.