[=Link_AJ;618427]
Is there an estimation date for the full release for 4.14? I’d love to get started with Forward Rendering in my actual project.
[/]
About two or three weeks from now.
Cheers
I’m sorry guys but for the first time since I signed up in these forums, permit me please to give you a little bit of rant.
This is not to offend anyone, or to open a can of worms, but I just felt like getting something out there after watching the latest live stream and a few others in between.
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”.
Now maybe at some point in the future of course all these points will be further clarified. But we couldn’t help but notice that a significant portion of your time in these very precious live stream videos are sometimes spent on things like VR landscape editing at the expense of those other important features, I would love to know how this benefits a real world production environment when any experienced artist can paint that landscape before the person puts the headset on. And if in reality someone is going to be putting a headset on to paint a landscape like that in a tight production pipeline then he or she would most probably be in trouble with the upper management for “slacking”, or with their colleagues who would be busting their butts to get the job done and would hold this person’s ears tight and drag him back to his chair to start working again.
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.
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.
Thanks again though for the effort of the team at Epic and all you guys, please don’t think that we don’t appreciate everything you are doing for the community. I just wanted to speak my mind and on behalf of many as well who feel this way from my colleagues and otherwise.
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.
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]
[]
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”.
[/]
Hi . Thanks for the feedback. I think the main reason you may get this impression from the Twitch streams is because Fricker (who speaks on the Preview/Release streams) is currently focused on VR development, so he’s talking on the topic he is most familiar and enthusiastic about, and is providing less information on the areas he’s less involved. This isn’t a company-wide directive, just the case of a person discussing what they know. I’ll share your feedback with our Community team coordinating these Twitch steams to see if we can mix it up.
[]
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?
[/]
I’ll get that information shared here.
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 
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 
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.
[=;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
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
[/]
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… ??