I’m wondering if JME supports single pass lighting (not the entire process… just getting the list to the shader)?
There is a MultiPass technique in most (all?) materials. I’m wondering why this would be needed if SinglePass is not an option… thus the silly SinglePass question above.
Thanks!
Maybe this was the thread you meant?
http://hub.jmonkeyengine.org/forum/topic/gl_lightsource/
I don’t know if it actually resolves your current question, though.
For what it’s worth, I googled: “site:jmonkeyengine.org singlepass t0neg0d” and that was the first of three hits. Since the forum search is busted, the site: thing is a useful trick.
I never used it, and from what I’ve seen in the code it pass lights as an array to the shader…but the lighting shader never account for it so I guess it’s completely busted.
I know some monkeys made it work (@phr00t did I think) but I guess they had to modify the shader.
I’d like this thing gone in 3.1 and replaced by something functional…
The idea behind Issue 510 about lighting was to render only the geometries affected by lights (some sort of light culling). That would reduce the number of geometries rendered for naught in the multipass mode.
Also Kirill was thinking of having a mode rendering only the 8 lights that affects most a geom in one pass, and optionally have additional passes for the remaining lights.
The problem with sending all lights data into an array is that at some point you’ll run out of uniforms and varryings and it could fail depending on the hardware…
I wrote my own lighting shaders. As much as I love jMonkeyEngine for most things, the lighting system’s performance was completely unacceptable. I think it should be a high priority to redesign the lighting system, but I understand this is a free project people volunteer their time for & there are lots of competing priorities. I do believe there are very good single pass shaders available among these forums, and maybe they are even downloadable as a community plugin via the SDK(?), but it isn’t built-in to the jME3 engine. My shader is pretty 3089-specific and doesn’t have lots of general features like spotlights, so I don’t think they provide much general use.
Until recently, my game was using both Lighting.j3md and TerrainLighting.j3md. I recently replaced them both with a new material def for a splattable material with zero specular response. The change simplified my code and boosted my base fps from 209 to 231. It also resolved a problem I was having with TerrainLighting, namely that its ambient response was 5x weaker than those of other lit materials.
Lighting.j3md is an amazingly versatile material. I think its main weakness is that it tries to do too much. Having so many options makes it complex, difficult to maintain, and unnecessarily slow.
@sgold said: Until recently, my game was using both Lighting.j3md and TerrainLighting.j3md. I recently replaced them both with a new material def for a splattable material with zero specular response. The change simplified my code and boosted my base fps from 209 to 231. It also resolved a problem I was having with TerrainLighting, namely that its ambient response was 5x weaker than those of other lit materials.Lighting.j3md is an amazingly versatile material. I think its main weakness is that it tries to do too much. Having so many options makes it complex, difficult to maintain, and unnecessarily slow.
I haven’t looked recently (I also forked lighting for my own purposes some time back) but I remember getting similar improvement just yanking out the specular calculations. Everything else seems conditionally included based on defines. Which has been fine… except now I need specular in one material. :
Probably worth the 0.5 millisecond improvement you saw when you don’t need it, though.
Thanks for the input. I had put together a deferred rendering implementation a while back and was looking through it and couldn’t remember why I did what I did with managing lights.
It works… looks good enough… but I wanted to extend it to add a few things and was fairly confused as to why I would have put together a light manager system for handling something JME does already. Hmmm… think I will try a rewrite at some point and perhaps comment my code >.<
@sgold said: Lighting.j3md is an amazingly versatile material. I think its main weakness is that it tries to do too much. Having so many options makes it complex, difficult to maintain, and unnecessarily slow.that' pretty much sums up the situation yes. that's one of the reason shader nodes were added too... To be able to build a shader with only what you need... But here the porblem is more in how things are passed to the shader... So SinglePass passes al lights in formations to the shader once as an array MultiPass passes one light at a time and does nbLights passes
Only MultiPass is supported by the built in Lighting shader