Digital Foundry Article Technical Discussion [2019]

Status
Not open for further replies.
Maybe you can spend some time answering my question?

Here's a couple of videos that would be a good place to start on the changes they're making.




This is a nice overview by a Unity employee
http://lucasmeijer.com/posts/cpp_unity/

And another blog by the same employee about what's happening in the future
http://lucasmeijer.com/posts/whats_next_after_burst/

This is a demo scene built using some of the new unity concepts. It runs on a mobile phone.

They've also recently hire a bunch of people like @sebbbi . My guess is he's there to start transitioning the renderer to fit the new unity concepts, like using Burst and a data-oriented approach.

In short, they're changing Unity so it'll be more similar to what a AAA studio would use internally, while keeping it easy to use. It's been transitioning for a little over a year, I think.
 
Last edited:
I've worked on UE4 projects directly with Epic & with studios working exclusively on it, have had access to both PS4 SDK & MS's XDK which means that I have a fairly good grasp on how things work internally... Your experience as an end-user is in no way, shape or form, an indication on the viability of the engine as a great development platform especially for non AAA devs.
That doesn't make your previous statement correct though, seeing the examples I provided your statement is factually incorrect. There are many UE engine games that work fine on consoles. Most of them are actually.

BTW the only version of the engine which has great DX12 implementation is MS's own internal branch.
Great, at least there is a branch of it that is of good quality in DX12, something most other engines lack.
Considering what's on-screen, load times are pretty abysmal for a lot of these
Loading times are always a problem on consoles, whether UE engine games or otherwise. But I agree, loading times can be relatively longer with UE games on consoles, though we were not originally debating the loading part, but rather how UE games perform (fps wise) on consoles.

Even on PC there can be extended loading times with certain games, examples that come to mind: Battlefield 4, Battlefield 1, Kingdom Come, and Dragon Age Inquisition, those games have epic loading times on PC.
 
That doesn't make your previous statement correct though, seeing the examples I provided your statement is factually incorrect. There are many UE engine games that work fine on consoles. Most of them are actually.


1) The subject wasn't only how good UE4 games run but how hard it is to make them run decently for non triple AAA developers.
3) You listed 14 games out of which 6 are fighting games (not really the most graphically intensive or advanced content..). One of those is a UE3.9.X game (Mortal Kombat), and one of them having abysmal IQ and relatively poor performance (Tekken 7). One developed by the engine's creator (Paragon). Another heavily modified UE3.9 game (Batman one of my fav games this gen...but let's not talk about the PC version..). Another UE3.9/4 game (The Vanishing of Ethan Carter Redux which is a UE4 port of the original 3.9 game and far from graphically intensive game as most of everything was totally baked content). 2 MS games, two of which uses Microsoft's heavily modified branch (Gears & SoT). Undead Labs's State of Decay which runs like ass and looks like..(and AFAIK doesn't run on the same UE4 branch as Gears & SoT). Finally Hellblade which was literally co-developed by Epic (most of the engine work and optimization was done by them & their partners at 3Lateral and Cubic Motion) as it was used by the company as a marketing tool to promote Epic's Unreal Enterprise foray into virtual cinematography and DCC business from 2016 to 2018. But anyway.. we have reached Listwarz level of pettiness right now.

Great, at least there is a branch of it that is of good quality in DX12, something most other engines lack.

A branch that is proprietary to Microsoft...and is only useful to Microsoft's 1st party games.

UE4 isn't a bad engine per se..it's awesome for lookdev and technology showcases..which is literally what is always shown/used to pimp it out. As Scott Arm said earlier: Smoke & Mirrors. Nearly a year has passed since the Epic's GDC keynote showcasing DXR and you have yet to see a trace of it in the engine. It was promised to devs that early support only for RT shadows will be released in Q4 2018 with more later in 2019 (Reflections etc) but nothing yet. As it's usually the case with them..but it was good marketing... Epic loves to evangelise it to AA, Indie devs with BS like "You don't need to know code, you can to everything in Blueprint". Yes everyhting and then have a shitty running game...Artist are not developers but unfortunately Epic wants them to believe that they are...UE4's documentation is trash (yes even compared to Unity) and their paid dev support portal (Thousands of $/€ for one single seat access to a bloody support forum!!) is also trash because they either ignore the posts or simply can't answer most of the time (unless you are Sebbii and actually know more that the guys coding the engine...then they will be their for you 24/7). It was sometimes funny/scary to see panicked/desperate posts from Namco, Square Enix, Starbreeze other big house devs. Made you feel good knowing that you aren't the only one wondering WTF this or that never works..

In the case of AC7, the main culprit, if I had to guess, would probably be the use of SimulSky's UE4 plugin (same tech used in DriveClub & other games) which can easily trash performance in no time. But here's the interesting part (I'm no longer NDA'd): SimulSky is literally part of the PS4 SDK in the dev portal (it stil was 9 months ago last time I checked..no longer have access to it unfortunately). Which makes me think that maybe this is why we are seeing the shoddy performance results on Xbox versions vs PS. Sony probably has their tech heavily optimized for the HW given that they are including in directly in the SDK. State of Decay 2 on Xbox also uses it IIRC..
 
Last edited:
Tekken 7 runs fine, Batman Arkham Knight runs fine, Injustice 2 runs fine, Hellblade, Mortal Kombat, Dragon Ball FighterZ, Marvel vs. Capcom: Infinite, Paragon, Rime, Street Fighter V, The Vanishing of Ethan Carter Redux, State of Decay 2, Sea Of Thieves, all the Gears games, and many others run fine. And I am sure Days Gone and Crackdown 3 will run fine as well.

Many of the games you mentioned don't run on UE4 but on an improved version of UE3. Batman and Injustice 2 for instance.

Most multi games have disappointing performances with UE4 on consoles. The notable exception being the exclusive games which are well optimized (Gears games, etc).

There are some amazing multi games on UE4, but those games tend to be more simplistic such as fighting games. DBZ is a good example of that.
 
Apparently there are no comparable games to AC7 running on Unity.* And Unity's way forward is to have a separate compiler and memory model for code that has to be performant (and you can only run performant code inside special jobs with their own memory space). Seems really messy.

* And if you bring that up the mods delete your post.
 
Apparently there are no comparable games to AC7 running on Unity.* And Unity's way forward is to have a separate compiler and memory model for code that has to be performant (and you can only run performant code inside special jobs with their own memory space). Seems really messy.

* And if you bring that up the mods delete your post.
You really feel strongly about this one, don't you? No disrespect intended and I hope y'know I love and respect you and ask this with no animosity and only curiosity; why? :|
 
Apparently there are no comparable games to AC7 running on Unity.* And Unity's way forward is to have a separate compiler and memory model for code that has to be performant (and you can only run performant code inside special jobs with their own memory space). Seems really messy.

* And if you bring that up the mods delete your post.

Is this real? Tuna complaining about messy software? The same tuna giving me a hard time on the other thread for doing the same thing? Who told me to fix it myself. Why don't you fix unity yourself as well.

*I'm just joking, please don't read this as serious.
 
Here's a couple of videos that would be a good place to start on the changes they're making.




This is a nice overview by a Unity employee
http://lucasmeijer.com/posts/cpp_unity/

And another blog by the same employee about what's happening in the future
http://lucasmeijer.com/posts/whats_next_after_burst/

This is a demo scene built using some of the new unity concepts. It runs on a mobile phone.

They've also recently hire a bunch of people like @sebbbi . My guess is he's there to start transitioning the renderer to fit the new unity concepts, like using Burst and a data-oriented approach.

In short, they're changing Unity so it'll be more similar to what a AAA studio would use internally, while keeping it easy to use. It's been transitioning for a little over a year, I think.
@sebbi is working in the Unity team now?? This sounds good!

It's also interesting to know from the articles that current Unity project will benefit from the new compiler too, performance wise.

So you can mix & match. What’s great about that is you can already reap the benefits of burst codegen, and ECS performance for your game code, instead of having to wait for Unity to ship pure ECS versions of all subsystems.
 
@sebbi is working in the Unity team now?? This sounds good!

It's also interesting to know from the articles that current Unity project will benefit from the new compiler too, performance wise.

Yes. I'd say in a couple more years Unity will be much closer to what an internal AAA engine would look like, and have performance approaching a AAA engine. I'm not sure what Unreal Engine is going to do. I know Tim Sweeney voiced skepticism of going full data-oriented for even generic gameplay code, but there's probably some middle-ground they could go for.

Edit: The situation right now, which I haven't used, means you can start writing ECS code, burst compiler code, but there's some ugliness in getting systems to work between old and new.
 
Last edited:
Finally Hellblade which was literally co-developed by Epic (most of the engine work and optimization was done by them & their partners at 3Lateral and Cubic Motion) as it was used by the company as a marketing tool to promote Epic's Unreal Enterprise foray into virtual cinematography and DCC business from 2016 to 2018. But anyway.. we have reached Listwarz level of pettiness right now.

Quoting myself here (bit OT)..Epic just announced the "acquisition" of 3Lateral which..one can say..has already been part of Epic (unofficially) for a while now (90% of there projects since 2016 have been commissioned by Epic)...
https://www.unrealengine.com/en-US/...-twitter&utm_medium=social&utm_source=twitter
 
Last edited:
Yeah, Unity picked quite a lot of performace oriented talent recently. Aside Sebbi they've got Cort Stratton and Bryan Mcnett from Sony ice team , Mike Acton and Andreas Fredriksson from Insomniac.
Epic also started its hiring spree a bit more than 12 months ago with Emil Persson (aka @Humus) alongside a couple of Dice/Seed folks (Sebastien Hilaire being the most recent one). From the looks of it they really wanted Sebbi (given all the work he "did for them" when developing Claybook) but Natalya Tatartchuk (ex ATI/AMD & MS/Bungie) gave him a sweeter deal a Unity.
 
@Ike Turner The bigger story is definitely the amount of talent leaving big AAA studios, especially EA seed, frostbite. Everyone going to Epic and Unity. Curious if Unity tries to make a game internally. Best thing that happened for rapid improvement of UE4 was fortnite and to a lesser extent Paragon.
 
One issue with an engine dev making a game is they tend to prioritise the engine in favour of their game, which can weaken it for other styles. However, it'd be nice to have a number of in house dev teams using the engine inside and feeding back if that can get better fixes than the current community-led requests and bug reports. Having a significant bug like a physics glitch hang around for 6+ months is really painful for product launches and those issues would get fixed if in-house teams were dependent on them. But then you have the issue of the engine dev competing with its users which is very conflicting and potential hazardous for the community.

On reflection, in-house games is probably a bad choice. Better community feedback and iteration with better prioritise is the ideal. Squash game-killing bugs before adding fancy new features.
 
Status
Not open for further replies.
Back
Top