next »

[Mountain Forge Games]

Hello! I am a little new to Unreal Engine, but I'd like to hear any suggestions about how this might be done in Unity as well. I'm a fan of Thief 2 and I wanted to create something similar with the lights. At present, I am using Volumes/Triggers to determine if the player is within distance of the light, then I check the distance from the player to the light and divide it by a float to get the visibility. The closer you are, the more visible you are. It is very simple.

Unfortunately, each light is not the same size and each area is not the same size, so this solution I found is very inconvenient and time consuming, both when setting up the volumes/triggers and modifying them when the level prototype undergoes alterations.

Because of this, I want to check how much light is hitting the player or how lit they are. So, I do not just want to know if a light is hitting the player, because I can do that, but I want to know by how much the player is lit up in the scene. Areas that are very dark will completely obscure the player(dark), areas with a lot of light will make them visible(light), and those areas in between will offer a value of how visible the player is (all the grays in between dark (0) and light (100).

Would anyone have a solution to this? I'm not sure if this has something to do with a shader or whatnot.

Thanks for your time in reading this message.

[powly]

You could definitely add atomic counters for the brightness and area of pixels on the main character to get the average illumination. Though then you couldn’t use back face culling or z-buffering to ensure that all sides are represented equally.

Another choice that UE might make easy (disclaimer: never used it myself) would be to render a light probe at the player location with skipping the player model to get an idea of incoming brightness by again averaging over the values - create a mip pyramid, transfer top level to CPU, calculate final value by summing the sides and computing a brightness from the RGB result.

The first alternative is easy to code up and potentially more precise (for example it can recognize if only the players foot is brightly lit) but does require a bit newer hardware - dx11 level and should (shocker!!) be doable on a mac as well. The second might be easier to set up, especially if you’re not familiar with shader programming; you can probably do it almost completely with built-in features.

[oahda]

Not sure how complex your system is. For a jam game, which had only one light (the sun) I just used the same calculation (N·L) that's used to calculate light in shader to determine if plants were in the sun so they would grow. If you have more light to worry about, maybe you can still mimic your shader somehow, using the lightmap/shadowmap or whatever you have in the same way that the shader uses it to calculate the lit pixels.

[powly]

Oh yeah, just some conservative version of the shader is way better than the environment probe approach since it correlates better with the actual rendering and requires less computation. It does require quite a bit more knowledge of the shading model though (you need to replicate area light approximations and such)

[Mountain Forge Games]

This all makes me very optimistic and I'll look into these. I'm not as good at programming as I would like to be(I can do simple stuff and have never touched a shader or lights), I'm more a design/artist type, and I'm doing a slice of a game by myself for school as a final project, but I think I can do this. I was never sure where to get the data, but these options make sense to me when I read them. I'll take a look at all of them tonight. :D

[Ordnas]

I suggest to add to the light object you have  (torch, lamp etc.) a sphere collided as a trigger, with radius same as the light radius (just initialize that at runtime in code, so everytime you modify the light you do not have to resize the collider).

everytime the player enters in, it will add a certain visibility weight, based on a interpolation between the max radius and zero, remapped to 1-0 range, and as a parametric alpha the player distance inside the trigger. You could even add a parabolic interpolation, so you have more weight near the center of the light.

Then you have a sum of visibility weights if you have more lights touching the player. That is quite performance friendly, triggering inside a sphere is event based, probably you have a tick when player is inside to modify the weight value, and each enemy just have to check that weight variable from the player. You can have for example that at weight 0.8 the player is visible, achieved by 1 light near the center, or 2 lights each adding 0.4 weight or 3 lights with 0.2.

[BorisTheBrave]

Sounds like a bad idea to use shaders. Not only complicated, but also it'll show you how well lit something is with respect to the camera position. A backlit character will be "dark" no matter how bright a light is on the other side of them!

So yeah, I'd second using colliders, and weighting them by player distance to the center, and summing if there are multiple colliders. If you are worried about occlusion (i.e. shadows), do a couple of raycasts from the player to the collider center, and ignore the collider if the ray hits something first.

[Mountain Forge Games]

I've already used colliders and a distance to the center of it to check how visible the player is. It works, but it is a real pain in the butt when building a level because it isn't realistic enough for me. It's also a pain in the butt to place them everywhere only to change the level design. It took hours last time.

[powly]

A backlit character will be "dark" no matter how bright a light is on the other side of them!

Eh, what? It’s not like backface culling cannot be disabled or circumvented

A more real problem are really slant faces where you might get strong aliasing but that’s probably not a problem for a hero character. The big advantage of doing it like this is having wysiwyg; there is no arbitrary “this is lit even tho the lighting doesn’t suggest that” or vice versa (for example, how to efficiently deal with dynamic shadow casters with the bounding volume approach?)

[oahda]

Yeah, I'd try colliders first too but it sounded like OP had already tried that and wasn't happy with the results. Ordnas's answer did address your issue with having to update the colliders after modifying the level tho, OP: create and set the size of the colliders from code for each light when the game starts instead of placing them manually. c:

[Ordnas]

I've already used colliders and a distance to the center of it to check how visible the player is. It works, but it is a real pain in the butt when building a level because it isn't realistic enough for me. It's also a pain in the butt to place them everywhere only to change the level design. It took hours last time.

You need to add lights in the level by hand anyway, you just create a prefab with a light, a collider, and a script to resize the radius at runtime, et voilà! 
It is not realistic, you mean the level building procedure?

[Mountain Forge Games]

You need to add lights in the level by hand anyway, you just create a prefab with a light, a collider, and a script to resize the radius at runtime, et voilà!  Wink
It is not realistic, you mean the level building procedure?

Yeah, I did that. By realistic, I mean there are many small areas wherein the light/shadow didn't function well enough, although at this point even recreations of Theif 2 by fans have said to use the same method. I'll just go through and make a level to alter it so it conforms or change the setting from cyberpunk to something medieval so there aren't as many lights everywhere. I'll be adding sound as well, so I'll check if a combination of the two works. I think it will. Thank you all for your answers! :D

[Mountain Forge Games]

http://forums.thedarkmod.com/topic/18882-how-does-the-light-awareness-system-las-work/

Found an interesting answer from the Dark Mod and thought of sharing it here.