Hey Tim,
thanks for your quick answer and sharing your insight. I’m not a 100% convinced though - there’s always a way to make things work inside a game engine - it’s a matter of finding the best way to achieve the desired results.
Maybe it makes sense to broaden this discussion by explaining more of my concept.
What i’m after, as explained earlier, is to create game with a moving train interior seen from a first person view. The goal is to have it lit as good as the engine can offer. I know there will be compromises but i won’t call it a day just yet 
Basically it’s a moving platform game, with the train passing through an environment along an freeform, manually created path. A possibility to step outside isn’t planned.
I’ve already gotten the train, which consists of multiple imported static meshes, moving along a straight path. I set the static mesh actors to movable and ticked light as if static. The environment meshes (some trees and placeholder blocks) outside, actually only the ones that are positioned on the side where the sun light is coming from, are set to dynamic shadowing, to cast dynamic shadows into the interior, as the train moves along its straight path. So far this is working nicely! There are two compromises for me to accept with this approach:
-
One is that the dynamic shadows don’t have any effect on the indirect GI inside the cabin - that’s expected, knowing that lightmass is a precalc, static way to illuminate an environment - and is also a compromise that’s easy for me to accept in motion. The dynamic shadows add more to the immersion than the missing GI effect is taking away from it.
-
The second compromise is that with this approach the train is driving in a simple straight line, which honestly is a rather underwhelming experience, and much harder to accept.
Okay, so i’ve got a nicely lit train interior with dynamic shadows moving along a straight path. So far, so good. Now how do i get the train moving around bends? As mentioned before, my ideal goal is to have it moving along an arbitrary (but manually created) path. I’ve found three approaches for the movement side of this.
-
A very much obvious approach is a skeletal mesh, animated along a path in maya. I’ve managed to import everything nicely, and using a skeletal mesh i can achieve the most convincing animation for the moving train, allowing me to even add subtle things like shakes etc. This approach can be ruled out right away, because currently UE4 [doesn’t allow skeletal meshes to go through the lightmass pipeline][1] and i wasn’t able to find a way to hack this.
-
The second one is using the same skeletal animation imported WITHOUT any rigged geometry. So i’ve got an empty skeleton animated to move through the world, pretty much like a ghost train ;). UE4 allows me to stick static meshes into sockets of a skeletal mesh - And this actually works nicely! Even with light as if static ticked. As to be expected there are some major drawbacks though. One is that the socket attachment system likely isn’t layed out for collision geometry. When i step into the moving interior (onto a simple hidden collision block stuck into a socket) i’m experiencing player lag / stuttering. As soon as i step out again i can notice that it’s not the attached meshes (they’re moving smoothly) but likely the player physics having a hard time to keep up with a platform moving this way. That might somehow be solvable through changing player physics or so (any suggestions here?). Another drawback is that the the dynamic shadow of the static meshes seems to be stuttering in motion. This only happens with the shadow of one static mesh falling onto another static meshes surface. the selfshadowing is absolutely smooth. Maybe this is resulting from the same source as the player stuttering (amount of ticks/updates per second for attached meshes maybe?). The third drawback is the one i initially created this question for. it’s the combination of realtime shadow casting / dynamic lighting with lightmass precalculated shadows (static GI vs dynamic lighting). I’ll get back to that towards the end and continue with the movement side of things.
-
The last movement approach is having my imported static mesh train interior models set to movable and light as if static checked and then make them move along a spline created in UE4 [via blueprint][2]. This works but it will need quite complex blueprint work to give authentic results for the train movement. I’m not a programmer and i always prefer a manual/artistic approach over a solution implemented through algorithm when it comes to subtle motion etc. There’s one big plus for using blueprint though. This way there’s no player or light stuttering. I do have the same problem with static GI vs dynamic lighting as in the previous approach though.
To sum up my findings for the train movement i am somewhat confident to get either the second or the third approach to work. I guess it’s a matter of implementation here. Either i get the skeletal, socketed approach to work stutter free, or i manage to create a convincing movement through blueprint.
That brings me to the drawback both those approaches share: the GI lighting
Again, i’d love to make use of the super nice indirect lighting / GI i get from using lightmass. The realtime GI solutions are sadly not practicable for me yet so i need to focus on some sort of hack or workaround to use the precalculated lightmaps lightmass provides.
to visualize the prominent issue i currently experience i created this image. sadly, right now, i can’t share any of the scene work - so this will have to do for now.
Just as it is supposed to do, lightmass is calculating the direct light, first bounce, second bounce etc, and combines them all together into a final lightmap after completion. Because with both practicable movement approaches the static mesh is set to movable and “light as if static” ticked, it also casts a dynamic shadow as well. And once the train starts to move around a bend (rotation) the dynamic lights shadow will stray away from the starting position, revealing TWO shadows (see image). This is obviously to be avoided!
I find the realtime cascaded shadow of the DIRECT DYNAMIC LIGHT to be visually convincing enough to replace the BAKED IN STATIC LIGHT. To be able to achieve this i need to prevent lightmass from writing the DIRECT LIGHTING into the final lightmap. I understand that Lightmass needs to calculate this direct light to calculate the important Diffuse Interreflection afterwards. Let me illustrate this with the following image.
As visible in the Lightmass documentation there is an example of the first and second bounce light pass SEPARATED from the direct lighting pass though. So atleast for debug/technical presentation purposes there seems to be a way to extract each separate lighting pass during/after lightmass calculation. What i would like to do is exclude the direct light result from the final lightmass bake result.
What i hope to get in return is a cheap but high quality GI solution that works with limited dynamic light movement. The indirect light reflections (GI) will hold up as long as the dynamic light is only moved in a limited space/directionality (like just a few degrees). The visual result would only break if the dynamic light source would point from or move to completely different positions (like from the opposite side).
Is this somewhat understandable? I would absolutely LOVE to learn that this is actually possible. I know that the chances are massive that this not achievable right now. But still, maybe there’s a way to hack around, find compromises etc to get closer to what i want to achieve.
Help of ANY KIND is greatly appreciated here. Thanks in advance!
