@abies, AFAIK that is the model Unity use, it is often referred to as Light Indexed Deferred rendering, and it is better for keeping material variety. The main issue is that you have to render the geometries twice which is expensive, and the amount of shader magic you can do in the second pass is not that great either, you still got just the a diffuse color and a monochromatic specular component which makes it even harder to motivate. The implementations I have done (and others aswell) shows that deferred shading is in many cases faster then LID.
That is why I went with just plain old deferred shading.
The new cool kid on the block is Tile Based Deferred Rendering, but that needs some OpenCL magic in order to pull off =P
@vinexgames, nope there is no specular map at the moment. Adding that should be rather straight forward though. The main thing to consider is how channels you wanna allocate for specularity in the GBuffer. There is plenty of fun and handy variables one might store in the GBuffer but there is only so much room =)
<cite>@kwando said:</cite>
@abies, AFAIK that is the model Unity use, it is often referred to as Light Indexed Deferred rendering, and it is better for keeping material variety. The main issue is that you have to render the geometries twice which is expensive, and the amount of shader magic you can do in the second pass is not that great either, you still got just the a diffuse color and a monochromatic specular component which makes it even harder to motivate.
Quite possible - I’m doing throwing purely theoretical stuff here, don’t have any real world experience with that. I was reading http://www.realtimerendering.com/blog/deferred-lighting-approaches/
and followed through to Crysis3 whitepaper and got the impression it could be a lot easier to port existing shaders to it, rather then putting them in front of light processing - but as you said, there might be not THAT much to gain there.
@abies, I think it depends on case by case basis which approach is the best. One should not forget that plain old forward shading is still viable for the majority of cases =)
@kwando Question. I’m testing the DeferredSceneProcessor with my world loading system and I’m having trouble removing lights from the scene. Is there anything I need to know about that?
@vinexgames: Yeah, that is not surprising. =P It has not been tested and the whole light handling inside jME is a mess and subject to change… Feel free to poke around, and send a pull request with your patch =)
@kwando this project isn’t necessarily important, it’s just something random I work on in my spare time. I’ll see what I can do with the light removal problems.
@kwando How do I submit a patch? I fixed the light removal error. The problem was that the GeometryList couldn’t be cleared without removing every light, so I slightly modified the code in DeferredSceneProcessor to use an ArrayList to contain the geometries and create a GeometryList temporarily for the postFrame method.
@vinexgames, if you have experience with git / github I would like a pullrequest. Otherwise give me a git patch/diff that will apply cleanly on the dev branch.