Is there a way to configure a skylight (or some other type of light) to cast light evenly from all points in the sky (from horizon to apex) onto the ground?
I’m trying to use a skylight to supply some amount of global illumination to brighten up areas shadowed by my directional light, but the problem is that the skylight applies much more intense light overhead than it does from the sides. I can work around this by disabling shadow casting from the sky light, but then it affects areas which should be fully occluded the same as others (for example, the floor inside of a sealed box will be lit even though no light can get through).
When using the skylight as the only light, most upward-pointing surfaces are “shaded” as they should be, but nearly every other surface in the scene is pitch black… I can fix this by cranking up the intensity of the skylight but then the floors glow like the freaking sun. Is there some sort of angle or tightness configuration that can cast light evenly from the horizon inward rather than exaggerating the overhead light? I know it’s unrealistic, I just don’t really care.
True but that produces the same problem of increasing ALL illumination, irrespective of occlusion.
The result I’m after is increasing the brightness in all locations (shadowed or otherwise) where you can see the sky, while retaining near-blackness in all places where you can’t. So any time there’s a line of sight to the sky the shadows should be lightened, BUT any time there isn’t one, the player should be standing in total darkness. i.e. the sky casts a uniform light inward on the map from all locations, BUT doesn’t penetrate through objects to illuminate areas which can’t see daylight.
You can disable Lower Hemisphere Black for the Sky Light instead of disabling shadows all together. Also make sure you have reflection captures properly placed, they matter a lot when using sky light.
Disabling lower hemisphere black doesn’t solve it; nor should it, I wouldn’t think, since the problem is not insufficient illumination on the underside of objects but on the SIDES of objects.
I’m not using any reflection captures, actually; the cel shading I’m doing on my game fairly well obviates the need, as even if objects DID reflect correctly after having their lighting desaturated and quantized, they wouldn’t fit the aesthetic. I wouldn’t have expected (though of course I could he mistaken) reflection captures to have any effect on pure luminance…?
No, it’s like a sky illumination that casts shadows, if you have a room then the environment light can only enter through the open places. It will bounce and lose energy just like other lights.
Changing environment color from black/alpha 0 to white/alpha 255 and cranking the intensity from 1 to 10 has absolutely zero effect on how dark shadows are.
Disabling lower hemisphere black does nothing.
Here, maybe a picture will help illustrate the issue.
First you can see what the directional light yields; hard light, with black shadows. This is intentional (the cel shader doesn’t like indirect illumination as it produces too many gradients)
Second you can see what the Skylight yields when shadowing is ENABLED; note that many wall surfaces are essentially black. (This is because of movability; the objects which are pitch black are objects set to movable, and so don’t get any baked lighting)
Third you can see the combined result; note that due to the way the skylight leaves areas black, there are some outdoor areas with pitch black shadows. This is bad.
To fix it, we do what the FIFTH image is showing (disabling shadow casting from the skylight); this fixes the issue with unexpected blacks and adds a global lightening amount. When combined, you can see that this dilutes the shadows cast by the directional light, which the sixth image is showing. This is almost entirely correct.
The fourth image shows the issue with that; inside the cracked wall, you can see a space that should be almost totally black, as it gets virtually no light (except through the crack). But with a skylight that doesn’t cast shadows, the inside is lit FAR more than it should (it’s like it’s in minor shade, rather than an enclosed space.
EDIT: And for what it’s worth, setting the skylight to movable and enabling DFAO doesn’t produce proper occlusion of the interior spaces either. I don’t know why, it certainly SHOULD, but it doesn’t.
I’ve run into a similar issue…all shadows without direct sunlight are WAY too black (actually pitch black) despite being surrounded by lit surfaces…it’s not realistic at all. So far I’ve had to just chuck in additional lights to lighten the shadows…but this also looks unrealistic.
It does matter a lot. Going dynamic makes your lighting much more complex, and it shouldn’t be necessary.
I find that skylights are fairly good at baking light into the scene. I think you just need to play with the brightness settings until you can find the balance you’re looking for. If you don’t like the sharp shadows from the sun, increase the Skylight brightness and decrease the sun’s brightness. If you want the interior to be lit more fully, you may have to fake it with some soft static lights due to the limitations of lightmass. But other than that, you should be able to get exteriors well lit using a skylight alone.
The problem is some objects MUST be movable because they, you know, MOVE. For example, a wall tile which slides open or explodes. It needs to be lit the same as the static geometry adjacent to it, as in a full and smooth congruity of shadow. Skylights don’t bake that way, since shadows can’t be baked to movable geometry.
What kind of skylight source are you using? captured scene or cubemap?
I do not reproduce your dark side lighting issue when I try it out. I think what you are seeing is merely an artifact having to do with the type of cubemap or captured scene you are using. I tested out two cubemaps that can be found under “Engine Content”
TextureCube’/Engine/MapTemplates/Sky/SunsetAmbientCubemap.SunsetAmbientCubemap’
In this example, the cubemap is a sunset so it is brightest on the horizon. That shows up properly after a production lighting rebuild.
Notice light is brighter on the side than the top. And look at the cube thumbnail, there is way more light emitted on the horizon than from the top of the sky so this makes sense.
TextureCube’/Engine/MapTemplates/daylight.daylight’
In this example, the cubemap is relatively flat blue although it IS a bit brighter on the horizon than the top of the sky (not much though).
Notice that here, the sides of the cubes are slightly darker than the tops. You might think that is wrong since the cubemap is brighter on the side, but actually it is correct.
Think about one of those sideways wall faces. They really only can see Half of the sky, and half of what they see is ground which is basically black. The top surfaces on the other hand see the entire lit side of the cubemap. Even though that horizon which may be the brighest part of the cube is least affecting those up-facing surfaces, the fact that they see the whole hemisphere of lit sky means they will see more light overall.
Unless you have a cubemap like the above sunset where there is significantly more light to the sides compared to the top.
Understand that (a) I HAVE to use dynamic lighting, unless there’s a way to bake shadowmaps onto movable objects, and (b) if I DO build lighting I have to use a bounce count of 0 (i.e. NO indirect lighting) because of my cel shader/art style. This makes what I’m doing a little bit different from standard sky lighting solutions and is why I was asking for a specific kind of omnidirectional inward lighting; my concern is specifically for evenness in all non-occluded spaces.
However, as I’ve done more level design, I’ve realized that if I DID succeed with such an approach, it would still cause some issues for interior segments of the level (there would be too many pieces of geometry around them to really light them evenly) and so I’ve realized that what I ACTUALLY need is to manually define “occlusion” in terms of geometric areas, and/or manually place shadows as art assets. Generally speaking it would be easier to go with a nice even uniform skylighting and just manually define areas which are not to receive its light than to try and configure the engine to properly detect them all automatically.
It should be possible to use static lighting on dynamic primitives. FWIW you did not exactly say earlier in the thread that you are using dynamic lighting. You said some objects will be dynamic which is normal for static environments.
The standard solution is that during light baking, the editor automatically places little indirect lighting samples around your level. This is done using the lightmass important volumes. The meshes lit this way should be fairly closely lit to the static environment.
The other way is to check “light as if static” on your movable actors. That may have problems though. For example if a door is closed to a dark room and you tell it to light as if static, you will see the dark side of the door when it opens unless you place some light for it on the dark side.
Also bounce light won’t really have that much affect on the side vs top lighting. Skylights with lower brightness set to upperbrightness basically are omni inward sources like others mentioned. Everything else is just adding degrees of occlusion. Ie lowerbrightness=0 is like fake ground occlusion.
You’re correct… what I realized is that stationary skylights light movable objects so wildly differently from static ones that if I try to make a static wall with a dynamic element (say, a destructible panel) there will always be extreme lighting discontinuities between the dynamic panel and the adjacent static wall. I need every major piece of level geometry to be lit the same to cover up things like this, for nice smooth shadow lines, so I either need to light dynamic meshes as static (works okay for placed objects but you can’t prebake lighting data for yet-to-be-spawned ones; e.g. when a cracked wall panel is replaced with a destroyed wall panel, the cracked panel can be lit but the destroyed wall panel will always be unlit) or simply light everything as dynamic even if the lights themselves are totally static, which is what I’m currently doing.
Be aware, I HAVE to set my indirect lighting to 0! It’s necessary for the art style to NOT have indirect lighting bounces being performed, which means the indirect lighting cache will be populated with blacks for any areas not touched directly by light rays (or at least that’s what appears to be happening). Since static skylights do not properly shadow dynamic objects, the net result is what my picture shows: static objects have their shadowed areas lightened by the skylight, while dynamic ones do not, leading to the shadowing errors.
Case in point, here’s a simple side-by-side of a wall with baked stationary lighting versus one with pure dynamic (i.e. nonshadowing) lighting from a skylight. Notice the enormous difference between the lighting results when baked (left) and not baked (right). Shadows are properly cast on static geometry, but dynamic geometry doesn’t get shadowing from the skylight, meaning I get chunks of pure black wherever the skylight touches a dynamic object rather than a static one.
I apologize but your comparison images are not very clear to me. You are saying on the left is baked lighting with a dynamic object (the black square with the masked hole) whereas the right is all dynamic, correct?
If so, I am not sure why the large panel on the left is black since it is not shadowed at all (at least in terms of skylight visibility). It looks like your dynamic objects in sun shadow are not getting lit by the skylight at all.
I tried to set up a repro case here. I made a scene with stationary lighting.
The big cube creates an all indirect shadow area.
The “medium” cubes (selected) are Moveable objects being lit dynamically. You can tell they are different because the shadow resolution is different but the indirect lighting on the dynamic and static objects is nearly identical. There is no black indirect lighting anywhere.
