ECS - When and where to use..

Hi,

I've been testing ECS and think it combined with DOTS looks fantanstic, loving the performance boost it gives you using burst compiler..

But when and where should I use this new stack..?
Is it only aplicable when I have a lot of the "same" elements that needs to be translated/rendered..?
Are the any real life examples of use, becides zombi shooters ;-) ?

And when you use it, do you use only for the part that gives meening or the entire app..?

To admin : If I placed this in wrong area, please move

Thanks..

Søren

 

Anything that needs update everyframe can be replaced with it (Coroutines and stuff in update method, TriggerOnStay etc). But I would start with the code base that have a high complexity count

 

DOTS is not necessary for rendering. It is huge bonus. But beyond that, it has massive amount of potential usage.
From path finding, complex movement and formation of large groups of units, i.e. school fish, to simple things like rain, to spatial calculations, raycasting, and extensive logic execution. Just to name few. Oh, and not forget all range of applications for AIs Not only gaming btw.

These not necessary have to happen every frame. You can execute something otherwise complex, which could take few frames (probably primarily using courtliness). That you can probably reduce to one frame. And whats important, you can bust frame rate of average game by much. Something running at 20FPS probably could have potential to gain a lot extra FPS.

Other than that, massive battery usage reduction, for mobile devices, even for simplistic games.

 

I believe data-oriented design is about more than just performance; I recently wrote some notes about it here.

 

You can use ECS for everything. Problem is that some integrations are missing right now, requiring somewhat workaround solutions to solve simple problems.

E.g. UI, or missing material property block support in the hybrid render system.

Those will be there eventually, but its not there yet.

ECS is way better than classic. Zero-alloc by design is huge on its own. Easy multithreading.
Easy decoupling. Running things only when they needed to be processed.

Lots of pros.

But right now its just easier to use classic. And the classic approach is way more stable (really nasty bugs occur less frequently).

 

Also ECS API is subject to change a lot meaning what works now for you might not in a few months time. Comparatively, classic unity API doesnt really get many breaking changes

 

DOT's is literally the most amazing thing I've ever seen in Unity. While I haven't used ECS yet, the Jobs system (which is part of DOTS, which also contains ECS). I built a culling system for my Map Magic generated worlds for my game, and I can have literally MILLIONS of trees and objects dynamically in real time cull and uncull, etc. and not lose a SINGLE FPS from all the calculating.

[EDIT]
The only FPS I'm losing is simply from the overdraw of the trees, which there's really no way around. So generally my game, despite the hundreds of thousands or millions of objects, I'm generally at around 50-54ish FPS on a 6 Core Ryzen and Rx480 graphics card.

[EDIT 2]
But at times I'm over 60+ FPS depending on Overdraw.

 

Just wonder, that is in the editor, or already after build? Nothing wrong either. But if in editor, that means you will get even greater bust after build

 

I'm sensing an asset store product in the making.

 

Even tho, It would be nightmare to maintain it, at current pace of DOTS evolution. Just look at current Classic OOP based assets, and how many become obsolete, in no time.
Better, either waiting 1year + before ECS stabilizes, or keep it for own game, or put on something like github.

 

IDK. Let's ask @LennartJohansen how Vegetation Studio Pro is doing. (An asset which utilizes the Job System extensively AFAIK)

I think if you only use Jobs, you're safe. (Okay as safe as a normal Unity Asset project can be...) The complication comes when you try to involve something pure preview like ECS or something complicated with Burst (although I think that is also close to stabilized).

 

I've been contemplating it, the only reason I haven't actually 'done' it yet is because it's simply made for outdoors E.G. - terrains, I'd like to eventually get it to work for any scenario. But haven't actually yet tried to figure out how to guess the current scene size like regular culling does. Nor does it ignore areas that have nothing in them - that wasn't the case I needed it for. But of course I could simply make it if it doesn't find anything to just turn off the cell. I try not to actually destroy anything as that amounts to more GC, a simple empty gameobject cell shouldn't amount to much memory being added I wouldn't think.

But yeah, making it get the current scene size I haven't look into yet, I'm sure there's some simple handy function somewhere that can do it.

 

Works both in Editor and Build. But I'm going to implement it to work even in scene view as well to cull and uncull based on scene camera.

[Edit]
There's not really any super magic too it, I'm just handling TreeInstances and objects in a way that removes a lot of unwanted LOD 'culls'. It became too unbearable the second a second mapmagic terrain generated. Went from 50ish FPS down to 12-20 FPS steadily. Took me a week to figure out tree instances and doing it in a way that resulted in less GC. It was so bad when I first started GC was nearly a gig every time a check went through to check player distance. I got that down to nearly non existent now.

[Edit 2]
Actually I have no idea if the GC even exists now, I just figured out how to make it work and it literally never spiked a frame at all. So haven't actually even checked for GC because of how efficient it was. But I will do it soon now.

 

Sure with Jobs is ok, since it was out of preview for relatively "long" time, in comparison to ECS, which still sits in its nappies.

Saying that, if anyone is concerned to use ECS itself yet, Jobs is good way, to prepare code, for transforming into ECS, If required in future. But to make all easier, Data Oriented Design should be in place from beginning.