Lighting in Starmancer is a personal favorite of mine. It adds a lot of visual depth and immersion to the game.
Here is a toilet being lit by an imaginary light source.
Internally we multiply the color of the object by the color of the light in a shader.
This is the basis of the lighting system.
It would make sense that objects closer to the light source would be lit a bit brighter.
In Starmancer the light source is assumed to be in the ceiling, so we light high pixels a bit more strongly than low pixels.
In the example I was toggling the y position intensity on and off.
The top of the wall is a bit brighter than the floor and the base of the wall. (The light source was dark red)
You may have noticed that bottom of the wall was bright blue even though the light source was dark red.
Walls, like most of our objects, have lights and terminals.
These lights and terminals are self-lit, regardless of how dark the room is.
Here’s the same scene without any self-lighting.
The self-lighting is implemented with an “emission” texture. The emission texture has the exact same dimensions as the normal texture, but instead of colors it contains alpha values.
Our lighting shader “self lights” objects based on the intensity of that alpha value.
Here’s the part of the emission texture for the lights at the bottom of walls
How It (Mostly) Works
The internal implementation is fairly simple.
Objects exist in rooms. When an object is placed, it gets added to a room. The light source of the room is passed to the object so that the shader can correctly light the object.
Whenever the light source is changed, all objects in the room need to be told. This can be performance intensive if there are lots and lots of objects.
It’s also a bit more complicated because multiple rooms can have different light values and you have to merge them correctly. Rooms can also become split and all objects need to be moved to their new room. This can be very performance intensive if you get too carried away.
Doors are probably the hardest object to correctly light, because they’re the only object that can exist in multiple rooms.
I hate them.
Toilets are much nicer, but we can’t all be toilets.
The doors also have to tell their adjacent wall sides about the correct lighting values.
We have a system in place for more traditional lights as well. This is used when a door is opened between 2 rooms that have different light values.
The intensity of this light is slowly increased from 0% to 100%. This is to simulate an increased brightness as the door is opened wider.
This post became more show than tell, but that’s because lighting is so visual.
We’ll be taking off about 10 days for Christmas and New Year’s. We’ll be back next year.
Here’s everything that we did this week (that’s worth mentioning).
Fixed an issue where doors weren’t rendered properly with the delete material
Implemented UserInputAction system
Fixed an issue with wall sides not being paintable if you deleted a wall that was next to another wall.
Implemented visual selection box
Implemented FMOD Zoom snapshot variable
Identified a performance issue with placing many floors and walls at the same time.
Mouse input will now be ignored if the cursor is over any UI elements.
Changed offset of dead colonist sprite
Designed visual selection box
Designed visual for object selection
Adjusted sleeping heads
Condensed walls, floors, and foundation tool into a single menu category
Changed morgue drawer model so that it no longer opens out
Designed in-game window (for colonists, objects, etc)
Fixed a pathfinding bug with certain access position locations.
Doors will now more consistently refresh their adjacent walls’ lighting values when deleted
Created access position component for matching AI reason to specific access position
Changed how sprites are internally changed
Internal item containers are now transferred whenever items are consolidated or split.
Colonists now work with the lighting system
Text can now be translated
Wrote this list