I’m currently experimenting a bit with my LD post-mortem: B07s. I tried to integrate some PointLights but I noticed significant performance drops when adding around 100 lights. I know that sounds like a lot but the radius of them is limited to 2. I figured that the problem might be the one big mesh I create for the whole level. So I split the level into smaller meshes so that when one geometry is outside the radius of a light the light calculation could be pruned - but without any success.
Is there any pruning from the jME regarding light calculations? Or are they all just added to one array and passed to the shader? Can I improve performance somehow without the need to calculate light maps?
Do not limit radius attach them only to object that you want to be lit.
JMe uses forward rendering, all potential (from the scenegraph point of view not radius) affected meshes are renderd for each light once. So you render all your level 100times for one frame.
see issue 510
for now the workaround would be what @EmpirePhoenix suggests or/and baking lights into textures for static lights.
@EmpirePhoenix said:
Do not limit radius attach them only to object that you want to be lit.
JMe uses forward rendering, all potential (from the scenegraph point of view not radius) affected meshes are renderd for each light once. So you render all your level 100times for one frame.
I'm a bit on the lighting-illiterate side. How does one limit the geometries effected by a light? node.addLight() for each geom you want effected? And... because I am lazy and don't want to go look this up right now... oh, and you might know already... does this add the geometry/node/spatial to some sort of render queue bucket for the light? Or duplicate the light for each spatial it's added to?
A light added to a node lights all geometries attached to its subgraph.
By partitioning your scene and place your lights wisely you can gain a lot of render speed.
@nehon said:
see issue 510
for now the workaround would be what @EmpirePhoenix suggests or/and baking lights into textures for static lights.
Read the issue... don't see a problem with the solution... why hasn't the code magically appeared? :) I pushed my "Make code magically appear" button... it seems to be broke.
@nehon said:
A light added to a node lights all geometries attached to its subgraph.
By partitioning your scene and place your lights wisely you can gain a lot of render speed.
When I planned the breakdown for the scene graph of my game, I wasn't completely aware of the lighting issues. But, thankfully... I am only using 1 ambient, 1 directional and (though, I may remove this after reading the issue you posted... temporarily anyways) 1 point light for torch light effect.
The reason I may remove it and find and alternate way of "brightening" the areas closest to the player, is it needs to effect most everything in the scene.
I think I may add the effect to one of the post filters that has a depth buffer to work with... though, this will follow the camera, not the player model... it's an alternative for now.
@t0neg0d said:
When I planned the breakdown for the scene graph of my game, I wasn't completely aware of the lighting issues. But, thankfully... I am only using 1 ambient, 1 directional and (though, I may remove this after reading the issue you posted... temporarily anyways) 1 point light for torch light effect.
The reason I may remove it and find and alternate way of "brightening" the areas closest to the player, is it needs to effect most everything in the scene.
I think I may add the effect to one of the post filters that has a depth buffer to work with... though, this will follow the camera, not the player model... it's an alternative for now.
For one point light, you could also build it into your shaders. Mythruna kind of does a weird lighting trick similar to this and essentially has only two lights, all handled in one pass.
You could also do a material where you pass like the 10 light positions nearest in, and use that to render 10 lights per pass. this will give you up to a 10x boost.
(Or you wait untill the deferred renderer is done somewhere in the future and just use less lights untill then)
@EmpirePhoenix said:
You could also do a material where you pass like the 10 light positions nearest in, and use that to render 10 lights per pass. this will give you up to a 10x boost.
(Or you wait untill the deferred renderer is done somewhere in the future and just use less lights untill then)
I was reading somewhere that deferred lighting is a great solution as long as your targeting new hardware exclusively, but that it has significant issues with older hardware (i.e. not a good idea in these cases). I've been focused on making sure the game I am working on is able to render all effects on efficiently on the shittiest hardware I can test against. So far, so good. Will deferred lighting in JME have the issues I read about?
@t0neg0d said:
Will deferred lighting in JME have the issues I read about?
Yes of course...more even...i'm pretty sure we can do it... ;)
@nehon said:
Yes of course...more even...i'm pretty sure we can do it... ;)
hah... I'm anxious to try it out.... even if you DO add in "extra" issues ;)
@EmpirePhoenix said:
Do not limit radius attach them only to object that you want to be lit.
JMe uses forward rendering, all potential (from the scenegraph point of view not radius) affected meshes are renderd for each light once. So you render all your level 100times for one frame.
That's what I basically did. The scenegraph should look like this:
rootnode
| ... |
node1 ... nodeN
|
Light1 Geometry1
But still no improvement ... but maybe I did something wrong in the scenegraph building - I will check on that again. At least I know now how the lighting works in theory ;)