Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: blackhole on January 06, 2008, 11:36:05 pm
-
While messing around with motion blur, I stumbled on a technique for a realtime bloom shader. This shader takes a single texture as input, nothing else - this texture should be the entire rendered scene, minus the GUI (standard post processing procedure, make sure the texture does not wrap its UV coordinates). The shader has 4 passes, 2 parameters (fblur/fextend) and was written in HLSL, but since its purely picture modification should be easy to port to GLSL.
Because this shader only needs a single frame of information, I was able to insert screenshots and process them to give an accurate depiction of what they would look like in-game. This bloom technique was invented on my own and built without the use of tutorials; however, its entirely possibly that something similar has been done elsewhere. You will notice that the shader does not bloom excessively - only something that is really bright is bloomed, everything else is left alone. The following screenshots were taken with an fblur value of 3.0, and an fextend value of 0.007.
Original pic (Massive explosion situation):
(http://img106.imageshack.us/img106/9660/6p9hegkdd4.th.jpg) (http://img106.imageshack.us/img106/9660/6p9hegkdd4.jpg)
Bloom applied:
(http://img177.imageshack.us/img177/8633/firstpiciy7.th.png) (http://img177.imageshack.us/img177/8633/firstpiciy7.png)
Original pic (Subspace warpin situation):
(http://img106.imageshack.us/img106/2295/psamtikjumpinginmq6.th.jpg) (http://img106.imageshack.us/img106/2295/psamtikjumpinginmq6.jpg)
Bloom applied:
(http://img106.imageshack.us/img106/6947/secondpichn3.th.png) (http://img106.imageshack.us/img106/6947/secondpichn3.png)
Original pic (Dark situation):
(http://img106.imageshack.us/img106/3792/86ruumdar6.th.jpg) (http://img106.imageshack.us/img106/3792/86ruumdar6.jpg)
Bloom applied:
(http://img516.imageshack.us/img516/1926/thirdpicpn4.th.png) (http://img516.imageshack.us/img516/1926/thirdpicpn4.png)
Original pic (Beam and engine glow situation):
(http://img516.imageshack.us/img516/2352/fsftk2.th.jpg) (http://img516.imageshack.us/img516/2352/fsftk2.jpg)
Bloom applied:
(http://img516.imageshack.us/img516/2963/fourthpiczf4.th.png) (http://img516.imageshack.us/img516/2963/fourthpiczf4.png)
Now, please, get postprocessing working before VasudanAdmiral's head explodes! Once you get postprocessing implemented I'll convert the whole thing to GLSL and let you guys screw with it however you want.
EDIT: I added two more parameters - bloom subtraction and final subtraction. Bloom subtraction lets you adjust the power of the bloom, and final subtraction is for general lightness correction. These parameters are set to 0 for the purpose of the above screenshots.
-
Does bloom take care of the problem when a large capship is hit by missiles, and the billboarded texture intersects with the hull? (So you see the explosion plane get cut off as it goes 'inside' the hull)
-
It would probably help to hide the problem, send me a screenie so we can find out :P
-
It would probably help to hide the problem, send me a screenie so we can find out :P
Note the missile impacts on the right side of the screen:
[attachment deleted by ninja]
-
If you want it to be more then 2% accurate, could you upload a PNG or otherwise lossless screenshot? Bloom really doesn't like artifacts.
-
Apparently the 216 KB PNG fills the upload folder :p
The source is the BtRL video, so I can't get a lossless version of the same screenshot. It's not a big deal anyway, I'm just curious.
-
All it seems to do, at least with that pic, is make the ship look kickass :P
(http://img341.imageshack.us/img341/8761/badexplosionsbloompn2.th.png) (http://img341.imageshack.us/img341/8761/badexplosionsbloompn2.png)
-
This could be really cool.
In moderate amounts.
A bit less than the screenshots.
Like, a lot less.
Still, great job. I'd like to be able to use it (whenever possible).
-
I'd make both values adjustable in the launcher via commandline.
Yes, postprocessing will improve the graphics even more.
I like that it doesn't simply bloom everything.
Blooming would slightly help a bit with our praticle->hull->intersection problem. At least bright particles would cover the ugly seam a little bit.
-
Yes, this could greatly improve the look of the game if used correctly. It's good to see that it does not affect the backgrounds, unlike that old ATI bloom shader (this is why I never use it much even though my card supports it).
-
i'd prefer to hold out on simple bloom until we get full on HDR-controlled bloom. i've always found it to look much cleaner.
unless of course that's what this is...
-
:eek2: holly...
First normal mapping and now blooming? How do you all think up the code for all this? There is no way you just wake up one morning and suddenly say, "I think I'll just add bloom effects to FSO" Do you all work for game companies and thus know all the latest secrets? I mean, really, this is all just amazing.
That battlestar was impressive to begin with. Now it would rival any official game that would ever come out. You guys should be more careful. Heck, your rivaling the CG in the miniseries/tv-show.
-
thats just stunning great lookin!!
like darklord said... you are heros, doing this in your spare-time :D
-
First normal mapping and now blooming? How do you all think up the code for all this?
Not having shaders was a big barrier to what we could do graphics wise. From the sound of it the materials system is the other big barrier.
-
i'd prefer to hold out on simple bloom until we get full on HDR-controlled bloom. i've always found it to look much cleaner.
HDR controlled bloom is always better, but that involves implementing an HDR pipeline, which is not easy. My bloom is using what I call fake HDR, which is when I basically take the scene and screenblend the whole thing on to itself to create the HDR. The actual bloom shader uses traditional HDR techniques (only blooming values above 1.0f). When I implement this shader into my 2D graphics engine I'll be using an HDR buffer to control it, sending it an HDR texture, and simply removing my fake HDR. The same could apply for FSO.
I'd make both values adjustable in the launcher via commandline.
Now there's four, and possibly more values, to adjust the intensity, falloff and any other variables I can throw in without going over the 64 instructions limit :P
A bit less than the screenshots.
The shader is fully customizable so that the bloom amounts can be adjusted to just the right amount. That, however, is up to you guys :D
There is no way you just wake up one morning and suddenly say, "I think I'll just add bloom effects to FSO"
Actually it was 2:25 PM in the afternoon, and I said "I think I'll code a bloom shader." :p Its really not that hard, you just need to have the proper technique 'n all.
-
falloff and any other variables I can throw in without going over the 64 instructions limit :P
Oh, instruction limit? Where does that come from?
-
All shaders of pixel shader 2.0 have an instruction limit of 72 and an arithmatic operator limit of 64 (or something like that) per pass. Pixel shader 3.0 raises this limit, but its still there. I usually prefer to write shaders in pixel shader 2.0 for compatability reasons. Besides, if you've got more then 64 operators, thats a seriously GPU heavy shader.
-
well apparently the shaders only work on SM3.0 cards and up, so if it's heavy, the cards that would be running it could probably handle it.
Real HDR is something i'd really like to see
-
Very nice, but a little over-done in the screenies. HDR is nice, but like gaming, too much is a bad thing (unless it's FSO :nod:)
-
I'd like to see some HDR myself, but that would involve recoding the entire rendering pipeline to handle HDR. Not fun.
And its not HDR, its BLOOM. Yes, too much bloom is a bad thing, which is why my bloom shader doesn't bloom everything. :P
-
Ah, forgive me, I'm not well-versed in HDR. But true, there is perhaps a little too much bloom in those screenies...
-
I find it quite tasteful....but it may need to be dialed back a bit. But thats not really the point at all. The fact that it can be done and looks like without too much trouble once all of the other pieces fall into place means this will be a really nice eye candy effect that we can all configure to our hearts content!
-
Don't get me wrong, it's great that it can be done, and it is "quite tasteful," but too much of a good thing ...
-
THE SHADER CAN BE ADJUSTED
Ok? ok. :D
-
I really do like the amount of white bloom on the ship exiting subspace, however. It really gives an awesome feel of it coming out of subspace.
-
K, is this on a 1207 exe with an external shader? Or a completely re-coded exe?
If it's just an external shader on a robinson XT, could I play with it? Please? :-)
How well does it react to high AA/AF values being applied (with or without Edge Gamma Transparency, etc.)?
-
Its an external shader but its currently reliant on rendermonkey's IDE, as i haven't made it independent yet or loadable. Sorry :P
-
THE SHADER CAN BE ADJUSTED
Ok? ok. :D
Ok.
-
i also would appreciate this bloom-effect. it makes everything much smoother and i think, more realistic. it simulates also some kind of selective eye blending which can occur on every object you look at, if it is bright enough......
furthermore i added this effect also to my cutscene ;)
-
So cool. :D I have been waiting for the reintroduction of bloom for, christ, three, four years?
-
I'd like to see some HDR myself, but that would involve recoding the entire rendering pipeline to handle HDR. Not fun.
HDR in freespace wouldn't be too good. Take a look at this image: http://www.archives.gov/press/press-kits/picturing-the-century-photos/space-shuttle-challenger.jpg (http://www.archives.gov/press/press-kits/picturing-the-century-photos/space-shuttle-challenger.jpg). The stars are so faint that almost none can be seen. In freespace with HDR we would probably have two situations:
1. Background stars and nebulas fully visible, then bright flash of light when something appears on the screen and before exposition will compensate.
2. Some ships on the screen, or even only sun and "where's all that beautiful background?"
IMO better just stick to the bloom.
-
I'd like to see some HDR myself, but that would involve recoding the entire rendering pipeline to handle HDR. Not fun.
HDR in freespace wouldn't be too good. Take a look at this image: http://www.archives.gov/press/press-kits/picturing-the-century-photos/space-shuttle-challenger.jpg (http://www.archives.gov/press/press-kits/picturing-the-century-photos/space-shuttle-challenger.jpg). The stars are so faint that almost none can be seen. In freespace with HDR we would probably have two situations:
1. Background stars and nebulas fully visible, then bright flash of light when something appears on the screen and before exposition will compensate.
2. Some ships on the screen, or even only sun and "where's all that beautiful background?"
IMO better just stick to the bloom.
Very good point. I completely agree. Unless there is a good work-around.
HDR is mostly interesting for TCs that feature ground missions.
-
Don't get me wrong, it's great that it can be done, and it is "quite tasteful," but too much of a good thing ...
See the part about it being "adjustable" :)
-
\Sigh
Yes, guys, I understand that it is adjustable. I got that when I first read his post.
-
On the point of HDR, i disagree. Who said HDR had to be perfectly realistic? Isn't it also perfectly reasonable for the stars to instead take advantage of HDR and give them a nice bump on the brightness scale? That way you'd be able to see then provided you weren't looking at the sun, which you already have a SCREENGOWHITE effect for anyway. In fact, HDR would make it easier to see the stars when you should be seeing the stars. A la, when your not staring into the engine glow of something. Tone mapping goes both directions.
-
On the point of HDR, i disagree. Who said HDR had to be perfectly realistic? Isn't it also perfectly reasonable for the stars to instead take advantage of HDR and give them a nice bump on the brightness scale? That way you'd be able to see then provided you weren't looking at the sun, which you already have a SCREENGOWHITE effect for anyway. In fact, HDR would make it easier to see the stars when you should be seeing the stars. A la, when your not staring into the engine glow of something. Tone mapping goes both directions.
I have to whole-heartedly agree. It would be even better than now, since HDR makes it possible to have true changing light ambience - ergo when looking at smg. bright you won't see that well in dark areas, but that's alright....neither do you in life. When looking at something dark, you will see earlier "soft" ligthsources as a lot brighter. Which is alright too.
What the system tries to compensate is your monitor's inadequacy at rednering very dynamic images (with a very big difference between the brightest and darkest parts). Instead settling for a "muffled", grey middletone; you can achieve true dynamic range.
HDR isn't bloom, or enhanced or any of the other crap you see in most games!
Hell, I hadn't seen a HDR game in all these years, until I tried out Stalker on my friends rig.
It's different. Check out the Lost Coast on HL-2 to get the idea.
-
Could the bloom shader be made independent so it runs on all my OPENGL (or even Direct3d) games?
please?
Anyway, those pictures look better then the ATI Smarthader (HDR-Ish Lite). So, keep it up, and please get it working before summer ;).
-
It's a shader not an application.
It probably be used in some games (D3D9 as long as it's HLSL), but not without support for it in the used engine.
Anyway, those pictures look better then the ATI Smarthader (HDR-Ish Lite). So, keep it up, and please get it working before summer ;).
Yes, I agree. Much better than just blooming everything. ;)