Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: blackhole on December 23, 2009, 10:29:40 pm
-
Someone was trying to get per-pixel lighting for multiple lightsources on all models without making the FPS drop to nothing, and this is one way to do it:
http://www.infinity-universe.com/Infinity/index.php?option=com_content&task=view&id=105&Itemid=26
-
Cool...
Seen it before, but still cool.
-
Looks very nice :)
-
The problem about this article is that it describes deferred *shading*. Deferred *lightning* (aka light prepass) is also a technique that allows using many light sources, but it's implementation is often completely different.
The main disadvantage of deferred shading is large memory usage (many G-buffers which often stores not only information required to render lightning but also data needed by some post-processing effects), while deferred lightning needs to render geometry few times (it doesn't depends on the number of light sources, though) what may cause performance hit.
Deferred shading is now quite easy to implement since we already have all post-processing code (Actually, I'm still trying to resist the temptation to start experimenting with it :P ). Light prepass rendering needs a bit more work. However, it is a complete waste of time to implement it now, since the existing, old FSO code is not ready for such things. What has to be done first is to overhaul current rendering code in a way it will allow using various rendering techniques: multi-pass lightning and either deferred shading or deferred lighting (since, none of these two techniques seems to be much better than the other it may be a good idea to try using both of them before final decision will be made).
(I've also heard about light indexed deferred lightning but I'm not familiar with that technique yet.)
-
I'm sure the codebase needs work before any of this can be implemented, but once the code has been improved, its a place to start.
-
yeah, I saw that update before on Infinity, how's that project going? I don't usually go in the forums to check it out so.. I'm kinda stuck with the recent events posts.
-
The problem about this article is that it describes deferred *shading*. Deferred *lightning* (aka light prepass) is also a technique that allows using many light sources, but it's implementation is often completely different.
The main disadvantage of deferred shading is large memory usage (many G-buffers which often stores not only information required to render lightning but also data needed by some post-processing effects), while deferred lightning needs to render geometry few times (it doesn't depends on the number of light sources, though) what may cause performance hit.
Deferred shading is now quite easy to implement since we already have all post-processing code (Actually, I'm still trying to resist the temptation to start experimenting with it :P ). Light prepass rendering needs a bit more work. However, it is a complete waste of time to implement it now, since the existing, old FSO code is not ready for such things. What has to be done first is to overhaul current rendering code in a way it will allow using various rendering techniques: multi-pass lightning and either deferred shading or deferred lighting (since, none of these two techniques seems to be much better than the other it may be a good idea to try using both of them before final decision will be made).
(I've also heard about light indexed deferred lightning but I'm not familiar with that technique yet.)
With multipass lighting, how will this look compared to what we have now?
-
We currently use multilight approach. There is no general rule whether multilight or multipass approach results in better performance. However, it is much easier to manage and apply multiple light sources when using multipass rendering (however, it appears that the performance hit is bigger).
With multipass lighting there should be no limit in the number of light sources per object except from FPS and unfortunately, comparing to the deferred lightning/shading it is quite a strict limit.
Obviously, both mutlipass and multilight should be considered as "pure evil" when talking about deferred shading/lightning :P On the other hand there are many problems connected with either deferred shading or deferred lightning that don't exist when using forward rendering (for example: alpha blending, AA).
Ideally, FSO would implement all 4 (or 5 if light indexed deferred lightning will prove to be an interesting technique) methods of rendering and choose the best one according to the user's hardware capabilities. That may seem to be a waste of time to implement all of them but that will be the easiest way to decide which technique use. However, many things in the current code need to be overhauled before we will start thinking about it.
-
I would count a lot simpler scene management for one of the big wins for deferred appoach, due to less management of light of shaders.
As for alpha blending, most deferred engines do render transparencies in forward rendering pass after you do opaque stuff. (just like you would in a normal forward renderer)
Recently some limited amount of transparent stuff has also been rendered in same G-Buffer and handled just like everything else. (http://graphics.cs.uiuc.edu/~kircher/inferred/inferred_lighting_paper.pdf (http://graphics.cs.uiuc.edu/~kircher/inferred/inferred_lighting_paper.pdf))
For game like FS the normal forward rendering would be most likely the best option for lasers and explosions
Nebulas other hand are quite different case and could be done separately with almost any method imaginable, perhaps some interleaved deferred rendering, this would make it possible to have light and shadows there 'easily'.
-
Ooo, that gave me an idea (but I can't even benefit from it until I get a better computer)... volumetric shadows and/or simple 'god rays' in the nebula!
-
You can forget about getting anything like that running at decent speeds before the rendering engine has been rewritten
-
You can forget about getting anything like that running at decent speeds before the rendering engine has been rewritten
A robot can dream, though... a robot can dream.
-
Ooo, that gave me an idea (but I can't even benefit from it until I get a better computer)... volumetric shadows and/or simple 'god rays' in the nebula!
Well, I think Hery has at least added god rays to the sun already. :)
-
I published only one screenshot with that effect. It required more work to fully implement it, but yes, it is quite straightforward to implement god rays as a post-processing effect.
Actually that build assumed that the sun is always in the centre of the screen and there were some other artifacts caused by poor radial blur algorithm. When I have enough free time, I will implement it again, and this time fully and properly :D (In fact, that implementation was done because I accidentally came across Crytek's presentation that described how to easily write such a thing and I was amazed by simplicity of this method.)
Unfortunately I lost that screenshot and I doubt if anyone still has it.
-
Was it a Stratcomm's Hyperion with those strange "light streaks"?
-
Was it a Stratcomm's Hyperion with those strange "light streaks"?
You mean the things at the back of the engine glows?
-
Unfortunately I lost that screenshot and I doubt if anyone still has it.
(http://img4.imageshack.us/img4/7379/screen0053.jpg)
-
Yes, it's this one.
-
I published only one screenshot with that effect. It required more work to fully implement it, but yes, it is quite straightforward to implement god rays as a post-processing effect.
Actually that build assumed that the sun is always in the centre of the screen and there were some other artifacts caused by poor radial blur algorithm. When I have enough free time, I will implement it again, and this time fully and properly :D (In fact, that implementation was done because I accidentally came across Crytek's presentation that described how to easily write such a thing and I was amazed by simplicity of this method.)
Unfortunately I lost that screenshot and I doubt if anyone still has it.
It's nice and fast method for the effect, but if it were to be used on nebula, it might be good to try to use color buffer for the sampling as well.
This way you might get the puffs to have shadows as well.
IMHO, the rewrite of nebula rendering as proper volumetrics might be the best solution in long run, currently it seems to be a bit of a mess.
That way a proper volumetric shadows and lighting would be easier to implement and results might be incredible.
-
Pottuvoi: There's a _lot_ (as in, seriously a lot) of internal discussion going on about the renderer at the moment :)
We'll stick it in the ideas pile :)