Scalepiercer: Real time lighting in pixel art
I wanted to share some sprite normal mapping that we're implementing for our game! One reason I prefer 3D artworks is the dynamism of lighting that can be easily achieved with a renderer, something you couldn't historically do in 2D art with ease.
But lots of modern 2D engines adopted the 3D concept of 'normals' and now we can do stuff like this!
In Scalepiercer, we are using normal maps for characters and weapons/explosions. Our characters will react to light in real time similar to games like CRYPTARK and Airships: Conquer the Skies!
So how do normals work? What if you wanted to do this for your own game? Well there's many ways to normal map sprites! but here's how we did it:
We went into Blender and created a 'shape-sheet' like this by positioning 3D objects and taking a screenshot of their normals as viewed from above. The funky colours are because we are actually encoding *directions* for how individual pixels are "rotated" in 3D space! That's a normal map!
A TLDR of the directions are as follows:
A color value of 128 means "middle/no angle", with 0 and 255 being 90* facing one way or the other.
Red is the East/West facing angle
Green is the North/South facing angle
Blue is "tangent"/facing-camera and is always 255 (which is why our 'normal map color' is this specific 128,128,255 blue for a flat surface).
Knowing this information, we paint over our cargo container by sampling the 'directions' from or normal map sheet to create something like:
Keep in mind different game engines may have different direction encoding, if your sprite lighting looks backwards try inverting the red or green channels!
This is human-readable data too if you keep in mind that the presence or lack of a color means a direction! After some time you may be able to read (and even possibly paint) your own normals without constant reference.
P.S: I didn't know where to fit this but a note on automatic normal mappers: There's great tools like Laighter and Modlab which let you instantly create normal maps from sprites! These tools are very powerful and often make it very easy to do these effects, the reason we avoid them here is because they rely on the *brightness* of a sprite instead of intentionally knowing the *direction* of one. We found that the generated results often don't "understand" the 3D forms of a sprite as well a human who can think abstractly. If you want to mess with these techniques with little effort, or your art style is compatible with how these programs 'read' files, I'd recommend trying it! It's fun!