Unreal Engine 5 = Game Changer

I am really wondering what unity tech will do in future about lighting =)

 

Can I write in C#?

 

While I also think that this is an awesome Demo, I believe some people are overestimating the role of the engine in this scenario. There is no magic algorithm or something like that. It's simply possible because the hardware architecture of the PS5 allows to stream these massive amounts of data in realtime. Why do you think this shouldn't be possible with Unity too?

 

A lot of people making the point it's a demo with all the caveats involved. But what really matters is the core approaches being used/implemented. That those are actually possible with the engine. That it's not very accessible to hobbyists/amateurs due to lack of knowledge/experience is another thing.

Where Unity is in terms of optimizing their rendering pipline in this area is years behind Unreal. It basically puts Unity back to where they were pre SRP. Always playing catchup never leading. It's their own fault for losing their focus on games. You can't focus on other areas and still lead in games when you have someone like Epic to compete with that is laser focused on doing one thing well. Not too mention the market share Epic has and all of the direct feedback from people making production games.

Which isn't to say Unity isn't getting a lot better. It's just realistically never going to compete on high end PC games unless they make a significant change in strategy.

 

As of late Unity has been more of a challenge to use than ever before. Since the move to yearly versions, I have experience nothing but stress using Unity. My experience before was clean and predictable. Now, its things randomly breaking, searching for answers to mundane problems, features perpetually in preview, when not in preview still broken. I now understand why some studios jumped ship. This is simply not sustainable.

 

I understand the praise here for Epic's work, but I don't get the hate in this thread for ECS. Was honestly confused to see that here. I didn't realize ECS was seen as "a mess" be some of the community. It's really not - it's very intelligent stuff. It's just still in development. The unusual thing here is that we get to see it's development, and be part of that process.

 

Unreal has also branched into the same domain unity has, except maybe ML for all I know. But they do architecture, cinema (mandalorian was made with unreal), VR etc ...

 

There is no hate for ECS here, just an understanding that it is still not production ready and still relies on a lot of boilerplate code despite being in preview for going on two years now. That is well worth being apprehensive about, especially when Monobehaviour still has a dramatic ease of use benefit.

 

If I understood this correctly, they worked from September to March on the tech demo with 2000 people being involved? He mentioned it at around 48:15.

 

While the PS5 may have been the platform they chose to show off the technology, a modern PC is not that far behind it right now and very soon will be surpassing it in raw bandwidth. The PS5 is 5.5 GB/sec compared to the current PCIe 4.0 SSDs which are 5 GB/sec but there is at least one upcoming drive able to do 7 GB/sec.

By the time the technology catches on PCs will have caught up to where they need to be to handle this technology.

This. Meanwhile Unreal doesn't have an equivalent framework because it doesn't need an equivalent framework to achieve good performance with large scale worlds.

Except it's not that unusual because you can do the very same thing with the competition. Both Unreal and Crytek are on Github with full source code available. In fact we can only somewhat be part of the process with Unity thanks to them relying on special preview builds rather than giving us access to the active development branches of the engine.

 

True but what impact has that had in terms of stealing focus away from games? Epic is very consistent throughout in games are their focus. Unity is all over the place. That an engine is used for X isn't the strongest indicator of what they are best at or where their primary focus is.

Unity's demo's try to hit a far larger audience. The ones that are showing gameplay are simplistic. Just put aside the bleeding edge tech aspect Unreal makes stuff that looks more like what you see in a game just in terms of the content. Epic has that connection to games that Unity doesn't.

You see that connection at almost every level. It's in their development process, what they prioritize is closer aligned to what people making games need. Not just features but in areas like not leaving weak links for months that make a feature untenable. Lots of little areas where I think it becomes obvious Unity doesn't get it.

 

They said about 2 dozen.

 

Epic has been slowly working towards their engine being viable for non-game use cases.

https://www.unrealengine.com/en-US/events/build-for-architecture-2020
https://www.unrealengine.com/en-US/events/build-for-automotive-2020
https://www.unrealengine.com/en-US/events/unreal-film-jam

 

The real truth is that unreal make money by making games, unity doesn't, that free engine (no) money bite them in the ass, unreal don't have that concern. That fortnite sweet sweet money do help unreal a lot. Unity has ads and subscription ... They are on a hell treadmill just to keep existing.

Making games mean all part must connect together, and all people work for a common goals, each unity's section work on its own goal independently of each other, they have a structural failure.

 

While Unity has been struggling with the New Input System for the past couple of years, Epic has been working silently to blow us all. I don't even want to talk about DOTS. I'm pretty sure it will have a Preview or fake-Production-Ready by the time UE5 comes out.

I still love C# and I think there is a place for Unity though. You don't need Excaliber to peel an apple.
Unity needs to admit that they will never get hold of Excaliber and to stop chasing after Epic to compete in high-end such as Automotive, VR, Architecture, and stuff. Thanks to C# and Unity has an opportunity to make small-sized games faster. However, it's a constant struggle if you try to push it to make a medium-sized game where you have to fight the sluggish Editor every day

To summarize, this is what Unity needs to focus on.

1. Make the Editor performant, not just the Runtime. Start "Performance by Default for Editor!" campaign immediately and everyone will benefit instead of the few interested people for DOTS. In order for that to happen, you will need to port the Editor to .NetCore and there is no other way. Don't wait for .Net5. .NetCore 3.1 is already very capable and .Net5 will be just a superset of .NetCore 3.1. You will have to admit that you won't find any rat-hole you can hide.

2. Stop making Eye-candies. Yeah, I'm impressed so stop it now. If you want to impress others, make a real AAA game.

3. Improve Editor workflow now. There are small but very annoying workflow flaws laying for years and years. Fire everyone if they don't see it. Grab the low hanging fruits while you think of something grandiose.

4. Put DOTS on a separate branch. It will not be relevant for a few years and not every game needs DOTS but it seems like it pulling all of our legs.

Well, I know they won't listen but I have to keep trying. Cheers!

 

Honestly the only reason I haven't jumped ship 1+ years ago is - I've just invested so much time and sank so much money into Unity, and C#.

But eventually I might just jump ship myself. I love Unity to death, but if they believe in their product enough they should finally just make their own game and show the world what Unity is actually capable of with really extremely talented people on a scale that makes a game, a game. Don't take me wrong, their videos are nice, but that's not a game. I mean yes there are AAA studio's who use Unity, but they are so far and few between that the ones you know are Unity don't look like AAA next gen beasts, they look like cartoons or card games.

Again, I love Unity, but I'm tired of preview this, preview that. Finally getting terrain stuff, and yet - still no terrain in HDRP that works with grass. All these employees and sooooo many projects how about consolidate them into things that matter - right now. Give DOTS a break for a couple months and throw these hundreds of employees onto breaking edge features, like terrain grass, because it's a hard thing to implement apparently.

 

No, and that you're suggesting it shows how little you understand of the real problem with the editor. The scripting framework was never the problem here. The problem is with the UI framework. IMGUI is basically the equivalent of OpenGL's immediate mode but for UIs. It was horribly inefficient and everything was built with it in mind.

Unity's editor will have good performance eventually but it's going to take until UI Toolkit is ready for production.

 

Epic is a market leader in high end games Unity is not. It's far easier for a company in Epic's position to branch out and keep the lead in their core competency. Unity is in a very different position and also like @neoshaman mentioned just structured very differently. For Unity to compete with Epic at the same level would I think require major restructuring and a significant change in focus.

Unity doesn't need to do that though nor should they IMO. They just need to be not that far behind. Be a tenable engine for a big enough part of the market. What matters is relative positioning. SRP/DOTS narrowed the gap considerably but Epic widened it again here.

 

I used to think this way, then I started using Medium and Substance Painter and found that my productivity soared. Also I no longer have to worry about the consistency of how light falls on surfaces. So from that experience modeling and texturing is in fact much cheaper.
Sound, nah, you just hire a very good sound guy not from the USA.
Animation is still expensive. Cheap mocap: neurones suck unless you spend 2K$, kinects 1 and 2 are garbage, don't have it, there are 2 animation softwares which could change things but they are both keyframe, extra skill required. A tool that beautifies crappy keyframe is technically possible so maybe it'll land soon.

 

So all I saw in the demo was a lot more polygons.

Don't get me wrong, I like triangles as much as the next guy but from what I'm seeing of modern games, a lot of big budget games are moving away from ultra high poly art and there's a good reason why.

Style looks better.

The lighting is cool and the possible workflow improvements could be a big win for content creation but all in all none of that really excites me too much. As a game designer I'm left scratching my head as to how more lights and more triangles will equate to new and awesome game designs and experiences.


Looking at the past the things that have always made the biggest impact on the video game industry is when the input system changes, not the power of graphics.

Invention of Games

Keyboard

Mouse

Joystick (remember those?)

Console Controller

Light guns ( until destroyed by LCD Tvs )

Racing wheels / pedals

PS2 (Dualshock controller) / N64 and that crazy controller

Sing star microphone

Guitar Hero guitar

Nintendo Wii mote

iPhone touch screen

etc..


New engine, new generation, new graphics... meh.

 

I would prefer working with C++.

Unity still has advantage of having cleaner API than Unreal, but in case of Unity, C# is not a benefit, but rather a disadvantage, and a big one.

 

Oh yeah I know.
I've attempted to use Unreal and C++ a few years ago but it seemed nearly pointless - I don't know C++ that well and when I was looking at the docs to learn it in Unreal (I refuse to use blueprints as I think it's dumb and defeats the purpose as it is slower than C++, from what I've read it's around the same speed as C#). But anyways - docs always pushed Blueprints on everything so I just dropped it and came back to Unity after a few days of messing around with it.

I even have a hard time with Shadergraph because of this visual stuff, I don't grasp visual coding that well, I find it very limiting, at least in terms of understanding what each node is doing under the hood. Yeah I know I can right click and go to the doc source and read the possible code examples, some have code, some don't. HD Scene Color doesn't give you a code example.

 

To be honest I was too busy drooling over the realtime global illumination (that isn't dependent at all on raytracing hardware according to Digital Foundry) to care about polygons.

 

And your screenshots will look great. But will your game be any better?

 

Do you know the infamous AppDomain reload problem?
Sure UIElement will improve redraw problems but it won't solve AppDomain reload problems.

 

No. I have never run into it and I have never seen a thread about it.

 

That's actually 0 to do with the editor though... it's more about the backend, it would still happen if you didn't use the editor. What I mean is the editor is not responsible for it.

UI is editor responsibility and has a lot to do with why the FPS sample ran 1fps for most people. If you cannot use the editor to make edits then it is not a very good editor. Compilation and reloading of code is an entirely different matter.

 

I'd disagree.

It is transition through graphical technologies, although "big" moments become rare over time, due to being replaced with incremental improvements.

I'd say it largely went like this:

• Doom I (BSP)
• Quake (Transition to 3D, BSP)
• Half-Life (player in cutscene)
• GTA 3 (city with ton of npcs)
• Doom 3 (Full realtime lighting now possible)
• Half Life 2 (Physics are now stable, cinematographic approach)
• Far Cry 1 (BIG openworld)

Lesser and lesser impact as things go, but the next thing is definitely GI. And they demonstrated GI.

Games aside if we focus on tech only key transition went like this:

1. Vector Display
2. Raster Sprites
3. FMV games (movie playback possible)
4. Precursor Vector Full 3d (Driller, Hard Driving, Elite)
5. High fidelity 2d (adventure epoch?)
6. Faux 3D (2d game with parallax - The Terminator 2029)
7. 2D map Psuedo 3d (Duke Nukem, Doom I)
8. First 3D (Descent, Ultima underworld, Quake)
9. Hardware Accelerated 3D (???)
10. Skeletal Meshes (Half Life 1)
11. Fully Realtime Lighting (Doom 3)
12. Stable Physics with many bodies (Half Life 2)
13. Heightmap Openworld with large number of Trees (Crysis, Far Cry. Precursor: Trespasser)
14. Full PBR (Remember Me)

And the next would be GI.

I don't see any evidence of input device being important. PC went through multiple iteration of tech with mouse/keyboard, and gamepad was about since before NES times, although it got more buttons over time. Transition from CGA to EGA to VGA then VESA an Voodoo probably played bigger impact.

There were also many technologies which did not make impact, despite being promising. Fully Destructible environments, PPUs, Raytracing, Voxel Rendering, etc.

 

Yep. Epic's obsession with blueprints is comparable to unity's obsession with C#.

Also barrier of entry in Unreal when it comes to C++ is much higher. You'd need an experienced programmers that can survive a dive into a 300 megabyte codebase.

 

Do a search. "it shows how little you understand of the real problem with the editor."

 

To follow up with some specifics of what I think this would look like. Realtime GI has to be working well very soon. SRP has to be feature complete. DOTS has to be stable, at least key parts of it. That would put Unity into a decent place IMO. What really hurts is what is just flat missing, where they don't hit the bar at even some minimal level.

DOTS is inseparable from SRP really in a practical sense. Optimizations that matter on the whole are split between the two. Just how the bigger picture was designed. This is not apparent. I see a lot of people who have never used DOTS that completely misunderstand the larger paradigm going on here.

 

According to the official response on the issue linked below it's not the fault of the editor but the fault of a third party plugin.

https://issuetracker.unity3d.com/issues/unity-editor-freeze-after-reloading-appdomain

 

I made the switch several years ago, although I still keep one eye on Unity. The new VFX work looks fantastic.
Here are some thoughts I've previously posted:

I always felt like a plumber in my day-to-day using Unity. It's cheaper to buy an asset pack than develop a feature in-house, so that's what happens. You wire up this asset pack into your system and it works, for the most part. When it doesn't, you have to fix someone else's code or adapt it (typically with a hack). Then you have to make sure those changes are migrated over if the asset source is ever updated. Then you have to deal with the way all these assets (typically code-based) are put together, which is usually in an ad-hoc manner because Unity is like a box of lego.

Now I use UE4 in my day-to-day and I feel a lot more productive/creative. I'm not a fan of frameworks because they lock you into a sandbox, but (oddly enough) I appreciate it in UE4. There's a very specific way of doing things and when you find yourself fighting the engine, you're usually doing something wrong. But it's not all sunshine and unicorns. UE4 source has a lot of baggage and bugs. But being able to dive into the source is such a relief. You get glimpses of how the internals work. There have been a number of times in development where we've encountered blockers that turned out to be engine-level bugs. But, with the help of Epic, we were able to overcome them and as a result the engine gets better for everyone. There is a community spirit there.

If you come from Unity to UE4 (as I did) things are going to feel slow. It's a big engine, with multiple editors and a new workflow. That alone takes time to learn, but a key fundamental difference is writing vs. reading. In Unity, you start slinging code right away (ie. wiring up assets) and you feel productive. Development feels fast. In UE4 you spend most of your time reading code and development feels slow. However, it's likely the feature/system you want already exists in the engine and after a lot of reading/research, it only takes a bit of code to leverage it in your project - less code is better! But this writing vs. reading is a stark contrast for a lot of developers. And this feeling of slow is compounded by the fact that it takes a powerful rig to run UE4. If your hardware isn't up to par, you'll spend a lot of time watching things compile/launch.

I also like that Epic uses UE4 to create games. Not only tech demos. Full-blown games that are released to market. Whether these games generate revenue is not the true metric of success (although it's great if they do). In the process of developing an ambitious game, they push the engine a little farther. If an engine feature doesn't exist, they build it. Those changes are then rolled out to the community as a whole. This is a fantastic strategy that creates a virtuous cycle.

Buying companies and bolting systems onto the Unity engine results in fragmentation. Unity hasn't been battle-hardened in production at scale. Everything is constantly in preview. Everything is constantly just around the corner...

A lot of people list the asset store as an advantage. I think it's the opposite. A lot of people get hung-up on not being able to use C#. It's just a language, get over it. Blueprints are fantastic and UE4 C++ feels more like a scripting language (just sprinkle some macros around).

The most prominent reason I use UE4 is its embrace of open source. And that is a direction I want to support: an open, free community. It's not there yet, and certainly not free (as in beer) but I think it can strike a nice balance. And that philosophical underpinning is what makes UE4 cool.

In the end though, don't get too hung up on us vs. them. If you don't have feature X, don't worry. Most people can't even fully leverage feature X when they have it. Often times, having constraints enable freedom (avoids analysis paralysis). If you feel comfortable with the tool you have and enjoy the community you're a part of, carry on! Focus on becoming the best artist you can be because the tools are ultimately transient.

 

Are these multi billion poly assets using mesh colliders?

 

Every editor that I know of consists of backend and frontend. .NetCore will just make Editor faster on the both. AppDomain, in particular, pertains to the backend though.

 

Unity has lost the high end battle, but it doesn't matter for most of us anyway, they should stop chasing after it and happily admit defeat. Maybe if they do that they will then be actually good at something.

Unity wins at the low end? On mobile currently, controllers don't work, splash screens have bugs (no, REALLY), and no one can prevent Unity from gathering data and sending it to Unity headquarters.

And you look at shiny graphics and say Unity can get their S*** together and do that? They can't even find their own bugs, they have outsourced all bug hunting to users and they simply deny lifting a finger without a user bug report.

Unity currently, is a fragmented, bug ridden confused mess with no vision behind it. Chasing after high end features is the last thing it needs right now. They can't do that.

 

Yeah, because not having to bake and having immediate visual results would free up time for playtesting. At least that's how I see it.

My ideal combination is PBR + GI + LowPoly, by the way.

 

No, it's because AppDomain requires to reload everything (full assemblies) even if you change a single line. Native Assemblies( with pInvoke) cannot be used in Unity, period. Think about the missed opportunities here.

It causes not only a freeze problem but causing extra long time to reload everything, every fu**ing time.
.NetCore simply removes the problem.

 

I'm too busy thinking about how people need to stop blaming the editor when it's not the editor's fault.

Your previous statement was that it would increase performance. Which is it? Increase performance or fix the problem?

 

Why is everyone comparing the current state of Unity to a demo of an engine that will probably release sometime in 2022 and is shown on unreleased hardware?!

 

Yeah, workflow improvements, great. next gen graphics, meh. That was kinda my point. Seeing as the demo is mainly showing graphics tech...

 

Because at the rate Unity progresses, nothing will have changed by 2022 really.

 

We're professionals and part of our job is keeping up to date with the upcoming technology. Technology that is not too far away. Both consoles are coming out in less than a year, and PC will be getting equivalent or superior hardware in six months from AMD, Intel, and NVIDIA. In fact NVIDIA is announcing their next GPUs tomorrow at 6 AM.

 

That's pretty harsh tbh. It wasn't long ago I was wrestling with xcode and having to enable entitlements every time i made a build. That's now fixed!

Game engines never have problems when they are first released either.

 

Blueprint is both a blessing and a curse. It's good for procedural stuff and for making quick prototypes. Beyond that, it's a hindrance, whereas C++ is like drawing a picture with a needle. There is no choice in-between right now, but they are working on a new scripting language that can fill the gap.

And yet, Unity is trying to follow the mistake. The visual scripting tools will fragment the market place and it will litter with garbages. Even if Unity makes a visual scripting tool, it will fall short of Blueprint by miles and they will drop the support after a while.

When we have C#, it will make little sense to make a visual scripting tool except for some simple projects. Why not invest more time make C# hot-reloadable instead? It will be much wiser decision.

 

Game engines always have problems as you well know but Unreal was very good at launch compared to some of the more recent releases of Unity. Unity switched to two tech releases per year specifically because it's been more broken than stable lately.

 

Sure, now you just have to wrestle with XCode to write in your own controller support, because Unity broke theirs, and to try and fix the storyboard splash screens, because they have been a mess for... 4 years?

Actually I take that back, in 2022, more things will be broken than now.

 

If Unreal ever adds C# support it will be over for medium to large-scope indie games, at that point there will be very little benefit to unity over unreal (it's hard to talk about ease of access when the "production-ready" SRPs are missing documentation and constantly changing their APIs, asset store authors are bogged down supporting multiple rendering pipelines, standard rendering falls further and further behind, etc)

 

The idea is that it makes it possible to do both without having to make massive sacrifices in one direction or the other. The entire point is to make it so that this choice can be a false one.

 

It's worth noting that we haven't seen anything from Unity yet about what it can do on the new consoles.

It's pretty clear that what Unreal showed was possible because of the SSDs in those devices. That may be possible in home PCs over the next few years, but not today. I don't believe they could publish this demo for PC users to run at home - anytime in the next year or two. Not without requiring it to scale down from what we saw.

There's no point in giving anyone "a pass". But it's smart to keep in mind - we haven't seen next gen anything from Unity. We probably will by the end of the year.