Engine Level ECS System Needed

General Feedback & Requests
,
1

Hi, I was looking for ECS in UE4 because I came from Unity and they implement it. so I found that UE doesn’t have an ECS system. so please add an ECS system on the engine level so we can get the benefit for the multi-core processors.

I know some people implemented this for their own use.

but It’s too confusing, it would be great if we can get the ECS system inside UE on the core level.

2

I believe I saw something called “Mass” on UE5’s commits on git, it seems like an ECS system but can’t confirm. It looked very much like ECS to me.

there is also third party ECS EnTT/flecs you can integrate but I would suggest just optimize the code you have and you will be fine, even with ECS you won’t be able to have 1000’s of skeletal meshes as there is no Instanced skeletal mesh component out of box.

plus I think Unity’s ECS is just awful at this point but I am going to give them the point of trying and taking the step in right direction.

2 Likes
3

Yes, Mass AI systems indeed rely on an ECS-like framework for simulating agents. And that’s seamlessly integrated to classic Actors in the world.

TL;DR Unreal does take benefit of CPU threads. It does already uses ECS where it makes sense, instead of forcing everyone to some trend.

There’s not much point in engine-wide ECS. We can distribute any system to threads in C++, or write smaller features in a data-oriented fashion.
OOP-based blueprints are perfect for designers/artists, most of the world-building. Would have taken that away from them. Or introduce a separate ECS path for every single gameplay thing. Both options might end up a nightmare.

ECS in Unreal is introduced on a low level where it truly makes a difference. In 4.26 evaluation of Sequencer has been refactored to ECS (micro-framework written just for that), sped up evaluation up 7-8 times for a large number of animated actors. And Sequencer users didn’t even notice a change. That’s what we need, solving actual performance problems! That’s a free lunch.

It was a mistake on Unity’s side to assume a full switch from Game Objects to ECS would be a good idea. They retracted from this.
Let’s also keep in mind that data-oriented patterns are much more needed in Unity because of C#. It wasn’t designed to handle performance-intensive applications like games. It’s really bad for memory in bigger worlds, especially with added OOP overhead.
And developers couldn’t go around it as projects rely on C#.

Plus, Unity had almost zero systems built around Game Objects, so they could try to build new things on ECS. Still, it’s taking them years…
In Unreal, a dozen well-functioning systems would have to be rewritten, perhaps a million lines of code :wink:

The last thing, applying ECS everywhere might actually don’t need huge performance gains for most the Unreal games because:

  • If we’re doing 3D games (and UE doesn’t truly support 2D games), then we’re usually GPU-bound. CPU waits until GPU finishes rendering. Especially that CPU-side of Unreal’s rendering it’s pretty fast when it comes to hi-fi visuals, unlikely to non-DOTS Unity.
  • We already have heavy engine stuff distributed to threads: draw thread, optional RHI thread. Physics, animations, Sequencer moved to threads for us. And recently Mass simulations.
  • Also, Nanite takes way some work from the CPU. We can forget about counting draw calls for Nanite meshes, one less reason to go ECS for the entire engine.
5 Likes
4

You can’t have been looking very hard. The AActorComponent system is an ECS, and affects almost all objects in the system. All objects that have a location, will be AActor subclasses, and have access to this component system.

Even more than that, it’s actually possible to attach components to a base UObject just fine, and pick other objects the fill those property roles. The UPROPERTY()/UCLASS() system lets you do this, and gives you the level of introspection and data driven-ness that you’d expect for generic objects with generic sub-objects. You can make blueprints of UObject subclasses. You can configure any declared property, or array of properties, with sub-objects as appropriate.

That being said, ECS are great for editing and data, but sucks for performance, because every single pointer is a cache miss. This is why Unreal components generally configure some instance of some record in some more data-driven, parallel system, and marshals events back and forth. This is obvious for things like “particle systems” but also for things like “collision assets” and “physical bodies.”

1 Like
5

I am already aware of the plugin “MASS AI”. it’s is a huge improvement on the NPC side. now we can control our NPC and crowd in Mass Ai instead of Niagara.

thanks for the detailed explanation. it makes sense and you cleared a lot of confusions :slight_smile:

1 Like
6

after you mention that I checked the documentation but there isn’t anything mentioned about the Actor component and data-oriented design.

7

The fact that the components end up updating more efficient internal structures, is an implementation detail, so you’d have to get the source from GitHub and read through it to know exactly how that works, if that matters to you.
Epic did the right thing in making the source available to anyone who signs up! It’s the best documentation there is.

2 Likes
8

thanks a lot for pointing out :slight_smile:

9

We have actually implemented a full-fledged and BP-ready ECS framework. It’s called Apparatus and is available in the Marketplace: Apparatus in Code Plugins - UE Marketplace

3 Likes
10

AActorComponent is not an ECS system. Sure you can compose components on actors, but it’s not the same thing. Unreal components are not data-only or data-oriented. Systems are not separated and there’s no automatic concurrency detection.

3 Likes