Unreal Engine 5 = Game Changer

Wow cool that you totally ignored the video in that same post that addresses this.

 

I've already seen it.
Tell me which part of "In development" means that these features will be production ready (and really production ready) for 2021.

 

The video also addresses the production issues that have come up in the past and how they're being addressed, so are you sure you've seen it?

 

As mobile dev, look at all these amazing things I have to look forward to.

Support for new iOS Android versions? Oh my!

 

Maybe I've missed the part where it says that the engine will be stable on 2021.
Seems you have seen it lately, so you can respond easily.
When is the date for the GPU lightmapper, or the realtime GI solution ? Stuff they've talked about for years now.

 

Correct me if I'm wrong but doesn't this mean:

- A big switch/if-else blob of code compared to the simple logic of adding a different component a different object.
- GetComponent every frame? Or otherwise using magic strings or some other such thing to differentiate objects.

It appears to me that the ECS approach is sort of the equivalent of using singleton 'manager's for everything, except that it's not the singleton that is being searched for in the code (which would be relatively simple) but the identifying features of each of the individual objects that this manager is operating on. Which would probably degenerate, in practice, to the ECS equivalent of GameObject.Find(My100thIdentifyingNameThatMightChangeAnyTime).

If such an approach was used in the normal Unity workflow I would consider it to be hard to manage, high risk code.

Let me know if I've got this wrong, I hope so.

 

When's the date for nanite and lumen? It was in R&D for a decade.

 

According to Epic it'll be in prerelease 2021 and released late 2021.
So around 1 year since since they announced it.
Why bounce the question though ?
According to you the only reason I didn't get an answer is because I lie about seeing a video.
So tell me.

 

You're saying that UE will be "stable and state of the art" in 2021 but there is no evidence to support that. You either don't remember what UE4's dev was like or you're just trying to start another pissing match in this thread while not actually paying attention to the fact that UT is taking active steps to resolve the problems they've had. Right now, most of these changes are slated to be in a release state in 2020.2 - 2021.1 because the 2020 release cycle is about locking down functionality and improving workflow.

Of course, you're probably going to say "well that's too vague!" but if they gave actual dates you'd probably go "well they've missed targets before!"

 

I don't know if Lumen was in R&D for a decade. But nanite is something I don't consider essential - it's a revolutionary, experimental technology. Something to make you feel good about the future.

Hands off realtime GI is an immediate issue for many people.

In any case, a lot of people on this thread are claiming that the reaction about Unity was caused by the Unreal video. when in actual fact it's just the straw that broke the camels back. It made people think "hey this video looks exciting, am I excited about Unity?". A lot of these issues that have been simmering in the background have come out in the thread.

 

You are right I'm going to say it's too vague, when stuff promoted years ago (some features more than 4 years) is in the "in development" column, and unity has had stuff "in preview" for years.
Again, all it says is that these features will arrive on 2020 or beyond, did you see the video ?

 

The recent Unreal video actually contrasts greatly with the Unity video in a variety of ways that are of note:

• The Unreal video shows, it doesn't tell. The results speak for themselves, no bullet points needed.
• The developers behind the tech are sitting right there explaining their tech demonstrating that the actual developers are powerful within the Unreal hierarchy and have a voice, they aren't relegated to a cage.
• I was so unexcited for that unity video. They used a lot of bait and switch with the titles to make thins appear more exciting. "Creativity workflow improvements" != A few 2d improvements. The exciting bullet points in no way connected with what was shown. An entire bullet point for some small inconsequential addition to prefabs while other changes are MUCH MORE NEEDED. When do these pertinent changes come?

I groaned when i saw that they are working on 2 friggin' animation systems side by side. Like WTF are you smoking Unity? The current system is FINE, it is MORE THAN FINE. It is dynamic, polished, it works, it's performant it's one of the few bright spots. Why the hell are they developing a separate dots solution? The current animation footprint isn't even that large, why aren't they simply developing parity with the existing mechanim and adding a few bells and whistles like dots support?

This says to me that dots does not play well with anything that currently exists in C#. They have effectively made the insane decision to not only maintain and build on their current engine, but simultaneously integrate dots KIND OF, while essentially creating their future tech side by side.

Long story short it appears they are working on 2 seperate game engines, Unity future, and Unity legacy, and somehow also attempting to integrate them simultaneously together.

Like seriously wtf I just feel bad for their engineers. It is such a fukcing dumb idea. Why not just develop DOTS, figure best practices for upgrading to dots after the fact, then carry your existing systems over to dots once this is all figured out? If upgrading to dots is too complex a process, there should be no connection between legacy and future, if it's relatively simple, then simply port it. Why in heck are they developing 2 pipelines to do the same thing simultaneously while creating a cob web of inter functionality between future builds and package combinations.

You can't expect great code from your talent when your far reaching decisions are F***ing amature. It would take a herculean effort to maintain these 2 pipelines at 1/4 the speed of a company like Unreal that aren't juggling this cross-integration insanity.

Am I missing something?

 

Which part of the video says that the GPU lightmapper/realtime GI/on demand import will be production ready 2021.1 ?

 

Because they switched to subscriptions so they have to appear like they have meaningful output all the time so people maintain subs.

 

I simply want the editor to work with me and not against me. And I’m enjoying 2020.2a. The editor is the fastest it’s been in a long time. It seems more stable despite being an alpha. It’s seeing some cool little quality of life workflow improvements every couple of weeks. There is still lots of room for improvement but I’m more optimistic than last year. Once URP gets feature-complete enough, and asset devs can work their magic, then I’ll be quite happy. Everything else is cherry on the cake.

 

Also the GPU lightmapper doesn't seem to default to CPU most of the times in 2020.1
The russian roulette feature is quite interesting to iterate fast.

 

2nd part about "Connected games" was a bit of a joke and showed how disconnected Unity is with community. https://forum.unity.com/threads/2020-roadmap-q-a-part-2-live-games.857182/#post-5658043

 

No they don't. If you earn more than the income cap then you need to maintain your sub as long as you're using the engine.

Look at how much backlash there already is when a system is deprecated. Just a few days ago there was a complaint thread about the fact that Unity has made breaking changes in the time between Unity 5 and now, and a developer was trying to update their mobile games. It's not the first such thread, and it won't be the last.

I don't make mobile games at the moment, so it's easy for me to say that I'd like Unity to take Unreal's approach - just start again every few years and make fundamental, breaking changes. If I were a mobile developer then I'd almost certainly want Unity to stick to their current approach, with ongoing support for "legacy" functionality and a stream of incremental changes I can handle one at a time as I keep my engine up to date so I can avoid falling behind the compatibility window for mobile OSes and devices. (Separately, I hear mobile developers are having their own issues at the moment, some of which are... disappointing.)

 

I don't think unity is in lack of competent technical people, the demo they do ARE technical marvel, they just aren't accessible to the audience in a sensible way, ie you have sheltered competent people at odd with the will of the audience, ie they make a product for themselves and their technical peer, but don't have a sense of services and are disconnected from the need of the "peons".

 

The last 10% of the work is 90% of the work when you're making broad usable tools for a variety of platforms and use cases. I would imagine for unity they bring on these people capable of creating amazing tools, but when faced with the prospect of standardizing the tools be be broadly usable in an open engine setting suddenly no one has the broad toolset to make it fit in their engine.

Combine this with their constantly shifting code base as they implement dots and now everything has to be hyper performant to warrant development so it doesn't' instantly become deprecated on release and now you basically have a freeze on your engine.

What they COULD HAVE DONE, is focus on developing their core tools in a responsible way while trying to lay things out so they could be migrated to dots in the future as best as possible. This would have put extra pressure on themselves to develop dots in a way that it works retroactively with prior C#, or at least develop pipelines as painless as possible to upgrade it internally that they could then share with their user base. It's a win win. You hyperfocus on your current tools, you work on making them expandable to your new tech when it's ready, and you don't gate your future tech by stifling it with parity with multiple legacy features.

 

This move to DOTS and HDRP, if done at all, should have been Unity 2.0 with a clean slate. An experimental new version of the engine which they can work on separately and see if people are going to be able to use it or not.

I get that technology needs to move along, but workflow is paramount, and confusion is never necessary. Until it is clear what it entails to work with DOTS, and it has been battle-tested and accepted at large by experienced and new users alike (if it can be), such radical changes in the architecture should not be incorporated into new features for the engine everybody is using.

Same goes for HDRP. In the current state, nobody should be selling stuff on the store for it, least of all Unity themselves.

There has to be a clear separation of what is tested and ready to use from what is experimental, so that things can live and die on their own merits.

 

100%.

If you keep your eyes open in this industry you will see that features and tech are not bankable. You cannot bet your future and OTHERS' future on unproven tech. Heck most GAMES fail, let alone game engines, and those have a far narrower use case and proven formula to follow. Everything about Unity's current plan of attack is suspect. If they pull it off, I mean hats off. But it's like your friend doing a back flip off a 2 story house with no gymnast experience. Whether they pull it off or not it wasn't a smart move, and in Unity's case it is more than just their well being they are gambling with. And what successes do they have to point to that gave them the big head to think they could pull off the impossible?

Every sign points to idea people calling the shots, and I can almost guarantee it's the grunts on the ground floor taking the flack when things don't go smoothly.

 

I could be wrong, but I really do get the idea that Unity are sacrificing a good part of the indie equation to go after licenses from engineering companies and similar customers. Whatever can be said about the benefits of ECS, no other engine that I know of needs it or even perhaps wants it. Unreal are deploying huge Fortnite games across all sorts of devices without needing it. I never heard of it being used for AAA open world games and stuff like that.

I have no doubt about is utility for having 10,000 soldiers marching across the screen, or simulating particles or other such things of which there are many operating in exactly the same fashion. If I was making a large scale strategy game I'm sure I would be pleased.

But I'm not convinced it's necessary at all right now for Unity to develop further as a game engine in general. With all its workflow disadvantages I can't see the sense in building the future of Unity around it right now.

 

This is true. I guess i'm just focused on a few things - like terrain, timeline, animation, etc where there has been LOOONG standing complaints but there has been no decent response to when or if these things are coming (apparently they're working on brand new dots versions of all those things, so hopefully they tackle most of those issues). But you're definitely right, they've improved.

 

Are you sure about that? In my talks with people far more experienced than I it's a fairly common, often recommended way to go about things. Some of the first talks I went to at game dev conferences towards the start of my career were about exactly this stuff.

The difference is that they don't give it a fancy name and market it. They just do it and then move on and do the next thing. They're not "making ECS", they're just "doing stuff efficiently".

Here's a set of slides from 2009 about exactly this, from someone who's worked on quite a few big titles. Note that they didn't need a special pre-made framework there, and got something from ~19ms down to under 4ms.

 

I'm really curious as to where some of you got the brilliant idea that is "Unity should support two entirely different codebases at the same time."

That's genuinely the kinda thing where I'm genuinely baffled as to how anyone thinks this would lead to faster and more reliable iteration times, because historically everything but that is true.

 

I mean, they're sort of doing that now, although instead of maintaining the old stuff a lot, they spend a lot of time trying to merge the two codebases together, often unsuccessfully.

I guess they idea is if they split them completely, that would free up some time to actually properly support the current features.

I mean, did Unreal stop working on current features while working on Nanite or Lumion or whatever?

 

You could have a big if/else or have separate systems for each type - that's up to you. And ECS's version of "GetComponent/Find" is basically instant - it's not like GameObject.Find cause you're querying by type, not string. So if you change your type's name, either your IDE will fix up your project or you'll get an error.

ECS does take a mental shift, but it's very fast and powerful. I wish there was way that Unity could have switched to using an ECS backend, while keeping 90% of our current coding workflow (seems like Visual Scripting is going that route). We're too deep in now for that tho. But before you write off ECS, if you have time, i'd say to try it out. A lot of your ideas on it probably won't hold true - I personally think they did a good job at simplifying the concept and making it pretty approachable even if it's not as easy as monobehaviors

 

That's possible, I'm sure these things are implemented as required in custom engines. But let me put it like this: Unreal make one of the biggest scale games around that operates on all sorts of devices, and they also ship some of the biggest AAA titles as well. Tim Sweeney questioned whether ECS is a good idea; it's entirely possible that's just marketing, but given what Unreal is capable of it might just be a good point.

To be perfectly honest, I would have expected Unreal to be breaking china all over the shop with some new high performance experiment while Unity sat in the middle of the market enjoying the fact that people will still prefer it for being an engine you can actually get stuff done with.

Not sure if you're referring to me, but that's exactly what I'm getting at. Experiments should be quarantined from the rest of the engine until they have proven themselves useable and useful to the majority of Unity's user base.

 

Workflow wise, that's just not pretty at all.

I will give it a go at some point, and I have looked into it far enough to understand what it is like to use. I expect to use it for spaceship traffic in my game. So I'm not sorry it exists - quite the opposite.

But for prototyping and the vast majority of games, I would not want to use it nor expect to need it. As an asset store developer who is always in contact with beginners and learners, and thinking about when I started off with Unity and what that was like, unloading ECS onto everybody seems like the wrong thing to do.

Anyway, that's about it from me on this topic, I'm reiterating myself at this point. I just hope that Unity continues to want to be what it has been in the past - the kind of game engine you choose because it will help you get stuff done.

 

You should know that you can use as much of MonoBehaviours and UnityEngine.Component based stuff with dots as you want right? You may not get any performance benefits, but its most certainly compatible with what existed prior. You can mix and match them, use as much or as little of either.

 

It is best to rely on your own knowledge, though.
Not so long ago we had a poster saying "my friend said X about the engine". We all know how it went.

See generic versions of GetComponent/GetComponents/GetComponentsInChildren/GetComponentsInParent.

They're already doing that via LTS.

It is impossible to create COMPLETELY different codebases. They would have branches. Branches are nothing new.

 

I think that's kinda what they're doing now with ECS and Monobehavior AND with Tiny.
They kinda have 3 versions of Unity right now, all kinda colliding in weird and confusing ways to the end user.

 

Not everyone can have first-hand knowledge of everything. That's why I backed it up with slides from Sony. And if you look the specific author up you'll see he's worked on exactly the kind of game mentioned in the post I was responding to. (Sunset Overdrive to be specific, among others.)

 

While I'd love to see DOD implemented in some major engine and see if it does really make a big change this, it's really weird that Unity pushes it first. There are hundreds of things that could be upgraded in a given engine to catch up with AAA engine performance.

Examples

• Intel ISPC for easy SIMD vectorization. Integrated for performance-critical systems (in UE4 for Chaos physics, animation, brings up 4x improvement in simulating Cascade particles on CPU). Implemented in the engine, developers do nothing, it's simply there.
  
• Changed format for compiled shaders in UE 4.25. Now it doesn't rely on CPU heavily, it makes loading shaders to GPU much faster. Content loads even a few times faster on PC's SSD. Can imagine that utilize next-gen console architecture nicely.
• A lot of work is done for refactoring asset loading, moving what possible on async threads. The current mechanism is UE3 legacy, loading sublevels or any assets blocks main game thread. Bad for huge worlds and new consoles.
• And there's a lot of engine optimization happening now. The only new thing for the developer is that Epic finally created a first-class profile called Unreal Insights giving an... well... insight into what happens every frame. Basically, FramePro tailored for specific engine
• The cost of CPU-to-GPU communication went down thanks to automatic mesh instancing (also needed to make raytracing performant). And implementing modern API (DX12, Vulcan, Metal). Although the entire level design is based on OOP (actors and components, like "classic Unity"). Blueprints can't into multithreading, still a single person can develop a performant and beautiful 3D game... It's not like OOP is some performance nightmare on current hardware and APIs

Any kind of method of easy multi-threading actual gameplay code in the project would be nice, especially in "hypothetical" custom scripting language. But this would be a final optimization. The engine should care about utilizing a high thread count of modern CPU. Bring down the cost of performance hogs like executing skeletal animations, physical simulation, issue draw commands to GPU.
So... a lot of things that the developer of the 2D game should never care... They shouldn't even notice something changes in the engine.

PS Unity's city demo could quickly be prototyped in UE4 by using Instanced Static Mesh Component. A single component, when every mesh instance is generally a new transform on the list. It's done to optimized draw calls, just a single draw call created for the entire thing. Used for years to optimize foliage (it would be insane to have every instance of grass as separate mesh). It could be utilized by a designer to make the crazy amount of mesh of any kind actually... And by programmer to created game mechanics utilizing it.
Obviously, this solution isn't nowhere close full ECS-based gameplay, but how many games need entire engine working on ECS?

 

I mean, I agree. I definitely wish Unity could have found a way to make the ECS stuff fairly transparent if you didn't need 100% of the performance boost you'd get from going the full ECS route. Putting the burden of ECS (even though Unity has done a decent job of simplifying it) on the user probably wasn't the best idea.

I just meant that string bit for GameObject.Find

 

In my experience taking that approach makes a big difference, but only to a small amount of your code. In those slides I linked the example is using it for transforms. That makes sense because it's a part of your code that potentially needs to work on thousands of objects every frame. There's lots of work being done which means there's plenty of scope for improvement, and it's being done all the time so it'll directly impact your overall performance.

For parts of your game which are less commonly used the benefit will be far smaller, so using an approach and/or toolset that you're more familiar with or which results in more maintainable code makes a lot of sense.

My current game rarely has more than a few tens of any particular type of object, and most of them are dormant most of the time, so they're all implemented in standard OO fashion. There's just no practical benefit to optimising something that's already not having much of a hit.

Previous projects have got a huge advantage out of this kind of thing, however. I remember prototyping for one project where our target system struggled to simulate ~6k entities with the OO approach, and got into multiple tens of thousands with a data oriented approach. (C#, single threaded... nothing special but re-organising the data.)

With the latter in mind, I suspect that the point of ECS is to enable rookies to do some of the stuff that people say can't be done with Unity. It can be done, but you've got to know how a computer works in the kind of detail shown in those slides. Or, when it's done, you follow the instructions with ECS and someone else has already worked out the tricky stuff for you.

 

It is largely a nitpick, as the last "my friend said" has left a massive negative impression.
Feel free to ignore it.

 

I can see how you get a "my friend said" vibe out of that, but it's really not what I was going for.

 

That's exactly what I was saying. With Unity, every new feature has to be implemented by the DEVELOPER: like DOTS, the new animation pipeline, the new physics system, the new rendering system, etc.

While with UE4, just about every optimization is hidden under the hood, so developers could easily update their projects and have all the benefits. Why couldn't Unity learn from Epic Games, and put all the DOTS engine updates under the hood, making each updated feature something that would automatically benefit developers?

I know there's already a few rendering features that have been rewritten in DOTS with no added strain on Unity developers. But the problem is that particular piece of code is now closed source because it's integrated into the game engine. All the essential features should be integrated into Unity (when it's out of beta, possibly allow the developers to opt-out of these features in player settings), and not separated as external packages that have to be installed by the developer. And all these integrated C#/DOTS features should be open sourced without separating them from core unity.

 

The benefit of DOTS are that your data entities are tightly stored in memory and in CPU cache.

You lose alot of this if you need to link that data back to objects on the heap like monobehaviors.

Edit: my point being its a bit hard hiding Dots behind classic MB

 

I thought the whole point was that they are doing a lot of that stuff under the hood? The first sentence I find when I do a search for it is "We’re rebuilding the core of Unity with the Data-Oriented Technology Stack."

They're just also making the same system available to use to use script-side if and where it's useful.

 

We have as a POC migrated our AI visibility and visual awareness code to Dots and using async raycast we could run 50k instances before the fps started to drop below the 90 fps mark required for VR on a AMD 3950x

Pretty cool

 

That's possibly true. But a good portion of Unity packages don't depend on Entities, but I'm sure a good portion still utilize the job system and the burst compiler. Unity can hide the whole process of compiling Jobs using the burst compiler deep in the engine code (and keep it open source too).

HDRP and URP could have been integrated into one new default renderer, that would hide the process of compiling HLSL into the new shader language, so older shaders don't break on developers who have been using the older default render.

The point I'm trying to get at is Unity is getting into the habit of releasing mandatory external packages and forcing developers to change up their whole technology stack just to use new features. Heck even the new Input Package forces developers to change their entire project, while Unreal input system works right out of the box.

 

I agree on the render pipeline stuff, but for Dots you need to run it all the way to benefit performance.

I wished they abstracted URP pipelines better so you could switch between the different fidelity levels like tiers.

 

This is not true.

In Unreal, API changes can be quite rapid, and at the same time can be undocumented. Additioanlly, Unreal does not maintain archive version of its documentation.

So you shouldn't expect to easily upgrade your project. Chance of your codebase being wrecked can be higher.

For example, read this:
https://forums.unrealengine.com/dev...998-what-happened-to-uskeletalmesh-in-ue-4-19

 

It definitely not great to rely on friend's opinion of advice but u must practice your own disciplines. So we are sorry if you are feeling upset. But my friend said she really like your box modeling examples and said you seemed highly acomplished. So thank u very much for the advices we're doing really well now with unity.

 

have u started using dots full time, we are just beginning the journey sir?

 

How do you know?