Hi there,
I’m wondering, for an open world kind of game (well not so big, something like 4k terrain) should I go with static lighting or dynamic? Certainly dynamic is a lot cooler since there are town and natures and lots of lots of meshes but I’m also wondering if it would be so problematic performance wise for the end users?
Usually you’d have to go with dynamic lighting–you might not be able to build the static lighting for something that’s very large since it could take more RAM than your system has, plus it would possibly take a large amount of disk space once the lighting is built. You then just have to figure out how to get a nice result with dynamic lighting.
Which is… as hard as setting foot on moon? 
You basically just want a Directional Light + Skylight. Individual non-shadow casting point and spot lights can be used as freely as you want (shadows are the performance killers, not the lights). The only issue with this is that the dynamic skylight lights EVERYTHING, so it’s really difficult to actually make very dark areas like caves.
^Pretty much that. If it’s an outdoors map then most things are in direct light and skylight can add a bit of light to the shadows and make it more realistic. If you really want to you can get into more complicated stuff, but directional light + skylight is probably the best for performance.
I’m experimenting. Thank you both for the guidance. 
What kind of performance return, if any, can we expect from painting holes in the terrain that isn’t visible. Let’s say about 40% of the terrain could be painted out because other things are sitting on top of it…like another piece of terrain. Imagine a layer cake where the bottom layer is four times larger than the layer above it…and there’s four layers. And we paint a hole as it gets progressively smaller at the top layer.
If there are any performance improvements in that, they’ll barely be noticable. The engine still needs to “draw” transparent terrain. What you want is to delete segments that are fully hidden.
That’s what I thought. 
Thanks.
To bad they don’t have something like a skylight occlusion volume.
I believe that’s the 5000000th time that was brought up by me and other people on the forum. 
You could implement something similar to a tonemap controller that turns down the ambient lighting based on their current location (raycasting upwards and grabbing the material to determine if they’re indoors, etc.) This is likely what you’d want to end up doing if you want to have a continuous map but you could potentially run into issues such as staring out of a window would cause the ambient lighting outdoors to be darker due to the fact you’re indoors.
I can try experimenting with the concept I outlined above, I haven’t touched UE in months so if something I said has some sort of inaccuracy let me know
I’ve tried that, and the “who shut the sky off” effect is too noticable. I also tried making a double sided plane with different materials on both sides, one to darken the scene behind it and one to lighten. I’d then put darkness post process inside caves and that “darken” plane on top of the entrance. Then, from inside, once the post process kicks in, you’d see the “lighten” plane that would make the outside look normal.
This works, but has an issue - the camera near clip plane. There’s a centimeter where your camera is outside of the post process but it’s clipping through the entrance plane, showing you the “bright” cave behind it. This results in a bright flicker when you enter caves. This might be solvable using world position offset though, I could push the vertices back until the camera is in the post process…
Maybe you can try post process volumes and ambient cubemaps instead of skylights. You have the same controls of a skylight, but with the added bonus of being able to change the values based off of you distance between volumes. And I do believe you can animate the values in Blueprint. Yes, you will have to have a generic cubemap for lighting, and the same cubemap may not work in different situations (like indoors), but it sure as heck beats environment colors and skylights in UDK (read: ONE color ambient light).
Have you tried using interpolation?
The near clip plane should be easily solved, I assume the UI is likely drawn ontop of a mesh but that may be the source engine calling me 
Have you tried replicating this method with post processing triggers?