Lighting artists explain how they relight habs, adding a door button that switches a hab to a low-power night state. They cover light groups and their four states, day/night switching in Orison, shadow and lighting budgets set by graphics, and working with VFX.
Well, a lighting artist, it's fairly self-explanatory. It's in the title, but it's basically taking the environment that gets made by the environment artists and level designers and adding lighting to it in a way that represents the art director's visual target for the game, while also keeping in mind things like performance constraints, technical restraints, and also some gameplay considerations like leading the player, making sure that they have good visibility where we want them to have good visibility, that they know where they need to go if it's something like a linear level design.
TL;DRThe stream shows real-time work on relighting habs, including a new door button that dims lights into a relaxed nighttime state, which is the team's actual task that week.
Today, we're going to show the process of how we are relighting some of the habs around the PU. You may have noticed in Orison, currently on the PTU, we've got new habs there, and we've added a button by the door, which allows you to push it and basically turn down the lights. I hesitate to say turning off the lights because obviously there is still lighting there. But you basically put the hab into a state of a chill nighttime, either relaxation or sleep kind of state. What we're going to do is show how we do that process and our thoughts behind why we're picking certain moods or make certain decisions while doing that. It's something that we're doing right now. This is real-time game dev.
TL;DRThe habs aren't being redone; the aim is to add player interactivity through light groups tied to a player-usable switch, extending lighting states previously used mostly in ships.
As you say, we're not reinventing the habs. We're not changing them completely. But we've always had a desire to add more player interactivity from a lighting perspective. You've already got some things that you can interact with in your habs, and we wanted to add to that through lighting. The obvious way to do that is we've already got these tools called light groups, which allow us to basically change the state of a light based on whatever kind of logic. Traditionally, that's mostly been in the ships, like when you take damage or when you're powering up the ship for the first time, there's a low power state and a full powered state and an emergency state. And we've been, over the course of the last year or so, introducing some of those elements into locations where we feel it makes sense and where we can get the most bang for buck. And the next obvious thing was to do it in the habs, where we recently got some new gameplay entities that allow us to tie the light group into a switch which is player interactable, so that the player himself or herself can manually change the light state.
For the time being, for habitations, it's just going to be a low power state and a full power state. We're not adding too much complexity to it at the moment. We just want to get something in as a proof of concept and then see where we can expand it, where it makes sense to expand it.
TL;DRA hotkey spawns a playable character in the editor to quickly check interactions and how characters, and therefore NPCs, look under the lighting; the nauseating effect is thought to be a bug.
Z
ZachJunior Lighting Artist
We have a little hotkey, Ctrl+G, that spawns you a character and just gives you the interactions that you'd expect to have as a character. So it's just a quick way to verify how this interaction feels and how these characters are receiving light in these spaces. There are other ways that we can look at that. We have a client that we can run where you can actually have your own version of a server on your PC and do the whole process, spawn in a hab, move around, visit the entire PU. But this is just a quick way of doing it in the editor for these smaller spaces. And it looks a bit nauseating when you go, whoa.
I'm not sure what that nauseousness is when you jump into game mode. I think it's some bug which will no doubt be fixed. But as Zach was saying, the benefit of being able to jump in game like this is that we're trying to make the environment look good, but in the actual game itself, there's a lot of characters running around. And so we also have to verify that the player character looks good. And by doing that, we also make sure that any other NPCs or AI can theoretically also look their best under the same lighting circumstances. So that's something we're always keeping in mind when we light environments.
TL;DRThe switch is wired to a light group whose states, such as default or emergency, can be set and toggled manually while working, with transitions between them added afterward and described as the tricky part.
Z
ZachJunior Lighting Artist
The way that that switch works is that it's hooked up to one of these light groups, which is something that in theory should be in every what we call object container or area, like a hab or a hab floor. And within this, you can set how you want. So for example, in Orison, we have the day/night states where we switch on all those lights in the garden on the trees at nighttime. So one of the things we can do from this light group is set it to be affected by day/night and set which of those states, auxiliary, default or emergency, we want to switch to. And then the engine, when the sun reaches about the horizon level on a planet, will switch between them. And so I'm just manually in here switching between these states so I can see whilst I'm working what we're going to have. And then once we've established those two different states is when we'll probably go back and do the transition and how those lights are going to flick on or fade off. And that's the tricky bit.
TL;DRShadows are among the most expensive parts of rendering, costing both GPU and CPU (draw calls) and growing rapidly with each shadow-casting light, so lighting is managed within an overall budget.
Everything has a cost. There's no free lunch in lighting. I don't think I even can get too technical into it because I don't really know. But every light has the option of being a shadow-casting light. And in computer graphics, shadows are generally extremely expensive, one of the more expensive parts of rendering a scene. And so whenever we use shadows, we have to keep in mind how many shadows we're using. The more that you have in the scene at one given time, it can exponentially get more expensive, and it adds a cost both to the GPU in terms of actually rendering the shadows themselves and then also a cost on the CPU for all the additional draw calls that get introduced by the CPU trying to calculate how many extra shadows have to be computed.
We generally get guidelines from the graphics department, again, mostly because lighting is almost purely a graphics side of the equation. So the graphics department gives us a set of budgets to stick within, and that's the number of overlapping shadows that you can have on screen at any given moment, like two shadow-casting lights next to each other, how many lights in general make up the overall scene that you can render on screen at one moment, and stuff like that. We basically just have to stay within those boundaries. And then we also have to allow for a certain amount of overhead for unknown light sources, basically. Because again, this is a big multiplayer game. Glow sticks, flashlights, ships, all of these things can, depending on the location, be introduced to the location. And then that just adds on top of that budget.
TL;DRConfined spaces like habs and shops allow a bigger lighting budget, while outdoor places like Orison need constant rebalancing because adding one light can duplicate across many identical platforms.
Yeah, exactly. These kinds of examples, we generally love working on habs and shops and stuff like that because not only are they very self-contained, so you can do a lot, but as you said, because they're very confined environments within a culling volume, we can spend a lot more lighting budget really making it look as good as we envisage it. Whereas something like Orison and outdoor environments in general, there's a lot more variables at play that always have to be rebalanced. So when it comes to lighting somewhere like Orison, there's just a constant process of iterating. You make a bunch of changes. Those get populated because there's so many different platforms which are duplicates of each other. So if you add one light, you could end up adding 500 lights to the overall scene of Orison. Then we have to balance using our various optimization methods to keep our numbers within a certain range.
Well, it can happen. Absolutely. And it's always pretty devastating because it's like you've got to hack away at your baby, take off some limbs and hope that it still is pretty. But sometimes that's just the cost of things. It all comes down to weighing up where we want the budgets to go. So in a small environment like this, where there's not so much VFX, for example, if we wanted to or if there was a decision made, you could push some more of the lighting budget in towards the VFX budget because they're not using it. The ultimate goal is always to get a certain frame rate, and every department has their own little budgets to fit within that. But if some departments don't exist in a location, then we can just creep in there a little bit.
No, I don't think so. I'm on good speaking terms with Mike, as far as I know. He may feel differently. But no, we work quite closely with the VFX team on some of the volumetric particles that they were adding onto the industrial platform. I think there were some improvements to the way that particles are lit and how they receive light and cast shadows that was added a little while ago. And so there was a bunch of VFX added to the industrial platform. And so we had to work together to make sure that their VFX looks really good, and also that we show off how nicely the shadows cast through and how we couldn't really do that before.
TL;DREach light needs its transition set individually, which gives fine, powerful control but takes a lot of iteration to make the transitions feel natural for the type of light.
Z
ZachJunior Lighting Artist
You do have to do it for each light. But it does mean that, like Chris was saying, you have a very fine control and it's quite powerful in terms of if you have a vision for exactly what you want to do and you know how to do it, you can get some quite interesting complex transitions. Not that I can do that right now.
It's a lot of iteration time figuring out what feels natural. It's a balance between what feels natural for how lights would behave, what type of light it is, if it's a compact fluorescent, which slowly flickers before the power comes on, something incandescent where it has to burn for a little while before it reaches its full brightness, that kind of stuff. It takes a bit of iteration to go back and forth, and you test the animation, you test the transition, you see if it feels right, you find what elements don't feel quite right, and you go and you tweak them a little bit.
Yeah, unfortunately, the light groups only handle technically four states, so off, default, auxiliary and emergency, because the feature was initially designed for ships specifically. So even though the nomenclature of auxiliary and emergency doesn't always match up to what we're doing with the light states, we're kind of bound by those four states for now.