Hello guys,
is it possible to recreate something like Titanfall 2 time-traveling where you are on the same location but in different times (aka before war and post apocalyptic) using Blueprints in Unreal Engine 4?
See http://kotaku.com/let-s-talk-about-titanfall-2-s-best-mission-1788777731 for example if you don’t know what I am talking about 
I think it should be possible. Technically there’s really no “time” in a virtual environment so it’s not like you’re trying to invent actual time-traveling.
The only thing you really need to do is create an illusion that you’re being transported back in time. The way you do that is create an area and duplicate it so they’d be identical. Then add very different props on each one to create the feel of past vs future. You’d make the “future” one look older and weathered while making the “past” one look shiny and brand new. After that when you reach certain locations in the map you toggle between past and future by simply teleporting your character to the past or future version of the map. You’d have to set up the locations where these will be triggered though so you’ll need some volumes to trigger when the player reaches a certain location.
I’m not sure if there’s a better way of doing it but as of the moment I think that’s one possible way that it can be done. Definitely not something that would be too difficult to do in my opinion.
I’m not exactly sure but it definitely is possible. Maybe look into Level Streaming? Develop the first version of the map, save it, duplicate it, and make the necessary adjustments then use level streaming to switch between the two maybe? 
Yep my idea would be to create one level duplicate and edit it and teleport the player to it. I am fairly new to the UE4 engine so there are a few things I am thinking about: Let’s say you kill someone or you do an action like pressing a button would it be possible to copy the interaction to the new location that you can see bones for example where you killed one? What is about the lightning like are different sky lights possible depending on where you are? Can you teleport the player to the exact same location in the different map version. And would this hit hard on the performance?
Definitely possible, all with blueprints.
Level streaming would not work if you want to switch quickly as in TF2. All assets have to be in memory. Then it is just a matter of turning on and off assets and modifying materials depending on which time period is “active”.
I think it is possible. You probably need to use blueprint communication though using event dispatchers to tell the duplicate level that a certain event has happened and update appropriately. You can take a look at the following documentation links:
https://docs.unrealengine.com/latest/INT/Engine/Blueprints/UserGuide/BlueprintCommsUsage/#eventdispatchers
https://docs.unrealengine.com/latest/INT/Engine/Blueprints/UserGuide/EventDispatcher/
I really have no clue about that since I’ve never tried it personally but maybe someone else in the forum has some answers.
Depending on your design this should be fairly simple in my opinion. Let’s say you design it in a way so that the duplicate version of your area is 10,000 units above the original in the z-axis. That would mean your player would have exactly the same x and y position. Then to teleport them to the exact same position between maps, all you have to do is to add or subtract 10,000 units from the z value of their current position.
I believe it shouldn’t have any performance hit if you duplicate the area but it would definitely consume more memory.
Basically, there are different trade-offs depending on your implementation since there are multiple ways of achieving the effect. If you don’t duplicate your area and simply try to toggle every individual element to change or update it then it would mean you’d have to loop through every prop and material that you need to update or use event dispatchers to tell each object that they need to “update” themselves. The pro of this is you will probably use less memory, since you don’t have the additional walls and floors. The con is looping through each item would likely consume processing power depending on how many items you need to update in your level. I mean imagine having to loop and update thousands of objects.
On the other hand if you duplicate the map, then you use more memory but use less processing power since you already have the items duplicated beforehand and don’t have to update them one by one. As you can see it’s a trade-off between using more memory or using more processing power. At the end of the day, the best approach would depend on a variety of factors like - how large is the level; how much memory is available in the system, and that sort.
As for level streaming, I’m not sure how slow it will be or not to be able to say if it will work well. Like I said it might depend on how large the level is. This thread made me curious enough to read about level-streaming on the docs and it actually says the following:
So technically speaking it seems that the level is actually loaded into memory. However, people usually use the term memory rather loosely. If you have a background in computer science, you’ll understand that there are actually different kinds of memory from fastest to slowest (also most expensive to least expensive): Registers (used in processors) > VRAM > RAM > ROM
Usually when people talk about memory they actually mean RAM or system memory and that’s probably what the docs are referring to. Therefore, Level-streaming probably loads your level into RAM. On the other hand, I think what HavocX is talking about is VRAM or the memory in your video card. Having a duplicate of your map in the persistent level would mean it’s already loaded into VRAM, and logically speaking it should be faster for rendering on screen.
Like said before, you can duplicate a level and weather that one.
I found this thread searching answers to how to regard Stats for Texture and Primitives, specifically “Fully Loaded Memory” in the former and “Size” in the latter. It’s the distinction between system and GPU memory I’m trying to understand. dacster13 suggests UE4 refers to system RAM, so I’d add the Size of all meshes and Fully Loaded Memory of all textures to weigh that against system memory. I then also have a question about how polycount and size/number of texture maps relates to video RAM, but firstly; I’ve got 16 GB RAM (system), and with nothing else running but Editor I’d expect to be able to use at least 12 GB of that (notwithstanding the fact that Windows 10’s memory management uses all the memory, but manages what to spend it on depending on what’s most important, what’s “on top”.) So, my Stats report I’m loading about 5 GB total between geometry and texture, mainly geometry, and this between two levels created under Persistent. I’ve yet to create load and unloads to leverage Level Streaming Volumes, which is really what I’m after to understand how to right-size each Streaming Level.
So, with 16 GB RAM why would UE4 crash with an out of memory message? I have BTW the GTX 980 Ti with 6 GB video RAM, which makes me suspect I’m right up against that threshold. This leads back to my second question about video RAM. My understanding is that the GPU is only called on to draw to the screen whatever draw calls direct it to do so, this hinging on what’s in front of the camera. I’ve optimized my set with many small chunks to leverage occlusion culling, am getting 70-90 fps depending on which way the camera is facing, but GPU doesn’t feel pushed at all. That said, when I open a utility like TechPower to monitor GPU memory usage I see all 5.5 GB loaded into video memory. How to square that with dacster13’s statement? Is it possible that both types of memory are loaded with X?
I don’t think it should be that hard to make really. it’s not another level, you should be able to keep the same level and toggle some post-process/materials on the scene.
Then toggle some static mesh visibility on/off in order to swap the element you wanna change in the scene.
I really liked this gameplay from Titanfall, was pretty cool.