Selective Bloom, Emissive Glow, Fake HDR, there’s a number of ways to call this, but with Metric Racer being a scifi racing game, there was a need to make it look, well, scifi-ish. What that meant was a lot of sharp corners, chamfered structures and a lot of bright neon colours that pop from the screen. To achieve this, I was able to quickly modify a few shaders to get this result. You can see below the final result.

Metric uses the, Vertices Engine which uses a deferred rendering pipeline for it’s 3D graphics. The first pass involves drawing to 4 render targets at the same time, a high precision Depth Map, Normal Map, Distortion Map, and a Surface Data Map. This last map holds the specular data, along with shadow factor and the value for an emissive map. It’s this value from the emissive map that we’re interested in.

Faking the Glow

In a general bloom, the entire scene is used when extracting the bright portions. This can sometimes work well but often times gives a washed out or overly soft look to a scene.

For the emissive map though, when the bloom shader extracts the bright portions, it only does so for regions where the emissive map allows it to. This let’s us perform a selective bloom which sort of ‘fakes’ an HDR look by letting us highlight certain area’s of the screen and give the impression that certain area’s are brighter or “glow”.

Fine Tuning

The value of this emissivity can be controlled in multiple ways as well.

Boolean Control

First, there’s the boolean ‘yes-no’ for the full screen or emissive bloom. You can see this in the property grid control.

Surface Maps

Then there’s the emissive map, which comes from the alpha channel of the models surface condition map (which also holds the Specular power in the R channel, Spec Intensity in the G, and Reflection Amount in the B). By Fading the alpha value of this map, I can have tighter control on which parts of the model are more emissive.

Per Object Factors

And finally, there’s a per-object Emissive Glow Intensity factor in the shader which multiplies the emissive map value, allowing for items to pulse, hum or cycle their emissive values, which would be useful with an object like a light flickering.

To Pre-Multiply or Not, That is the Question

Another option which gives different results is whether to apply pre-multiplied alpha to surface data texture map during the content build step. Assuming the emissivity value, which is held in the alpha channel, is a full transparency, and If I pre-multiply the alpha, then that knocks out the RGB values altogether, meaning no specular or reflections will be passed through the pipeline for that area. Turning off pre-multiply will allow the specular/reflection data to pass through along with the emissive data. This would be useful say for a computer screen where there would be emission along with reflections and surface details.

Next Steps

I’m really happy with how this has turned out. But while doing the selective bloom, this completely negates any specular highlighting from the scene. The next step is going to be to extract any and all specular highlights and lighting data from the deferred rendering lighting pass and pass those highlights into the bloom extract pass.

Final Thoughts

This took almost no time at all to implement. After getting it working in the Vertices Test Bed, the results were evident immediately in Metric. Adding a center glow to the track helps lead the player around the course and adding an emissivity to the start of explosions gives a larger punch and emphasis to them. This effect, while trivial in it’s implementation, has added greatly to the flexibility of Vertices and the final look of Metric.

The subtle glow is even more evident on one of the Mars Sections:

 

blender Coding Design Editor Game Design Game Editor Game Engines Games Gaming Indie Games MonoGame Programming Tools videogames Xamarin XNA