Unreal Engine 4.14 Preview

Hey , thanks for sharing the feedback. Let me see if I can address some of your concerns:

[]
It concerns this VR trend that’s going on. Now, maybe there are some serious VR evangelists out there who may come at me with pitchforks and spears, not that we have anything against VR on the contrary more categories of games to work on in the future. But it is undeniably upsetting for some of us when in brief something like the following happens:

You guys spent relatively a long time talking about how you can do VR landscape editing inside unreal editor, but when it came to the production features we wanted to see talked about (and in our humble opinion would benefit a real world environment comparatively speaking), such as things for characters, like talking more about Physx improvements in 4.14 in more detail, (upcoming IK stuff perhaps), skinning improvements, cloth, about morph targets and a bunch of other things that were on that list before the stream ended, you simply “ran out of time”.

[/]

While VR is of huge importance to Epic Games and very, very many UE4 developers, we’re totally stoked for all of the features heading to 4.14 that will benefit both VR and non-VR projects, and there will be a lot more info once the release is ready to go. When putting notes together for the Preview livestreams, we work from what is already well captured by our development leads and work from there. The items at the end of the segment were not back-burnered for time’s sake necessarily, but often times we go as deep as we can on all topics that are ready to be discussed to a certain depth. There are a ton of new features that we were happy to share with the community yesterday such as the Auto LOD tools, Static Lighting Scenarios (which are awesome), the revamp of our Animation editor(s), Live-GPU profiler and more. Expect more information on the rest of the items listed in the full release notes and other avenues post-release!

As we move forward toward future releases, we want to ensure we’re hitting the right notes for the community of developer out there. What sort of things were you looking for specifically in a Preview livestream?

[]
I’m not saying these are bad features or it should not be talked about. However talking about these at the expense of much much more important features that need to be talked about especially when time is limited and tutorials are scarce, seems to many of us, if you would excuse the term and with all due respect of course, a “VR PR stunt” and to many if we dare call it as it is “a gimmicky feature” sorry if this sounds a little out of place. And to us a wasted precious time from the Epic staff presenters who can share their knowledge with us on more important points even if it’s for 5 mins, which can go a long way.

[/]

We’re currently building a roadmap of great content aimed at going deeper on the core features of the release as we normally do once a production build is in the wild. These Preview livestreams are not built with an aim to serve that need necessarily but to give everyone insight into what’s next. We hope you’ll get greater value out of the things to come.

[]
I’m sorry maybe some of us are seeing this differently and hoping for maximum amount of solid info within this given limited time, maybe we are in the minority or behind the times : ), but we just couldn’t help it and we wanted to get this point out there.

[/]

No apology necessary :slight_smile: We’re always looking for ways to improve and to know what you’re looking for in the content that we share. As we build the engine for games and experiences of all types, there is never a shortage of new updates to cover and posts like this help us better understand what’s important to the development community.

[]
For the record if the Staff members themselves feel obliged and genuinely excited to share these features on stream despite the above then of course it is their full right. Also all this (however we think is significant or insignificant within production) may be within the direct interest of Epic itself and their target line and goals for various reasons (whether it’s PR, production or otherwise) we respect all this entirely, just sharing a thought for the moment.

[/]

Our goals are to empower others to be successful with Unreal Engine. What we aim for in both the Preview releases themselves and our overview livestreams is to give people insight into what is to come, gather feedback on functionality and answer questions about where we might be going next. We’re all ears for feedback on our efforts to help you achieve your goals!

[= Ellis;618654]
About two or three weeks from now.

Cheers
[/]

New 4.14 under the tree! Epic Games = Santa :smiley:

Thank you and Ivey for your quick consideration and clarifications, we understand entirely your approach and position, and appreciate the time you have taken to clarify these points to us.
Wouldn’t wish to take more of your time on this matter, looking forward to your future streams and documentations on the new features to come.

Thanks again and a good day to you all.

Any plans to fix these issues for 4.14 ?

Wheeled Vehicle

4.14 V2 N wheeled support,

Trying 4.14 to see if “N” wheeled vehicles now work…

Sorry to say for me they do not, any more than 4 wheels listed in the Movement Component of a UWheeled_Vehicle BP … the wheel collisions disappear.

Also any less than 4 wheels listed then the vehicle refuses to move.

48hrs of trying in 3 different vanilla projects and the result always the same.

UVehicle Wheel … collisions appear to be a single point below the wheel centre , so what is the point in having a wheel width parameter ?

I also tried experimenting with the USimpleWheelMovementComponent but could not get it to move… will wait for some documentation

To test place any 4 wheel vehicle in game set PXViS collision and you will see the Vehicle Wheel collisions generated .
Add an extra wheel in the movement component , collisions are now not there .

Regards

G

After updating to 4.14p2,I have come across several BUGs on mobile:4.14 rendering BUG on mobile - Rendering - Epic Developer Community Forums

Thanks a lot!

I too share every point brought forward above to the point of me feeling a need to post just to say just that. It’s just starting to feel a little bit too much like bulletpoint salesmanship a la Autodesk. That probably sounds harsher than how I meant it, but I’m just starting to feel a disconnect to real world scenarios. Maybe we’re wrong and artists will truly put on headsets and work away, and maybe it’s just fun and exciting tech.

Either way, Unreal is still awesome. :slight_smile:

[=;618877]
Mobile games ship with Vulkan support and can now be enabled or disabled using device profiles, with fallback to ES 3.1 and ES2
How can I enale that?is there a step by step tutorial?Thanks! [MENTION=9] Ellis[/MENTION]
[/]

Hi ,

If you check the checkboxes for Vulkan, ES2 and ES 3.1 in the Project Settings, Android page, when you cook content it will build and package shaders supporting all three targets. Then when you launch on a device it does the following:

  • Checks to see if Vulkan is available, and gets the Vulkan version from the device
  • Gets the OpenGL version and driver strings, and checks to to see if the device supports OpenGL ES 3.1
  • Runs the device profile matching rules. These can match different rules based on the OpenGL and Vulkan version strings as well as the GPU type and model number.
  • Runs any console commands for the matched device profile.

If the device supports Vulkan, and the console variable “r.Android.DisableVulkanSupport” is not set to 1, then Vulkan is used.
Otherwise, if the device supports ES 3.1 and the console variable “r.Android.DisableOpenGLES31Support” is not set to 1, then the OpenGL ES 3.1 is used.
Otherwise ES2 is used.

So with that you can set up device profile matching rules to disable Vulkan on specific devices. We do that in 4.14 BaseDeviceProfiles.ini for Mali T8xx devices with a Vulkan driver less than 1.0.11, (profile name is Android_Mali_T8xx_No_Vulkan). During testing, if you came across another Vulkan-supporting device that didn’t work with your game, you could make a device profile rule that matched it and then set +CVars=r.Android.DisableVulkanSupport=1 for it. You could do the same to disable ES 3.1 for a particular device.

  • Jack

Just a simple question…

When will multi-threading be fully supported? By that I mean fully optimized usage across all cores and not just on one as several gamers and benchmarks have actually revealed.

[=Runreal_;619538]
Just a simple question…

When will multi-threading be fully supported? By that I mean fully optimized usage across all cores and not just on one as several gamers and benchmarks have actually revealed.
[/]

I am not quite sure what specifically you mean, since multi-threading can be done in a lot of areas.

If you mean the renderer itself, that will become more multi-threaded with DX12 and Vulkan, since only those APIs were really designed for multi-threaded access to the GPU. So the load you currently have one the one render thread will be spread better in the future when support for those new APIs is done.

The game thread however is a different thing, and there its usually up to you to write your own code in a multi-threaded way using classes like FRunnable. If you however talk about some specific framework part that is not multit-hreaded enough, like CharacterMovementComponent or something like that, there it’s obviously up to Epic to do that. But those stuff is usually quite optimized already.

So maybe you should ask more specifically about the area where you currently miss multi-threading :slight_smile:

I know it’s probably be impossible. But can you guys add blending between lightmaps to the engine? I think Mr. Fricker likes a challenge and is up to the task I saw it in the stream.

Thanks

[=;619568]
I am not quite sure what specifically you mean, since multi-threading can be done in a lot of areas.

If you mean the renderer itself, that will become more multi-threaded with DX12 and Vulkan, since only those APIs were really designed for multi-threaded access to the GPU. So the load you currently have one the one render thread will be spread better in the future when support for those new APIs is done.

The game thread however is a different thing, and there its usually up to you to write your own code in a multi-threaded way using classes like FRunnable. If you however talk about some specific framework part that is not multit-hreaded enough, like CharacterMovementComponent or something like that, there it’s obviously up to Epic to do that. But those stuff is usually quite optimized already.

So maybe you should ask more specifically about the area where you currently miss multi-threading :slight_smile:
[/]

Thanks for the reply !

Yes, I think what I was referring to is the renderer API being multithreaded. UE4 is a resource heavy engine and not every individual can really run it on maximum settings on just one thread. I asked this in context of Squad, which you can visit at www.joinsquad.com. One of the guys there did a detailed CPU usage analysis and what he found was almost 70% of the load being on just one single thread. Squad is perhaps the only UE4 title that uses extensive engine features. I don’t own the game but I’ve been looking forward to buying it in the future post some hardware upgrades. Multithreading support has been somewhat vocal in their forums since quite a lot many powerful CPU owners too have expressed dissatisfaction in performance and core usage and developers’ efforts remain limited since its an API issue. But many even doubt DX12’s multithreading support. Are you sure introducing it will make a certain difference? Vulkan seems very promising though.

[=JackP;619521]
Hi ,

If you check the checkboxes for Vulkan, ES2 and ES 3.1 in the Project Settings, Android page, when you cook content it will build and package shaders supporting all three targets. Then when you launch on a device it does the following:

  • Checks to see if Vulkan is available, and gets the Vulkan version from the device
  • Gets the OpenGL version and driver strings, and checks to to see if the device supports OpenGL ES 3.1
  • Runs the device profile matching rules. These can match different rules based on the OpenGL and Vulkan version strings as well as the GPU type and model number.
  • Runs any console commands for the matched device profile.

If the device supports Vulkan, and the console variable “r.Android.DisableVulkanSupport” is not set to 1, then Vulkan is used.
Otherwise, if the device supports ES 3.1 and the console variable “r.Android.DisableOpenGLES31Support” is not set to 1, then the OpenGL ES 3.1 is used.
Otherwise ES2 is used.

So with that you can set up device profile matching rules to disable Vulkan on specific devices. We do that in 4.14 BaseDeviceProfiles.ini for Mali T8xx devices with a Vulkan driver less than 1.0.11, (profile name is Android_Mali_T8xx_No_Vulkan). During testing, if you came across another Vulkan-supporting device that didn’t work with your game, you could make a device profile rule that matched it and then set +CVars=r.Android.DisableVulkanSupport=1 for it. You could do the same to disable ES 3.1 for a particular device.

  • Jack
    [/]

Hi Jack, the Vulkan checkbox still need to be compile from source? as it is still greyed out.

[=dizzynoob;619687]
Hi Jack, the Vulkan checkbox still need to be compile from source? as it is still greyed out.
[/]

Hi, For now that seems to be the case, but I don’t believe this is intentional because we ship the Vulkan Android library binaries in 4.14 preview 2. This should be everything that’s needed. I’ve entered ticket UE-38304 to fix this.

  • Jack

[]
Skeletal Mesh to Static Mesh Conversion lets you right-click actor(s) in the level viewport and convert their current state to a new Static Mesh asset.
[/]

I realize this will probably be 4.15, but is there any way we can get this same feature working on spline meshes? I heard right now each segment of a spline mesh costs separate draw calls. There is an FBX export option, but it would be nice to do it all in editor to preserve material assignments, etc.

Am I the only one who thinks some changes to the new static mesh editor are confusing?
With the new setup, you have to keep the ‘material’ section open and the ‘lod0’ section at the same time when making changes. You are going back and forth between the two…
If you want to make some changes, you use ‘highlight’ from the ‘Lod0’ section to make sure you are targeting the right element, next you go to the ‘Materials’ section and change a material, go back again to the ‘lod0’ section etc etc…
I must be missing something… ??

Windows build 14959, Preview 2, Visual ‘15’ Preview 5.

Can hot-compile/reload the C++ in-engine, build it from VS 15, etc. When I try to build the project though, I get this:



UATHelper: Packaging (Windows (64-bit)): Running AutomationTool...
UATHelper: Packaging (Windows (64-bit)): Automation.ParseCommandLine: Parsing command line: -ScriptsForProject="C:/Mage Duel/MageDuel.uproject" BuildCookRun -nocompile -nocompileeditor -installed -nop4 -project="C:/Mage Duel/MageDuel.uproject" -cook -stage -archive -archivedirectory="C:/Users/matty/Documents/AIE/Major Production/Builds/MageDuelBuild-v0.11" -
package -clientconfig=Shipping -ue4exe=UE4Editor-Cmd.exe -compressed -pak -prereqs -nodebuginfo -targetplatform=Win64 -build -CrashReporter -utf8output
UATHelper: Packaging (Windows (64-bit)): Automation.Process: Setting up command environment.
UATHelper: Packaging (Windows (64-bit)): CommandEnvironment.SetupBuildEnvironment: WARNING: ERROR: NOTE: Please ensure that 64bit Tools are installed with DevStudio - there is usually an option to install these during install
UATHelper: Packaging (Windows (64-bit)): CommandEnvironment.SetupBuildEnvironment: WARNING: Assuming no compilation capability.
UATHelper: Packaging (Windows (64-bit)): BuildCookRun.SetupParams: Setting up ProjectParams for C:\Mage Duel\MageDuel.uproject
UATHelper: Packaging (Windows (64-bit)): Project.Build: ********** BUILD COMMAND STARTED **********
UATHelper: Packaging (Windows (64-bit)): Program.Main: ERROR: AutomationTool terminated with exception: AutomationTool.AutomationException: You are attempting to compile on a machine that does not have a supported compiler!
UATHelper: Packaging (Windows (64-bit)):    at AutomationTool.UE4Build.Build(BuildAgenda Agenda, Nullable`1 InDeleteBuildProducts, Boolean InUpdateVersionFiles, Boolean InForceNoXGE, Boolean InUseParallelExecutor, Boolean InForceNonUnity, Boolean InForceUnity, Boolean InShowProgress, Dictionary`2 PlatformEnvVars, Nullable`1 InChangelistNumberOverride, Dictio
nary`2 InTargetToManifest)
UATHelper: Packaging (Windows (64-bit)):    at Project.Build(BuildCommand Command, ProjectParams Params, Int32 WorkingCL, ProjectBuildTargets TargetMask)
UATHelper: Packaging (Windows (64-bit)):    at BuildCookRun.DoBuildCookRun(ProjectParams Params)
UATHelper: Packaging (Windows (64-bit)):    at AutomationTool.BuildCommand.Execute()
UATHelper: Packaging (Windows (64-bit)):    at AutomationTool.Automation.Execute(List`1 CommandsToExecute, CaselessDictionary`1 Commands)
UATHelper: Packaging (Windows (64-bit)):    at AutomationTool.Automation.Process(String] Arguments)
UATHelper: Packaging (Windows (64-bit)):    at AutomationTool.Program.MainProc(Object Param)
UATHelper: Packaging (Windows (64-bit)):    at AutomationTool.InternalUtils.RunSingleInstance(Func`2 Main, Object Param)
UATHelper: Packaging (Windows (64-bit)):    at AutomationTool.Program.Main()
UATHelper: Packaging (Windows (64-bit)): Program.Main: AutomationTool exiting with ExitCode=1 (Error_Unknown)
UATHelper: Packaging (Windows (64-bit)): BUILD FAILED
PackagingResults:Error: Error Unknown Error


No issues with Preview 1. Also had issues where I have to manually add Include/Library “UniversalCRT” Visual C++ Directories to my project to get the engine to compile and run in the first place. All preview 2.

I’ve reinstalled VS 15, Windows SDK’s, etc. Also deleted Intermediate/Saved folders, .VC db files and the solution and regenerated it from scratch. None of that fixed these errors.

so i want to add a instanced level after i baked lights,can i spawn a duplicate of levels with offsets that have the lightmaps,in 4.13 i think i can do that but can i do that in 4.14

MSAA performance

MSAA has a big performance impact on our VR project. We noticed that Scene Resolve and Depth Resolve are performed 4 and 2 times respectively.

https://s21.postimg.org/iphi8tpaf/Resolves.png

Do we have any control over this? Can we tweak our project in a way to reduce the number of resolves?

Why is there a resolve for both views in the translucency pass?

And is the resolve after the distortion pass really necessary?

Auto LOD THANKS GOD!! i’ve just tested it out and it is so usefull for props , it saves me so much time guys! looking forward for full release