I’d like to add some dynamic lighting to Gentrieve 2, but I’m a bit confused on possible performance implications. When I was starting with 3079, I wanted to include some dynamic lighting, but quickly hit a performance brick wall with just a few point light sources. It was explained to me that a scene needs to be re-rendered for every light…
How does say, a game like Descent 3, do their lighting then?
This game is over 10 years old and has tons of light sources (e.g. one for each projectile in the air) and it ran plenty smooth on this old hardware. Is this done very differently from jMonkeyEngine lighting? I presume I will need to write my own shader to try and get this type of performance...?
@phr00t said:
Yes, if you dig through the forums for custom written solutions. I, personally, am all set with using these custom shaders. However, many developers, especially new ones, are not going to do this and simply give up when they see the default lighting system's performance so poor. This is why my advice was to do something different: use the better solutions as the default solutions.
Exactly, for you "lighting system == point lights" and you only tell us to do our stuff different, thanks.
For why it wont work for older systems, many are not able to do hardware if else, but do both and dispose the unwanted results.
Also the current lighting system is very powerful when using scene partitioning correctly, as every object is mostly only lit by one or two lights. (And for special stuff you need a own shader anyway). Of course deferred lighting is a great way to increase performance and so quite much, for highend systems.
@phr00t said:
I'm surprised on how poor the built-in lighting system is.. [..] I think survivor's lighting should just replace the current default system, which is just way too slow.
@phr00t said:
I really suggest you guys look into replacing the current lighting system with something like survivor's as soon as possible.
[..]
However, you have to admit, the current entire lighting system is practically unusable at this point
@phr00t said: We can always add John Carmack's method or Momoko_Fan's method later
... see the discrepancy? Until now you haven't contributed a single line of code to the engine, why would I expect you to do that now? At the same time you always put out a very demanding attitude towards issues you run into even if the problem is in your own code. You only posted code after I posted the lol and I stand by that lol still.
Are you guys really thumbing us down for trying to give constructive feedback and are you phr00t really starting to attack the work while your own status of knowledge is "I read some article about deferred shading" (which you underline by not acknowledging that lighting isn't just about point lights)? You put out an attitude as if we were dismissing the issue while in fact you dismiss our feedback.
I did some single pass stuff for Forester too. The only thing I changed was the single pass lighting routine in Material.java, because ambient lights slipped into the light list and ruined it. There was no need to patch because Material.java could just be extended and override the single pass lighting method.
The single pass mats use the default jME LightMode SinglePass, and the default Material.java (except for a small tweak in the single pass lighting method), so there’s nothing outlandish about them. An integer to keep track of the number of lights, that’s it.
I myself was reluctant to suggest a patch before running the materials for a few weeks/months to test, but people has been using Survivor’s system for some time now (a similar but much more robust system), and it seems to work without complications. It supports many lights etc.
Survivor’s lighting system is far more flexible than mine, and it was designed to work within the current framework of jMonkeyEngine’s lighting. It makes sense to use that code to base a possible jMonkeyEngine’s replacement lighting system instead of mine. I’m only using point lights in my code because I only need to use point lights at this time. This doesn’t mean I don’t acknowledge the need for directional and spotlights elsewhere.
Submitting code to the repository isn’t the only way to help jMonkeyEngine out. At least someone else found me helpful enough to give me a “Contributor” tag.
I posted code because I thought the code was at a good point to share, and because Momoko_Fan brought up compatibility concerns.
Saying “lol” to my implication of multiple people willing to help out isn’t constructive feedback. It is useless bickering, something we are continuing to do here.
if( normal < 0.3 ) normal = 0.3;
I did this because I just liked the results a bit better... it made sides that were close to lights, but facing away, just a tad lit. It can be simply removed if you prefer. :)
This is really not worth the effort, I agree. You keep twisting the words I say. Anyway I got a “reply to bullshit arguments” disorder.
@phr00t said:
Submitting code to the repository isn't the only way to help jMonkeyEngine out.
No but you were the one suggesting code changes and then talking about "we". Feedback and support is much appreciated, "you should really do it different" advices not.
@phr00t said:
Saying "lol" to my implication of multiple people willing to help out isn't constructive feedback. It is useless bickering, something we are continuing to do here.
Conveniently for you I said lol, inconveniently the dismissal from your side and the feedback from our side I am talking about happened before that and the lol references that. Really skillful twisting I have to say, respect.
In plain words: You would help the engine more if you worked on implementing the optimization techniques momoko was talking about. As you all see the solutions you suggest are already implemented and usable.
As you all see the solutions you suggest are already implemented and usable.
Yes, if you dig through the forums for custom written solutions. I, personally, am all set with using these custom shaders. However, many developers, especially new ones, are not going to do this and simply give up when they see the default lighting system's performance so poor. This is why my advice was to do something different: use the better solutions as the default solutions.
Exactly, for you “lighting system == point lights” and you only tell us to do our stuff different, thanks.
I'm talking about single-pass lighting instead of multi-pass lighting, not just only using point lights. This is why I have been recommending Survivor's system as code to work from, since it is single-pass, has support for more types of lighting features & is designed around the current jMonkeyEngine lighting framework. I've stated before that my custom shader is just a stripped-down version of Survivor's, because I only need point lights right now. This doesn't mean I believe all lighting systems should only use point lights. Anyway, this bickering is getting a bit silly and I've got coding to do -- I suggest we both go do something productive instead. :)
Hrm… for per-vertex shading, I’d need a decent number of vertexes packed together to make the lighting look decent? Right now, my floor is just one big stretched box, since I wanted to reduce vertex count in relation to 3079…
Yep, you would need to add more vertices to large flat items if you wanted it to look decent. You may well also find that the descent engine is only applying each light to a small area around itself - which is something you could also do in JME3 (I believe - it’s not something I’ve tried) by attaching the light to a node.
That DeferredRendering really does look impressive though.
So for example you could put one room inside a node and then have a light inside that room and the light is only calculated for the objects inside that room.
Majority of the lighting in that video is pre baked is it not? There is one, perhaps 2 point lights max? that’s it as far as I can see… That’s nothing.
I do all my effects lighting like gun shots and magic effects with a single point light moved around each frame. This is also very scalable, moving 3 or 4 point lights around can look better, but performance is slower.
I wasn’t referring to the static lighting along the walls – I was and am referring to the dynamic lights caused by explosions & projectiles. You could fire a long array of projectiles, and they would all light up the walls as they flew through the air.
Basically, you calculate a fixed number of lights in the shader (say, 16) by iterating over them in the frag shader. In my Java code, I’ll recycle the possible 16 lights and position / change them as needed… see how it goes. I just want point lights with no fancy specular colors, so I’m hoping it will be pretty straight forward and quick.
If this fails, then I’ll move on to vertex lighting. I didn’t plan for increasing the vertex count to make vertex lighting easy to implement…
The Descent guys were masters of smoke and mirrors. They did some incredible stuff this way. Descent 1 (and maybe 2) didn’t even have perspective correct textures. They used affine transformation but because of the way their levels were constructed, you’d never notice.
Given the way their levels are constructed to maximize the use of PVS, my guess is that they just made sure their geometry was well broken up and then used vertex lighting as others have suggested. I also detected hints that the effect was more pronounced where geometry is more detailed which would add further evidence. This was very popular at one time and even the earlier Jedi Knight games, etc. used it.
I read an article about how Doom3 did lighting… They had 12 lights in some scenes. If you make proper use of scene partitioning, depth prepass, and scissor test on the individual lights you can probably gain a lot more speed. jME3 isn’t designed to handle many lights at the moment… In your case I strongly recommend baking since you have indoor scenes where the lighting setup doesn’t change.