Hello,
Is there a roadmap of any sort for deferred rendering/lighting?
I see that in TestMultiRenderTarget there is some kind of G-Buffer set up, and there is also a Deferred.j3md definition. However, the test is only outputting a blank screen, so I am thinking that deferred is not fully implemented.
I ask because the project I am working on would really benefit from being able to put lots of spot lights in the scene. (awesome new addition btw :)) It’s a kind of architectural project so there are lots of lights pointing upwards and need to be dynamically placed and even moved around.
1 Like
Deffered rendering is a WIP right now in jme3, I think it’s even broken.
We decided this wouldn’t be a 3.0 feature, and focus first on the forward rendering.
But this could be one of the feature of the 3.1, but there isn’t any road map for this atm.
Bummer.
Thanks for the info!
Very low priority right now with all the other stuff that’s happening.
Who is implementing this deferred lighting? I might help with that… I really like the concept of deferred rendering (lighting) (that’s what the cool kids use nowadays). Who is “in charge” for the JME implementation?
I guess no one is actually working on it right now, as Momoko_Fan said its low priority.
I was reading the theory the other day from here http://www.gamedev.net/page/resources/_/technical/graphics-programming-and-theory/deferred-rendering-demystified-r2746
I would really love to work on it, but other then the theory I don’t have any high profile understanding of jME material & rendering system, which seems like mandatory for this kinda task. 
Maybe we can talk, but I dunno how much of help I’ll be at it. 
hey guys, I have already started to implement deferred rendering for my project.
The basic idea is to create a new material and assign it to all of the objects that you want to be handled by the deferred process. In that material you will be outputting the g-buffer (normals, depth, color, anything else you want).
Next you want to render all of the lights into a light buffer (point, spot, etc). To do this, I subclassed the rendermanager and manually draw in all the lights after the opaque pass (I haven’t implement the transparency part yet). Basically I add lights to the rendermanager with a function (not adding them to JME’s system) and each light has a special material which outputs to the light render target. For my purposes, I actually added the light render target to the G-Buffer.
Finally, you can use a Filter to combine all of the elements of the G-Buffer and Light buffer however you please. For my usage, I actually render everything (geometry, lights) in a pre viewport, and then render the main viewport (which has no geometry or anything) with the Filter applied.
I would share the code here but it’s really not ready for prime time at all as I’ve made some assumptions about its usage. Plus, it’s kind of tacked on to JME and not really integrated. When I get it to a more usable state I’ll share it here if you’d like
@iamcreasy I’m having half of a solution already implemented. Just wondered how far away this is, unnecessary to reinvent it if it’s already in the pipe. After all I would rather like to use a built in pipeline.
I’ve also read most of the material I’ve found on deferred shading, found this article yesterday:
http://www.beyond3d.com/content/articles/19/1
The internals of JME is not that hard, I’ve read through the rendering core and material system and I think I got a fairly good understanding of what I’m doing.
@bigstink nice! I’ve done some work in another framework where I’ve implemented parts of a deferred pipeline (Spotlights and shadow maps) but I’m still thinking about the best way to do it in JME. I’ve got a basic G-Buffer material running and rendering to several render targets. I’m also modeling my point lights as spheres and spotlights as cones, bypassing JME-s built in multi pass lightning. It would be nice to be able to use the builtin lights in some way (going to need them when doing transparent stuff) and I don’t like the idea of maintaining two lighting systems in my code.
I’ve seen references adhering to deferred shading around in the source, GBuf technique and so on… and there seems to be an attempt to do some deferred stuff inside TestMultiRenderTarget (I can’t get it to run, but it might not be ready to run either).
Hmm, I’d like jME3 to implement Inferred Lighting. A variation (enabling shadows) is used in the frostbite 2 engine of dice afaik.
Please feel free to check out this directory and others which is a collection of graphics stuff:
http://www.wuala.com/Graphics%20Programming/Realtime/Lighting/Inferred%20Lighting
This chick has a really inspiring attitude about game development.
This chick has a really inspiring attitude about game development
Not really if you think a bitfurther
@kwando said:
Who is implementing this deferred lighting? I might help with that.. I really like the concept of deferred rendering (lighting) (that's what the cool kids use nowadays). Who is "in charge" for the JME implementation?
I guess it's gonna be Momoko_Fan or me, but most likely Momoko_Fan as he is a bit picky about core features :D
But guys, this is not getting to the core before 3.0 release.