join us to discuss new features that will help you identify where your project is taking too many resources and help you improve your overhead. In addition to some fancy new features, many systems have seen significant improvements to their performance that you will not want to miss. With such a wide array of changes, everyone from artists to programmers will have something to be excited about!
It seems most assets loaded in editor has RF_Standalone flag which prevent them been garbage collected inside editor even there’s no references, which brings the problem that when editing resource intense level, the memory usage will continue growing and the only solution is to do a full editor restart. I assume it’s originally done to minimize assets loading time from HD, but now since the popularity of SSD, is it still a valid decision?
What about DX12 and Vulkan? I would have expected they are quite a YUUUUUGE topic when it comes to “Upcoming Performance Enhancements”, since that is why these new APIs exist. So I’m a bit sad you have not even mentioned them in the stream. When will we see good support for DX12 and Vulkan thats significantly improving performance in UE4? 4.12? 4.13?
You mentioned that APEX Cloth got very significant performance improvements. Will these improvements also affect the performance of APEX Destruction?
DX12 support remains experimental in 4.11 and 4.12. Currently both APIs are tied to specific platforms / OS versions, so they are nice to have but most games can’t rely on them to fix all their woes (e.g., most desktop games are going to want to support Windows 7 as well for the foreseeable future).
DX12 and Vulcan only help if you are bound on driver overhead (RHI thread time, especially allowing greater parallelization here, and to a small extent render thread); they won’t help with game thread or make the GPU magically faster. On the GPU side there are some specific optimizations that are unlocked by not having forced syncs after compute/uav writes, but it will be a while before we fully take advantage.
The improvements and optimizations were specific to cloth and will not impact destruction.
Blueprints shouldn’t have any additional impact on GC compared to C++, it’s all about how much churn you generate (spawning and destroying actors, components, and objects). I’m not sure what you mean by ue4editor cache, but you can do “obj gc” in the exec console to force a GC.
There several improvements to GC performance coming in 4.11 and 4.12, both baseline optimizations (to GC itself, and to increase the number of UObjects we strip during cooking for things like materials and particle systems) and the concept of gc clusters, where you can opt in and say ‘this island of objects should be treated as a single object cluster for the purposes of GC’ which can help a lot when you have a densely connected subgraph of object references that only has sparse external connections.
Load time is the major component of editor startup times on any non-trivial project even with an SSD, so it’s certainly still important to keep loaded assets around to some degree. I suspect it was also done so that asset editors don’t need to worry about the asset being unloaded out from under them, although it’s certainly feasible for the editors to keep a strong reference to them directly (and most recent editors should be doing this anyways). I don’t think we have any plans to change this (stop using RF_Standalone) right now, but I’d recommend posting this to the Feedback forum as it’s own request, since it would certainly be useful to have something like an ‘unload un-needed assets’ command that drops the flag and does a force GC to get you a bunch of memory back quickly.
Vulkan should work fine on Windows 7, right? So it’s Vulkan for Windows 7, 8, 10, Linux, Android and Metal for iOS and Mac. How long will it take until the Vulkan implementation is roughly same far as DX12? I’ve seen a lot of commits in github regarding Vulkan, but I don’t know how finished the implementation really is. Can I enable it experimentally in 4.11 or 4.12?
What a pity, I hope there will be improvements in the future. Performance with destructibles is a bit problematic at the moment.
RE: Destructables, are you seeing problems with render / GPU perf or CPU perf? For my global game jam game this year (http://globalgamejam.org/2016/games/unstoppable-grave-looter) we used destructible meshes for the graves and were initially having bad GPU perf problems but mostly solved them by using a unfractured static mesh until we started the destruction (the fracturing was bloating the triangle count of each tomb and also massively increasing the cost to render the shadows for the skinned mesh). We just set up a destructable blueprint that had both the static mesh component and destructable mesh component and an event to trigger the fracture hiding one mesh and showing the other IIRC (NickD wrote that bit so I don’t remember the details).
Swapping them out was a huge win. The original grave stone mesh was something like 1,000 polys, once I fractured it, it became a something like 13,000 polys and I’m guessing it goes through a more expensive rendering pipeline that expects a hugely dynamic skinned mesh being updated. If someone can go around your level sort of plinking lots of little surfaces your perf would eventually drop too low, but if you use them like us where it’s just for a temporary explosion of all the things, and then have them disappear a few seconds later, it’s a huge win. Especially since we had a large shadow casting light in the scene, so not only were we originally having to render 13,000 poly meshes in the view, but then they had to be rendered from the standpoint of the dynamic moon directional light - which was pretty expensive on my macbook pro. I’m guessing we had around 100 grave stones in the map.
Ok, maybe someone else who knows more about the Vulkan integration in UE4 can comment on it :o
The problems I remember were only with the game thread, not the GPU. I am already spawning the destructible mesh the second the mesh got hit by something, so it’s only around if it needs to be. And there’s one little annoying bug with this, the frame the DM is spawned it’s actually invisible. This bug got introduced in 4.8 or 4.9, and you seem to have workarounded it with just switching visibility of regular mesh and DM instead of spawning it, but in my case that does not work. I guess you had GPU perf problems.
For better performance I am also killing the debris immediately and instead spawn my own physics objects there so that I have full control about when and how to fade them out. The problem I have is that I need the “Form Extended Structures” feature enabled, and it causes hitches between 200ms and 1000ms if you spawn one DM with “Form Extended Structures” enabled close to another DM. And hitches of up to 1 second don’t feel that good in a game.
The other huge problem were that once you reach a certain number between 8000 and 9000 fractures in your whole scene, the performance suddenly decreases a lot for a few frames after you added more fractures. And this affects GPU time even more than CPU time. Almost as if there is some hard coded value between 8000 and 9000. The game basically becomes unplayable after you reached that number.
