Unite Berlin 2018 - Entity Component System, C# Job System and Burst Q&A
ฝัง
- เผยแพร่เมื่อ 29 ก.ย. 2024
- Joachim and Martin hold an open chat about Unity's new systems and the changes ahead. This talk also showcases some of the latest additions to the Entity Component System.
Speaker:
Martin Gram (Product Manager, Unity)
Joachim Ante (CTO, Unity)
So many amazing features. I like ECS reactive systems idea a lot, though contrary to the presenter's words I don't believe Added and Removed mechanisms look elegant in their current state. At the same time ChangeFilter, is great, and I wish we could mark our interest in certain types of added and removed components in the same, clear way.
What do you not like about the Added and Removed? It seems pretty simple to me, and seems to be how frameworks like EntityX handles it too.
It is simple, but not elegant. You need to create custom struct, and take care of it everytime you add given component just to get notified of the addition.
Also I was under an impression that EntityX exposes real events, without a hassle of tags like SystemStateComponentData, but haven't used it (or any other ECS framework) in production, so I may be wrong.
Wouldn't it be better had we an attribute like 'AddFilter' just like ChangeFilter?
Maybe there are technical obstacles that I can't see, but it's just hard for me to really consider what was shown elegant.
I'm playing with ECS right now. I don't know exactly what I'm doing, but playing with 200,000 spheres in realtime is pretty fun. I uploaded my first attempt on my channel a couple weeks ago.
Reactive?
OnNext, OnError, OnComplete? Nah! OnAdd, OnRemove, OnChange... Yeah, all three is the same thing basically: null->value, value->value, value->null. But mah EfficiencyByDefault!
Fine, I can wait...
Arrays and strings. Can't wait!
Does unity only want C# and not .Net ?
I still don't understand why unity doesn't use C# tasks and then allow us to use async + await in our code ... they would only need to implement a custom task scheduler surely instead of building out a whole new bunch of API stuff we all have to learn.
The ECS stuff looks cool but this use of structs to define a query is just plain weird ... who thinks of a type definition as a query ? what's up with say ... LINQ?
Unity does strange things but if it really adds up to real world gains instead of these tiny broken demo samples ... maybe there's something to it.
I think you can use threads and tasks in unity. There is nothing limiting you from using that.
Anyways, they decided to go with there own system to improve performance through spatial locality where each struct is aligned linearly. This improves the performance by a lot since there will be way less cache misses. Also they have created system where it is far less possibility of shooting yourself in the foot. Race conditions and Syncing is all handled by the system also through the special interfaces and dependencies.
They have many talks on this system with actual demos through out different events, you might want to look at those to see the advantages
Yes I know I can multiple threads or use tasks in C# ... but the key thing is that I can't interact with the unity API whilst doing so.
So no, we can't use threads / async code IN UNITY.
My point is ... if they solved that problem then the community could build out jobs / ECS, ect as packages for them.
They are clearly a crazy clever crew though and of course not working for them I don't know the problems they face.
I suspect there are cross platform concerns that often get in the way so they are trying to build out systems that "force the dev using unity to explain the project to the engine" in a way that the engine can do interesting things during compilation or something to heavily optimise.
kidmosey right ... Is that not the reason you can build your own scheduler for tasks?
The way I understand it is that the real magic here is happening during compilation.
Also that point above about complex task trees ... Surely you could get yourself in the same situation with jobs executing jobs too?
kidmosey interesting ... I hadn't thought about it like that ... I wonder if this opens up the way for us to write c# against ECS and the job system and unity to dynamically figure out during compilation that this job would better suit being handled by a GPU and so it automatically could build compute shaders and compile them in to the final build results
I'm not certain of your knowledge of Unity's history but the version of C# used by unity is branched off a very old version of C# because they branched off a very old version of Mono and so it may be some of these functions don't exist in Unity's version or don't work the same way.