I saw how ECS system icreases the rendering and physics performance. I think it will be better to have it.
2 Likes
I was about to open a new thread for this. Sounds very convinenet to have ECS in UE4 (even as an optional plugin), especially now that Epic Games has a lot of money flowing in thanks to Fortnite.
I love to see this too in UE4!
They are talking about “threading”, which is already in there since forever xD
These threads are why aliens don’t talk to us.
The only engine I know of that went 100% full ECS is latest releases of CryEngine5, but the overall engine package is so buggy the people I know using it can’t complete the game and project is halted until the many bugs are fixed.
It’s as close as we’re going to get. Actors provide the basic functionality that is required by the rest of the engine (rendering, networking, blueprint etc.) - not something you’d easily be able to get away from.
Sure they could move the functionality of actors into components if they wanted to, and the concept of an “Actor” could just go away into effectively an array of components - but that would result in a complete rewrite of the engine and those components would still be “required” to achieve anything - it’ll cause more problems that it would solve. It ain’t gonna happen.
I understand It’s a lot of work, Cryengine, Lumberdyard, Leadwerks, Unity, others… all of them are implementing full ECS and It has been proven more performance and flexibility than Actor(Entity)-Component only.
Not just Actors and Components, the base class “UObject” is itself already a very fat class.
Maybe in Unreal Engine 5.
This kind of rewrite would be a candidate for a completely new engine - it’s probably a bigger change than moving from UE3->UE4. They’re unlikely to change the fundamental architecture of the engine in the same version IMO.
I would like to see a more lightweight code base. AActor (the base class of pretty much everything in UE games) is heavily bloated with things you mostly don’t need.
Damage, Replication, Touch Input, ViewTarget Stuff. All this is not needed for a StaticMesh for example.
I second this.
I hope you people realize that any large architectural changes you suggest are purely pipe dreams, right? There are thousands of projects relying on this engine. Thousands of companies who have trained their staff to work with this engine and this codebase. Such a huge architectural shift would cost all of them potentially millions. Not to mention that given the kind of performance numbers Epic can squeeze out of it this is pretty much a case of “don’t fix what isn’t broken”. I mean, don’t really care about people discussing design philosophies and whatnot, as there are always ways that could have been done better, UE4 downright sucks in some aspects, but to think even remotely that it’s feasible to change the engine foundations at this stage, and then come here and DEMAND those changes, is childish at best.
“Please Add ECS to UE4” is a **DEMAND, **really? Childish…? What are the versions for(MAJOR, MINOR, PATCH)? Is it a crime to want a better engine?
Major versions are for changing API (i.e. function names, locations etc., anything that usually leads to a compilation error). Minor versions are for changing implementations (i.e. there will never be any new compilation errors; it’s just that the same functions will do different things in the back). Hotfixes/Patches are released when an accidental, known, screw-up (which also compiles) makes it in the release build. I don’t know what this convention is called but it’s a standard which you can find on Google.
​​​​​​Fundamental architectural changes fall into a much more severe category of changes and that’s why you have UE 3/4/5 altogether. It is, indeed, childish to hope to see this change in UE4, but it doesn’t mean the suggestion is wrong nor does it mean it cannot serve as the basis for UE5, when and if that ever becomes a thing.
I, for one, agree with this architectural shift and the fact that UObject/AActor are too bloated and need to be simplified drastically.
ECS is not a magic bullet. Data-oriented programming has been around for long time in games and pretty much every decent particle system implementations use it, for example. But it’s harder and more cumbersome to use versus traditional object/component approaches, there’s no way around it and games often use it when they really have to.
Anyway, it’s not marketed as that, but I think Niagara could be used as an ECS for purposes beyond just particles and VFX with some upgrades.
I think childish is the wrong terminology. I would use the term inexperienced. If you don’t spend much time in the belly of the engine, you could maybe be forgiven for thinking that incoporating a full ECS-framework and replacing the existing is a simple thing - but it just isn’t the case. Look at how long it’s taken to replace just Matinee for example, sequencer is still being worked on to this day.
I am fully behind splitting chunks of the Actor class code out into more components. The damage system is just one of them, but I’d also like to see things like Replicated Movement moved into actual Movement Components (makes sense right?).
Unfortunately judging by some recent changes to Characters and Character Movement, Epic seem to be focused more on short-term solutions to some of these problems - probably because of the F-word. For example, all RPC’s used by Character Movement are routed through the Character instead now to reduce some RPC overhead for components. It’s gross, but I guess they needed it for now. I do feel as though the almost absurd levels of success of Fortnite have overshadowed engine progress for the last few months - but that’s the price you pay for using a battle-tested engine I guess.
I don’t consider UObject’s to be overly bloated, they’re a fundamental piece of the engine and have a lot of heavy lifting to do, GC, reflection, replication, etc. Actors on the other hand, definitely could be divided up considerably.
In your case demand was a bit much, but spend enough time on these forums and you’ll see why many people are jaded when it comes to these topics. It’s basically the equivalent of “hey you know how we could improve this car!? Turn it into an airplane!” and to be perfectly blunt even entertaining the notion that people with that little experience with the engine and software production in general might even have the slightest influence in Epic’s direction for the engine is very much not amusing.
Hey, adding ECS or something ECS-esque wouldn’t require any rewrite of the engine. It certainly didn’t require on Unity: all the old baggage is still there, for better or worse. Like I said, Niagara is 2/3rds of the way into doing what an ECS is supposed to do IMO: updating the state of a large collection of entities in a cache-friendly[FONT=Helvetica,Arial,Verdana,sans-serif] and multithreading-friendly way. If Epic adds some debugging capabilities, the ability to nativize Niagara scripts for CPU and proper ways to get data out from it some crazy stuff could be done.