Ah I get it
Thanks Spike! I really appreciate it!
Today was a long day at uni, so not a lot got done. I experimented with "hot coals" as a hazard type (that fits with the orange glowing and heating up), but couldn't produce a nice enough texture today. If it doesn't get anywhere I'll try do something with electric floors as Error014 suggested.
Here's a fresh shot! Subtle change here:
Bloom. Not just any bloom, though -- I use MRTs to get most of the advantages of HDR (KarBOOM doesn't need automatic exposure adjustment, and since it's all forward-rendered there isn't an advantage to extra colour precision within the visible range either) with far less overhead. It might look like a bit much here, but I chose this screenshot to show off the effect -- 3 cars are just about to explode from being on grass too long, we have 2 fresh explosions, and the
weak spot mutator is enabled.
And in case you weren't sure: the ramps, barriers, skybox and shader effect on the terrain are all placeholders.
Here's the deal for those interested: I don't want an over-the-top bloom effect like from the XBox/PS2 generation, but that is really hard to avoid when doing bloom as a post-process of a standard-range (as opposed to HDR) image. I only want bloom on items that
exceed the normal range (that is, flat-white, even though it's at the top of the normal range, won't get bloomed at all, but things brighter than can be displayed should get bloomed). Secondly, items that
do get bloomed should preserve the colour of the extra light (think of a lightsaber -- white in the middle because it's so bright, but the bloom around it shows the lightsaber's true colour). This is what HDR is normally used for, except I don't want a dynamic range -- the lighting in KarBOOM is constant enough that exposure testing would be wasteful because exposure would almost never (or only slightly) change, and HDR would require more render targets (or at least much heavier ones, depending on your implementation), requiring a bunch more memory and using up a lot of resources for post-processing. All for a subtle effect.
Yuck.
That's why I love MRTs
All lighting is calculated in the shader and never limited, so the final colour value (between specular highlights and accumulated light from glow-maps, heating effects, and [in the explosion's case] internal lighting calculations) is often greater than 1.0. Subtract 1.0 from all components and write this to another render target, and there you have your input image for blurring and adding over the standard view for the final result. Colours at the top of the normal visible range won't get bloomed (like white, bright blue, and so on) unless they significantly exceed the normal range.
Hardly any overhead at all -- mainly the 16-sample blur (which isn't intensive at all by modern standards).
I still have some coding to do to have it switch on and off easily regardless of whether AA is on or not, but the effect is there.
Jibb
