I have to say that I’m becoming very annoyed about the current status of RGB lightning in the PC space, and industry overall. What exists now are multiple RGB lightning vendors, each one with different proprietary software. And the novelty of static lightning quickly fades once you start to figure how a pain in the ass is to make the lightning reactive to something, like games, music, or even what’s happening in your monitor screen.
Just a quick googling around RGB software and, depending on how many device brands you have installed in your computer, you will find multiple applications to handle your RGB devices:
- Thermaltake RGB Plus
- MSI Mystic RGB
- Gigabyte RGB Fusion
- ASUS Aura
- NZXT Cam
- Corsair iCUE
- Logitech G Lightsync
- SteelSeries Engine
- and more…
Not only that, you must take into account that games or other software that wants to use them needs proper compatibility from the software itself. There is some software that tries to unify everything, namely Aurora, but this raises unwanted problems with application security since it needs to check constantly the game status, something that not every anti-cheat software is happy about— nobody wants to risk a lifelong ban for a false positive just for glowing lights.
In the end, you end up with multiple software controlling multiple devices that may or may be not compatible with the game you want to play, and at the worst case scenario, trying to manually make the lightning responsive to the game events. All this sounds very obnoxious and counterproductive.
What we can do to handle this problematic? This is not an user problem, so we can’t do much about it. This a vendor problematic, and this ramps up to eleven when they push bad software to control RGB and offer little support, which is sometimes the case since you’re married to what they provide.
The only one that can tackle this is Microsoft. Hey guys, you know where to send the paycheck:
Make Windows Lightdome.
A dome to control the light
What I propose to the folks at Redmond is an ecosystem called Windows Lightdome: an API that would intercede between the software that wants to control lightning and the device who emits light, and a “Lightdome Panel” that allows the user to manage how on what will light on.
The principle is simple: the application is what sends and emits an “event” to Windows Lightdome API itself, and this should contact the RGB devices (through their drivers, if needed) and manage the lightning effects. This is done though Profiles that the application provides to Lightdome.
Profiles are what connect the software to the hardware, but also dictates how the lightning effect is handled, instead of letting the hardware or software do it.
Having multiple devices registered allows the user to intuitively know what they have, and categorize them or group them.
Registering a device to Lightdome
Devices should be registered to Lightdome by telling how many individual Emitters they have. An Emitter is usually comprised of three LEDs (red, green and blue), and optionally, a pure white one — the point being, an Emitter can light up to one of 16 millions of colors.
Each group of Emitters is called a “Light Source”, and these can be managed individually. For example, a Light Source of four Emitters are transparent to Windows Lightdome, but if Lightdome instructs the Light Source to be bright red, all the four Emitters will be red.
Light Sources can be a block or a stripe. Block means all Emitters will change color at the same time, while Stripes have an ordered list of identifiable Emitters. The latter is what allows you to make rainbow effects like this, since a color is sent to each of them.
These Light Sources should have descriptive names, making easy to the User where the hell each Light Source is and what it powers.
Devices can also register Groups, which are comprised of many Light Sources. For the case of Keyboards, these can have groups like “Direction Keys” instead of letting the user deal with each keyboard individually.
Motherboards with LED jumpers would be noticeably better and more personalized. The motherboard vendor should be able to tell Lightdome the parts of the hardware that are LED connections (12V + RGB/RGBW), through a standard driver or a custom vendor-provided one.
Event Bus in Lightdome
Everything starts with an Event sent by the application. These events are labeled by names that a Profile can match in Lightdome. These Profiles are what connect what’s happening in the game with the lightning itself. Profiles may be installed by the application, but these can be manually created by the user or supplied by a hardware vendor.
This approach solves the need to code the game itself to work with a proprietary RGB software and vice versa, or having it managing the light effects in a hard-coded way.
So, what’s an Event? These are labeled pieces of data sent to the Lightdome API with have, at least, three key pieces: a name, a type, and optionally, a set of key-value data in JSON.
The Event name makes it identifiable for Lightdome, while the type determines if is constant (always on, but values change) or dynamic (lives and dies, but its values don’t change). When Events don’t push the type, is understood is dynamic.
The values in the Event can only be numbers: integers, hexadecimal or single-precision float. This is because Animations and Transitions can take this data and directly use it without calculations to modify the result. We will come to that concept later.
So, what contains a Lightsome Profile? Is just a list of Actions, Transitions, Animations, and Keyframes.
Constant Events can be resumed in ongoing lightning effects with data values that change over time. For example, an Constant Event would be the health indicator, which changes color from green to red depending on the player’s health. Only one Static Event can live at any given time.
Dynamic Events are the opposite: these are short-lived lightning effects.
A Profile, which lives in Lightdome, lights your hardware by associating an Event to an Action. An Action is just a instruction list that says “run these animations (keyframes) when this event fires”.
Since multiple Actions can be fired at once, only the one with the higher priority level will be active.
For example, when in Doom Eternal an explosion occurs, the game will tell Windows Lightdome that the event “explosion” has been fired, along with some useful data. When Lightdome receives the event, it will read the Profile and check for all the Actions associated to the event. The
bright_red action will execute a given Animation, and have access to the Event data to modify the resulting lightning effect based on the explosion
strength value. That’s because Animations and Keyframes should have access to the Event data itself.
A thing of priorities
As you see above, explosions are suddenly cut out from lightning when the Health event is “critical”. Every Action has a priority level, so this way the Profile developer can have control of what lightning effects are over another.
In the above example, having critical health is very important, so a pulsating orange lightning will always show regardless of the events sent to Lightdome. Since the “Health” Event is persistent, the Static Action associated to it can change its priority to zero.
Having the priority in the Action rather than the Event makes the lightning fully editable by the game developer, end user or hardware vendor.
And talking about vendors…
Vendors at the rescue
Profiles enable lightning to work in any hardware RGB compatible, since are just instructions on what light animation to play on a given event.
Vendors can supply their own custom Profile with different animations for different parts of their hardware Light Sources, for a given game. For example, my Logitech G Hub could automatically install a Doom Eternal Profile for my keyboard and mouse once available. I could duplicate the Logitech Profile and edit it to fit my own lightning tastes.
As you can note, the vendor programming a custom profile is much faster than trying to tightly connect game events to a proprietary application.
Windows Lightdome should let the user to group multiple items to be handled in a personalized manner. Basically, you should be able to set a group of devices to handle determined Actions.
In the above example, I can set my Headset to always light a color with my current Health in the game, along my keyboard and mouse. When an explosion occurs, the keyboard and mouse will bright red along the monitor backlights, but my headset will be still with my health at all times.
The users should prefer this instead of manually routing the many actions a game could have in Lightdome to each device, which is time consuming, but I wouldn’t be against a full manual mode that could be implemented in the future of the hypothetical Windows Lightdome.
To avoid going back and forth the application for events, a custom script language could be used to to make complex interactivity possible. For example, note the ripple effect in this keyboard:
If this could be coded for any RGB keyboard using Windows Lightdome it would be huge in opening the community to larger and complex animations, brading the appeal of RGB hardware.
Is Windows Lightdome really feasible?
Kind of. Let’s talk first from the top.
First, the road for this standard will be very difficult as long Microsoft doesn’t give it proper importance, but I feel is a great opportunity considering most games run on Windows. Their work will be to put and document the API and the Panel itself, along with the software architecture that should play nicely with Windows 10 games and their Xbox App. This could be replicated for Xbox Series X lightning, and peripherals connected to the console.
Let’s say Windows Lightdome beta is a success. Now the next task is on the developers themselves, because they need to add support for Windows Lightdome API, meaning, they need to communicate Events to it. A basic SDK could be made available from Microsoft to let pushing Events easely.
Not less important, games could brag about Lightdome compatibility by also offering a simplistic standard Profile to handle the different events and actions: a player spawn, low health, explosions, you name it. Don’t make the gamers do your job, at least, not on launch date.
Meanwhile, the vendors will have to abide to the new API by issuing correct drivers and ditching their RGB control software, which could be better in the long term. The drivers would only inform the Light Sources and Emitters information to Windows Lightdome to handle, making the implementation backguard compatible without needing new drivers. Vendors themselves could experiment with more RGB devices as long these have proper drivers.
So, yes, it’s feasible, but Microsoft will have to put the resources on this project to power up the RGB ecosystem better on games and other software, and that includes talks to game developers and hardware vendors.
Who knows if, in the future, the concept behind Windows Lightdome extends to home lightning itself, so everyone in your house can know about the explosions in your game.