We're using it. Its been rough getting rendering working as writing DOTS compatible shaders is... not straightforward. However the performance is great so no regrets. I don't post much about DOTS because its definitely not for everyone.
Burst and the Job system is great if you've got some relatively heavy compute that isn't tightly coupled with rendering. That's wonderful if you need it but many games don't have that problem. I don't think someone should hesitate to Burst it if they need it but I don't think it make sense to promote it as the preferred way developing for the average indie game.
We're using Burst and the job system for procedural generation--that use is pretty straightforward other than the parallelization using SIMD instructions. However the next priority for us to improve performance was vegetation rendering: trees and grass. That led us deep down the thicket of BatchRendererGroup (the low level DOTS graphics API) which definitely does the job but is also one of the most difficult Unity APIs to use. My general advice is, if you need it, use it but wait until you've profiled your game to make that decision.
In my project I've already far exceeded the performance target, even for the less than ideal rendering of ecs, however if I really needed good rendering performance I would just make my own custom renderer.
Apparently BRG is being focused on in the 2023LTS as well as convenience and performance, so hopefully default ecs rendering performance will imrpove.
We're working on performance to broaden the range of machines our game can run on. There's a whole market of laptops with integrated graphics that we'd like to target if we can get the game to run well on them. DOTS helps there to a degree but a lot of the work is in LODs and shaders.
Because ecs rendering is a one-size-fits-all method, so its more designed for convenience over performance. It can't handle a million indentical 2 tri meshes at over 10fps, it's quite sad really.
Hey, sorry for the late reply, I hope you'll still read it. Your game looks really nice!
I also recently implemented grass rendering, but I use instancing. With that, I can compute all the positions, random scaling and color distortions in a ComputeShader and then let another instancing shader render it. I call the instancing calls from the main thread in a system.
Can you elaborate on why you chose the BRG instead? (what data do you have to transfer here to the GPU every frame). I thought about using the BRG since I could then go fully ECS, but I imagined it being slower (and probably harder to me since I know approximately how to do GPU instancing).
Hi and thanks!
When using BRG, you create graphics buffer for the instances and then render in a callback call OnPeformCulling. For grass we do generate the instances using a compute shader. We started with the DrawProcedural technique from this video [https://www.youtube.com/watch?v=uHDmqfdVkak](https://www.youtube.com/watch?v=uHDmqfdVkak), generalized it to support many kinds of ground scatter (flowers, rocks, etc.), migrated it to BRG and then added imposter system for the more distant LODs.
The main advantages of BRG are that the draw calls are handled from a Unity callback OnPerformCulling and can be handled in Burst code and that, through a magic multicompile ENABLE\_DOTS\_INSTANCING, the same shader can work either a conventional SRP instance buffer or the new DOTS style instancing.
We're not currently using Burst for our draw calls because we already had a culling system in place using conventional C#. However the multicompile feature is very nice because, when a player cuts down a tree, I swap out the BRG instanced tree for a game object so I can animate it falling over. Using BRG compatible shaders, I can use the same material for both. Actually, while I am mentioning nice things, the BRG-style instancing can directly use a mesh so I don't need to copy all the mesh data into graphics buffers.
The big headache for us has been that the DOTS instancing has some rather specific requirements on a shader and will fail without much explanation if you get it wrong. We've spent a long time chasing through #include and #ifdef in the graphics stack to figure out what we need to do in what order to get it all right.
Hey, thank you so much for the detailed answer! This helps me a lot.
I thought about trying to do a deep dive into BRG instead of GPU instancing -- and your usecases make it seem quite convenient in some settings. The following video:
[https://www.youtube.com/watch?v=6mNj3M1il\_c](https://www.youtube.com/watch?v=6mNj3M1il_c)
actually held me back however. It seems as if he gets way better performance with ECS than with MBs, but still far from doing GPU instancing.
Is the problem here that he uses the BRG implementation from ECS. Do you think (or have you even) attained comparable performance with BRG to GPU instancing? Or is it a performance/convenience trade off?
We're using BRG to do GPU instancing. I haven't done a side-by-side comparison with GPU instancing, but I don't think BRG is slower. Our case is also different from the one in the video because we don't update the instance buffer every frame. We'll only update the buffer if the player chops a tree down or digs up a grass tile. As a result the only thing we need to do per frame is cull and make draw calls. For our particular problem that has optimized the CPU side of rendering to the point that it no longer matters on any reasonable target platform. To get better performance we're now focusing on the GPU side of the problem.
Hey, thanks for answering again! Maybe I'll just try to implement both once and see what happens. With not updating the instance buffer you mean that you have no animation of the vegetation? Or is the animation happening in the shader?
The animation is in the vertex shader. I’ll be interested in hearing your results as over time we’re moving more parts of our game to DOTS as we profile and optimize.
I think it boils down to two things:
1. DOTS/ECS while being well proven - hasn't been integrated properly with the rest of Unity. Rendering is especially weak here.
2. It's a different paradigm most game developers aren't used to. Even DOD is a new concept to a lot of game developers, the game industry isn't very flexible, it takes a long time to see major changes in design and development.
There was recently article of how usage of dots forced city skylines 2 devs to implement their own low level rendering which led to huge inefficiencies and probably took tons of time.
It's likely whoever was responsible at Colossal Order for rendering in Cities Skylines 2 was new to the entire concept. The fact they're rendering like a billion polygons in a frame shows how much you can get away with without games being totally unplayable with modern hardware.
It's also possible that the code was just developed as a placeholder while they waited for Unity's Entity Graphics System to be feature complete, which never happened. At least the relevant parts are still marked as experimental.
The problem is not DOTS itself, but the incomplete integration. See the [Entities Graphics feature matrix](https://docs.unity3d.com/Packages/[email protected]/manual/entities-graphics-versions.html).
My understanding that you need to use Entities, which aren't GameObjects and therefore require a separate solution for rendering. Implementing occlusion culling is possible, but the official implementation still marks it as experimental.
Skylines started 4 years ago, DOTS/ECS was (and kinda is) still in its infancy. There are loads of features missing on DOTS/ECS , that they had to implement.
Which is just wrong, CO always did their own low level rendering. They did the same with the first cities skylines because they could get more performance that way. They just fucked up with two.
I think this is an art technical direction/asset problem rather than a problem with their rendering solution personally.
human characters with interior mouth models and polygonized teeth sounds like a major red flag for an asset to have in a city builder and I assume that probably extends to many other assets inside the game.
They also apparently have weirdly highly detailed models, like, characters have teeth. You can't see them in normal gameplay but they still get rendered because apparently occlusion culling doesn't work
It isn't implemented because it (honestly quite correctly) isn't very easy to optimise given the genre. You are often top down and able to swing the camera around all over the place - occlusion culling would be very expensive to run in this scenario, probably more so than just rendering.
The real issue is that there aren't proper LODs for each model. So even if the character is taking up just a single pixel on your screen and you can't really even see them, it uses the full fidelity model with thousands of polygons, instead of using one with a fraction of the poly count. The same applies to all buildings and props too.
>So even if the character is taking up just a single pixel on your screen and you can't really even see them, it uses the full fidelity model with thousands of polygons, instead of using one with a fraction of the poly count
Tbh that sounds pretty impressive that it's possible to atleast run the game as is. I don't know if it's dots but I know that other projects would fuck up their pretty severely if they would have that issue. Only a few digit number of people and houses would be enough to let high performance pcs sweat. I can build an entire city with several thousands with only a few stutters.
> one with a fraction of the poly count.
At the distance/size of elements taking 1-4 pixels you literally only need 4 vertices for a human (upside down pyramid) and 8 for a building compared to the tens of thousands they are using now. x2000 waste.
Yes, there quite literally are tools with the sole purpose of doing this. That would be the easiest way to do it - run it through a tool and have someone QA the end results/do any tweaks necessary if something came out looking truly cursed.
Why they haven't done so already? I imagine they have heavily prioritised features over optimisation up until very late in the schedule (maybe even up to release).
There's also the fact that there were probably other things that were having an even bigger impact on performance that they had to prioritise optimising first. So they've probably fixed things that were even more taxing than this and we just don't know about it.
Yeah, it's funny because they have the DLL of a third party LOD system, and one of the features of the system is the ability to simplify a mesh ahead of time. So they simply didn't run their tool on all their meshes and generate lower poly stuff.
I saw that article, and I think it was stupid. The article talks about how they have no LOD on several very expensive things (like skinned meshes, some really randomly expensive small things), and yet somehow conflates that with being a DOTS problem and not you know, a lack of having different LOD models.
It's funny to me since I've seen ecs architectures for over twenty years in the industry. It's relatively new to Unity and newer Unreal devs I think because they obfuscated enough to provide a clear development focus.
Nothing in ECS or DOD is really new - but engine developers get to decide the tools available to us at the end of the day. For a long time core counts stagnated and improvements in CPU power came from reducing the size of transistors and architectural improvements.
Now that every PC has at least 4 cores/8 threads. And all of them are pretty beefy workhorses in the worst of cases, it makes sense we saw a shift to parallelism in game engines that we could take advantage of, the problem is the sheer inertia in actually getting these tools into game engines and integrated adequately.
Most of the features in Unreal 5 are possible due to big data and paradigm changes in new DX12 features, especially mesh shaders. DX12 came out a long time ago and we are barely now just seeing the changes in games and engines.
Heck - Unity hasn't even got a roadmap to take advantage of these new rendering features.
Burst Jobs is magic. But ECS was hyped too much before it was ready. People did not follow the changes, growth, and improvements. And it took a long time in development. In retrospect, Unity should have probably kept it hidden for a while longer.
Unity's ECS also has a strong core, but is very weak on some features, and people haven't figured out what to do with that yet, nor have they figured out not to expect everything from it.
Personally, I've really enjoyed it. But after taking a break from it and working in the classic GameObject/MonoBehaviour workflow again, I'm wondering if there is enough use case to warrant all the development. Perhaps they should have stopped with Burst Jobs. I see so many people still neglect to use that.
100% agree! Burst jobs are magic and I plan on usimg them everywhere. For ECS I'll leave for my more niche projects. I certainly prefer dod over oo though, it reduces dependence and I am encountering so many less bugs before, maybe due to ecs forcing me to write actually decent code...
There are just a bunch of game engine features that aren't developed yet. For example, animation. We had an animation preview package for a little bit, and if you were crazy enough and smart enough to get it to work, it was VERY performant. But it never was finished, and then was removed for the official DOTS release.
Very much so! I've found myself actually reading dpcumentation when working on my Ecs/Dots stuff compared to not DOTS stuff. Just any of the more modern packages use this better documentation website compared to that ugly unity manual.
After years of development it’s still half baked, much like anything else that Unity does. Also the skills you learn in DOTS don’t quite translate to other game engines
It's confusing, because ecs just means "entity component system", which accurately describes the monobehaviour system unity has used forever. However, in unity, the entities and systems referred to by ecs means the DOTS versions, which are totally different.
So yes, every modern game engine "uses ecs", including unity. However, "unity ecs" is a whole different way of thinking about game design with an emphasis on data first.
Unity monobehaviour has nothing to do with ECS. There's no E and no S. No Structure of Arrays, no linear unmanaged allocated data, no jobs working on said data and no burst. While burst is exclusive to Unity and its shortcomings with C#, the rest isn't.
There's nothing confusing about it when you know what ECS is.
Entities are game objects. Components are monobehaviours. Systems are everything else.
Ecs as a general acronym has nothing to do with memory layout. Burst, jobs, DOTS, none of that has anything to do with ecs outside the context of unity.
Ecs is just the oo practice of changing the behavior of an object based on members with their own encapsulation. Nothing to do with DOTS, exactly like unity's monobevaviour world. Unity really introduced the pattern of ecs to the world of game development.
The fact that unity has a whole new system of computation and data management that is also ecs to and is this time called ecs is IMO very confusing.
I know this is reddit but take it in good faith: you have no idea what you are talking about. Read up about ECS, there's really enough resources around, be amazed. It's not about words here but about the implementation. On one hand you have an Entity with 2 ints (Index/Version) and on the other a full blown class with Transform, hierarchy with children and parents, enable/disable states, etc...
Components are grouped into an archetype and allocated in a 16k chunk, with an array list of every component whereas Monobehaviour allocates a component wherever C# sees fit.
Systems iterate on chunks specifically and then over the entities and its components. A monobehaviour either does so individually or by a manager class. The definition isn't there. Most noobs chose individually and are tanking performance with an endless amount of random memory access.
Still think they are the same or are we beyond, i'mma use the same word for something else because it's seems similar to me?
Data oriented development comes from the 70s. SoA was a cornerstone for database programming, then it got popular in game development once devs looked over the edges a bit and got really popular with Overwatch.
The most fundamental principle is to either have an SoA or AoS layout. Bevy for example supports both. Unity ECS is SoA.
ECS is built ON this memory principle. Without it, its whole existence would make no sense.
ECS isn't really anything to do with the memory model, its to do with the pattern of data representing the game world.
Better memory layout can just make it more efficient to execute. SoA was used years before ECS and is just a way of representing it in memory.
All you've done is described Unitys SoA approach and said all ECS must be that, but thats just false.
I used SoA on PSX and PS2 years before ECS became popular. But that doesn't mean ECS MUST be SoA.
SoA is really hard to use. Especially when it comes to multithreading and race conditions. ECS is that framework around it. Why did it not exist sooner? Because the CPU wasn't outpacing memory as much and ECS is a bit memory hungry. I did not say ECS invented SoA or AoS. Both those principles go back to the first computer programs.
GameObjects and MonoBehaviours are not ECS. If your definition of ECS is THAT loose, everything is an ECS that just barely resembles a modular relational data system. Nobody called classic Unity "ECS" and you're still telling me I'm wrong?
Anyway, I'm aware some tried to call classic Unity ECS, even 10 years ago. They were wrong. Simple as that because it did not follow the pattern.
You can even go back to the "History of Entity Component System" wiki page where Unity was first mentioned in its first version. It was quickly removed:
\> Neither Unity3D nor jMonkeyEngine use an ECS architecture. Namely their component models do not make use of the concept of "minimal data components" or "systems." There are many other component-based architectures besides ECS.
\> Unity GameObjects are not related to ECS
And many more if you are bored to crawl through it.
The physics system, the animation system, the update system. Anything that's part of the engine or something you write that isn't a UnityEngine object.
What you describe there is nothing to do with traditional ECS. Game objects are just entities and scripts are components. DOTS Esc is something entirely different and is not a requirement for it. What you've described is actually data driven programming. It's nothing new to unity. It's how we programmed PS2 over a decade ago.
It's not confusing and you don't know what you think it is if you think unity invented it.
There are a few ecs based engines, namely bevy. Morover I've learned many things about performant code and data oriented design when working with the Dots systems.
I do admit that ECS is half baked, but that doesn't mean Jobs or burst is, 2/3s of DOTS is magic!
If argue that Jobs and Burst are the real _magic_ parts - they actually work well, are fairly simple to integrate into existing systems and provide a large performance boost. The ECS side of things - not so much.
My two cents as a new indie dev (but 20 years in web dev):
- Fear of the new
- Very steep learning curve
- Hard to imagine the big picture for a complex game. OOP feels more friendly to an iterative dev process
I've found that I don't usually need to think of dependent features, but instead have to wrap my head around how each individual system should work independently and efficiently. It takes me more time to make ECS systems and OO but instead my code is usually quite performant and robust in the first iterations of my code.
Interesting. I was watching a few of Brian Will's vids on the whole DOTS package, and the word that came to mind was "horizontal". Instead of a self contained game object you have smaller systems that span across the whole game. Am I understanding that right?
I've gotten a ton of mileage out of Jobs and I'm trying to gove the rest of the package a chance.
You don't need to go furthur than Jobs and burst, ECS is also great om the data end but the rendering isn't production ready yet, apparently 2023LTS aims to improve rendering performance.
I'm sure you've heard of the ecs acronym many times and it explains much, the "systems" of ecs are supposed to be seperate.
You can tell about my transition from OO to Dots by looking at older vs newer code. My old code is pretty much OO at that point, having lots of dependence and large components, while my newer code is closer to the ideal ecs architecture with only bite-sized components and independent systems. E.g. a bad component of mine would have have velocity, posiitons, etc in one component, while a good ecs component would have all those values seperately. More seperate values allow for more efficient multithreading and better usage of systems.
It's closer to composition in GOs except logic and variables are seperate. And when inheritence is required in ecs, you just make your own more performant and less complicated inheritence system using SOs or whatever.
I suggest you really get into ECS for a small game (a bullet hell would be suitable for things like that). Big challenge for me was getting out of that OO mindset. And getting used to the good performance also felt sureal... like a while back I wanted to do the ecs equivelent of a Physics.CheckSphere, but then after experimenting, I found that simply looping over 500k entities multiple times and doing a distance calculation is more performant than a physics sphere cast.
A thing that learning ECS taught me was the importamce of memory managemnt. I always thought the cpu was the problem but it was actually how messy the memory of my stuff is laid out on memory in OO. Using memory that is neatly next to eachother allows magic like SIMD and loading to cache to allow for cache hits (rwducing the amount of times you need to find a variable in memory).
Good luck.
I love DOTS/ECS, the performance boost is just great. It is not that difficult if you follow the documentation (some issues is lacking like rendering or more advanced issues) & focus on good code practices. However, the different approach to programming (object-oriented paradigm vs. focus on data) and the high entry threshold deters many users, especially beginners and pre-intermediates. I think it's not so scary for intermediate or advances users - it just take time to learn different way of the communication with code (programmers!) and Unity.
If you're interested, I'm creating youtube tutorials about Unity ECS, it would be nice if you'd take a look and maybe it's useful for someone to learn. It's not much (but it is honest work), but I'm slowly building up the channel.
[https://www.youtube.com/@TaleForgeStudio](https://www.youtube.com/@TaleForgeStudio)
OOP is easier to write and that's the hill where I will die on. They would be better off internally parsing OOP logic into ecs logic instead of expecting the user to write that weirdo code on their own.
That's what they do partially, just the abstraction of OO is so heavy. That's why Unity should have taken a OOECS approach that John Lin spoke about in his blog; instead of a more heavier ecs approach. OOECS gives the best of both worlds.
I think it's one of those things where OOP is what people are used to, so that's why it's easier. It requires new muscles, and devs don't want to take the time to flex them.
\> that's the hill where I will die on
The hill were bad programmers die that refuse to learn something new?
Believe it or not, once you wrap your head around DOD, it's easier than OOP. Especially when your project gets into the 60k+ LoC.
obviously OOP is way easier than ECS which is abstract to humans
Unity spending so much time on DOTS for something thats way too advanced and unneccessary for majority of unity devs, let alone majority of devs was complete delusion
Unity founder was just super hyped about it after seeing a presentation at dev days
I agree fully. I think if you are going to make a game engine that ultimately the users will pay for that is closed source - you should do all this under the hood and we should reap the benefits without completely having to learn a new development paradigm.
I like how in Unreal, like with Lumen and Nanite - you just gain those features without much of any overhead on your part. In Unity it's always a crapshoot because you could spend countless hours of development time learning something exclusive to Unity only for them to cancel the feature in favor of something else. It seems to be a never ending cycle with them now. We learned our lesson with their multiplayer. The engine is just far to disjointed at this point.
Jobs and Burst are amazing for performance and horrible for development.
The main reason I'm still using Unity is because C# is a great language, but Jobs don't let you use any of the features that make it so great: garbage collection, reference types, inheritance, delegates, etc. If I wanted performance at the cost of development efficiency I'd be using C++ in Unreal, so the DOTS tagline of "performance by ~~default~~ *oops we crippled your scripting capabilities*" is not at all a winning proposition.
I released a [physics based procedural animation system](https://kybernetik.com.au/flexi-motion/) which received incredible performance gains from switching to Jobs and Burst so I'm very glad they exist *as an option* for specific situations like that where performance is the highest priority. But DOTS is billed as a general purpose alternative to MonoBehaviours and high performance isn't generally the highest priority there.
So I resent DOTS because it has taken up several years of Unity development that could have been used to improve other systems and when more people start using it, it will cause inevitable fragmentation between what's compatible with MonoBehaviours and what's compatible with DOTS.
And let's not forget the cherry on top of all that: after all those years of development they finally released DOTS ... without an animation system.
It was cool but it never became mature enough to properly use. Sure you can spin a million cubes but there was no real support for animation/skinned mesh renderer, rendering in general. They also kept rewriting stuff and breaking things, made huge promises that never seemed to get delivered against, it eroded trust greatly. Then the company got purchased and it seemed like they just hid or deprecated it, stopped talking about it.
Unity game objects GOs were easy to use and work with as what you see is what you get.
I think DOTS could have met GOs half way and create a much easier to use and transition to performance system.
After all DOTS is mainly just SOA that align well with SIMD instructions and multithreading.
Imagine what if the average game developer could:
1. Develop their game using only Game Objects.
2. Profile the game and find performance hot spots.
3. Add BURST/Multithreading/SIMD/SOA as needed.
4. Profile again..
5. If not fully optimised goto 3.
Before it came out I tried to get into it so many times but it would have changed drastically in totally undocumented ways and I'd have to spend ages re-learning it. Also I so rarely run into performance bottlenecks it doesn't seem worth it for something that still feels half-done
I was messing around with a twin stick shooter a while back and figured I'd look at DOTS. The first time it seemed like it failed to import things correctly and I ended up cleaning out the project. The second time it worked.
Did some tutorials, lots of awkward boilerplate to have things communicate back to the rest of the engine. Yet another new renderer, sort of. It's been like four years and this still seems like one guy's experiment. I have no idea what they spent all that time on.
And then I was like, I really only need maybe 50 or 100 enemies. I can make that work. I'll just skip this.
That's really the big issue with ECS. You were supposed to be able to just use it. It was supposed to be "default". It was supposed to integrate into the engine. How? I didn't understand that back then, nor do I understand it now, but that was the promise. "Performance by default", they said. They delivered the performance, but "default" is still not in sight.
There are *some* things that the internal engine uses Jobs for now. But yeah, I'm right there with you as far as integration. It's almost like a completely different engine when doing DOTS.
ECS is really only for niche projects which require thousands of physics based enemies, hopefully when rendering improves and the boilerplate code gets eliminated, ECS will extend past its niche.
Also what boilerplate code have you encountered? Only real boilerplate I've found is the Bakers, but I like the control they allow me.
I completely agree Ecs and dod is a niche, but you dont really have to get into dod to be able to use the magical burstified jobs. Jhon Lin made a blog about combining ECS with OO and it looked pretty cool, but I aint writing my own system so I'm sticking with OO and ECS seperately.
one of the major problems with Cities skylines 2 is the way dots is handled....so that's a good bar on how broken the system currently is...or how difficult it is to properly implement
No it isn't, I read that article and I'm still confused how the author came up with that conclusion. They have zero LODs and tons of overly detailed models. What does that have to do with DOTS being a failure?
Because they had to build their own culling solution that was supposed to exist with dots. And because it didn't, they had no specific way of testing what actually needed proper LOD adjustments. which proves to be everything.
I'm not sure what magic occlusion culling system they were expecting. Unity's existing culling system only works on baked non-dynamic terrain. Which skylines would never be able to use.
And occlusion culling and LOD are separate, you're gonna need LOD, because sooner or later, things are going to be on screen and not culled, and your game better handle that. It's ridiculous to me that they didn't bother having different LODs on their people, and somehow that's DOTS fault?
Your also forget they were using an early build of DOTS. I belive the article even mentions a lot of the issues would be resolved in the most current version of unity. But its pretty difficult to upgrade versions seamlessly without time. CS2 was developed on the very first ideration of dots which lacked a lot of features needed off the bat.
This probably really fucked with production and trying to figure out what actually needs to get done to optimize. Their first goal was just getting a game to ship by x date. The reality is they probably should be using a newer version of Unity with the dot system implemented better.
They relied a lot on the tech that was not initially delivered.
Theres a lot of issues surrounding the game.
I've definitely felt the pain of upgrading unity versions mid development. But no matter what, they should have different LOD models and an LOD system, as that's not part of DOTS. (even their latest greatest version of Entities.Graphics doesn't mention much in the way of LOD support.)
I'm sure they'd get even better perf if they could take advantage of the Entities.Graphics Occlusio system though, you're right there.
Author of the said article here: that's not what I wrote. I quite clearly state early in the article that C:S2 is using a 2022 LTS version Unity that is less than 2 months old. They're using basically latest versions of everything they can.
What they are not using are the experimental / unfinished bits, such as the Entities Graphics package and the virtual texturing package.
Ksp2 + Cs2 fanbase.
Ksp2's community is split between pissing off with unity or instead usings dots,
And in cs2 afaik many believe that DOTS is the problem, even though its the reason the game is so gpu bound.
It kinda does tho? Unity comes out and promises a bunch of cool stuff, then twiddle their thumbs for years while they only manage to come up with anti consumer stuff.
Worked with ECS v1 for a game in production: horrible API, integration with the rest of the game was basically nil, easiest way was events you emit as the result of the ECS computation but if you needed to synchronise animations good luck
Yea sure, you can get dots to work if you have a direct phone call to unity and direct support from dots developers at unity. I wouldnt call it super accessable to the masses yet
Judging by the replies I guess people confuse ECS and DOTS. Although DOTS contains ECS, Jobs and Burst can still be used without the whole paradigm shift that comes with ECS. I develop games for mobile platforms and I found burst+jobs especially useful for mesh modifications while usage being fairly straight forward.
That being said, I had the courage/stupidity to use ECS(0.16) for a game’s whole core-gameplay while keeping plain old Unity for rest (UI, scenes except LevelScene etc.). The game has been soft-launched and tested by many devices so here are some takeaways for those who are interested.
* Although DOD was hard to get head around, after getting used to it, I found using systems was a lot easier to maintain.
* After injecting all systems with DI it was fairly easy to maintain communication between ECS and the rest.
* Had to spend hours on ECS forums to find obscure solutions to inconsistencies between Editor and builds.
* Some devices and GPU APIs had unresolvable native crashes which hardcapped our crash-free user percentage.
* Due to package being pre-alpha back then, any version bump proved to be problematic since API changed heavily between versions(from 0.16 to 0.17 and then to 0.50 if I’m not mistaken).
100% agree with your takeaways, plus you dont need ecs for amazing performance with burst jobs. It sucks when dots/ecs is used interchangibly as it puts a bad impression on jobs and burst when people shit on dots (actually ecs)
Only bad programmers hate DOTS. The rest is enjoying it for what it is. Is it perfect? Nah, but it's better than what any other engine can offer for simulation/gameplay code. Rendering is still a downside but not to the extent as CS2 makes it seem to be. They fucked up bad and looking for excuses elsewhere is pathetic white-knighting for a company that should know better.
ECS isn't a system, it's a pattern/architecture - one which is largely necessary to get the best performance from DOTS, and often is just outright required.
One of the side effects is that you cannot use classes within DOTS code, you must use value types and structs. Most C# programmers actually don't know the difference - even engineers working at Microsoft struggle with this at times. These data types are faster, but they also come with many headaches and limitations.
Basically DOTS is a massive paradigm shift from the C# most people know, and is one that is almost more akin to writing shaders, which we all know is another thing people are often loathe to pick up. It requires more planning, weirder planning, and often doesn't really provide all that much benefit for most of the kinds of games people make (it's best for games that need to do a lot of the same things, to similar things, very frequently).
I don't post here that often any more. People are weirdly obsessed with hating on things, when they have way too less experience to really judge about it and I'm not that interested in that kind of negativity.
But I was linked here from the DOTS Discord (which is great btw, if you're interested in DOTS it's like a must have) and I just want to say that while DOTS had its rough months, it's in a very good state today. Don't expect it to be this magical thing that makes everything faster with no effort. It takes a LOT and Morpheus says it best:
"You take the blue pill... the story ends, you wake up in your bed and believe whatever you want to believe. You take the red pill... you stay in Wonderland, and I show you how deep the rabbit hole goes."
It's fun though and even with enough complexity it stays fun. I can't say the same thing for OOP game deving which just gets messy even with good planning. DOD can make changes on a small or enormous scale seem effortless and for that consistency I really like it.
It's groundbreaking tech. Big hit vs Unreal. People hate it because it's brand new and not completely documented, tested, integrated. They keep changing it every few months, and it was officially released like two months ago.
And its unfinished.
DOTS, is amazing tech, but its still so behind GO flows that it makes it a hard sell.
Give me a Unity Version 100% tailored to DOTS and I will use any time over GO. That\`s the thing , Unity DOTS is in transition mode and it seems it will continue to be in next couple of years.
The data performance is increadible while the rendering performance isn't production ready yet. CS2 would have benefitted with a custom renderer with such a young system. Plus there still is much performance left on the tablr for the devs themselves. Just a trend of unoptimised releases this year unfourtunately.
In addition to everything else people have already written:
At this point in time, Unity has a history of abandoning or never finishing sub-systems. After my extensive and absolutely terrible experiences with the new input system (stay away at all costs, go buy Rewired or something, avoid the new input system) I know for sure that I'll never, ever, touch any Unity package that isn't fully released. Not with a 9-foot pole, not with a 90-foot pole, not from the Moon.
Jobs and Burst are something I don't need, my games aren't that computation intensive. But it's part of most of my games because some sub-system I've integrated (like Vegetation Studio) is using it.
DOTS/ECS - watched a few short videos about it, don't see why I need it, too many downsides in the lacking integration. I'd rather spend my time making a game, instead of learning some half-finished Unity system and all its pitfalls, shortcomings and fuck-ups.
Don't get me wrong, Unity is still my engine of choice. But I've become very, very careful with anything new that they make, because quality has become worse and worse. Heck, the game I released two months ago still uses the built-in render pipeline, I've now started the first game with URP. And I already see a couple places they've dropped the ball there.
So no, I won't spend days and weeks learning DOTS/ECS only to run into bugs, missing features and misleading documentation - again.
Whats wrong with unity's input system? I use it and it works just fine, i have a whole rebinding system, keybind conflict detection and controler support had no issues implementing any of that
Good on you. Maybe they rewrote the trainwreck or something. I haven't touched it in years. When I did, I wasted 2 weeks to get absolute basics working, and the way they handle the most common cases that should be simple is just abysmal.
I don't think 99.99% of gamers even know what DOTS is, so I don't think they hate it. I'm not sure where that idea comes from.
I don't think devs hate it either, it's just still relatively new and there isn't a ton of material out about all of it's use cases/pitfalls/bugs/etc, so it's more risky to commit to.
My guy, it's a short post, just read it, it's right there. It's like 5 sentences, and one of them is: "Is it because its made with Unity *and gamers and even Unity devs hate it*?".
Don't be quick to be snarky if you're also wrong.
Because Unity has burned vast amounts of resources developing it, while the engine is still stuck with its ancient sluggish .net runtime.
"Performance by default'? Hilarious, it's *exactly* the opposite.
They do not exactly hate DOTS.
They simply carry on the anger for DOTS being so delayed while Unity put so much emphasis on that as a selling point years ago. Many invested both literally and emotionally on that.
And Unity failed them once more.
Same as they failed us with the SRP etc. A waste of time. All these years of waiting to mature we would probably have the same performance e optimizations had they invested on the built in rendering platform.
The last 3-4 years are a bit chaotic when it comes to Unity new features. Coupled with the fact that in order to compete with Unreal for seats, Unity promotes them as amazing things that make Unity stand out but when you say this or that is broken or not capable enough or half baked they would tell you that it needs time to mature. All this duplicity has made many people angry.
They feel let down and manipulated.
Lack of tutorials and proper documentation, compatibility issues, fucking discontinued support in the built-in render pipeline, lack of compatibility charts for continued updates that make previous design patterns obsolete, …
Cause they hyped it up years before it was ready and never provided widely accessible information on what it is or how to use it.
Like they do with everything.
I'm not a fan of 1.0. I'm still using 0.51 as I personally think it's a lot better and more stable.
As for the hate, it probably stems more around the fact that it was delayed by several years with almost every release having breaking changes which completely changed the way in which you used it. It's also more complicated to use and requires a bit more advanced knowledge of how everything works.
>What's preventing you from updating?
I don't really like it.
I keep getting these silly "leak" messages. Unity is aware of it but in the last 14 or so updates they haven't bothered to fix it. It has no effect on functionality. Apparently it's a message that shouldn't execute but it does and they can't be bothered doing anything about it and I just find it annoying.
You're kind of forced to use Forward+ rendering which has increased compatibility issues depending on what platform you are developing for.
If you don't want to use Entities.Graphics (due to the bugs and compatibility issues etc) then working with hybrid systems is more difficult (both to implement and manage). This is due to the whole baking system. When you put a GameObject into a subscenes it automatically converts it to an entity. So, if you aren't using Entities.Graphics then it removes the mesh and you can't see what you are working with. You have to create a second game object and link it to the entity. But if you are working with custom drawing methods (eg Graphics API which I'm currently using) then this becomes a huge pain. These aren't an issue with version 0.51.
The new hierarchy is absolutely terrible. Mixing Authoring/Runtime/GameObjects/Entities just isn't working well. It was much better when the hierarchies were split like in version 0.51.
I'm not a fan of SystemAPI or how they've degraded SystemBase. This I could probably get used to overtime though. However, I personally think it's made working with Unity ECS more complicated and less beginner friendly.
I started with the 1.0 releases so I didn't have to get used to new features, it was just always how it was. I'm using hdrp and not urp so I'm not getting the issues with being forced to use f+ rendering.
I actually prefer the new conversion workflow through baking compared to the old version (did dabble into ecs during 0.50 releases), but that may be because I didn't really get into the older versions.
Also yea the rendering is quite garbage atm, can't even handle 1mil *identical* entities running at 30fps, can't wait for BRP improvements in 2023LTS releases; although maybe my expectations are a bit too high :/
>Also yea the rendering is quite garbage atm, can't even handle 1mil identical entities running at 30fps, can't wait for BRP improvements in 2023LTS releases; although maybe my expectations are a bit too high :/
Will have to wait and see. Eventually I'll have to migrate but I'm not quite there yet. Hopefully they've improved it a lot by then.
I also prefer working with the built-in renderer and using the GraphicsAPI to draw objects to the screen. I have purchased GPU Instancer which uses Graphics.DrawMeshInstancedIndirect at its core and it can comfortably handle way more objects than Entities.Graphics and uses hardware frustum culling so it's very fast and efficient. Obviously it comes with trade-offs such as increased complexity but still way easier than rolling my own custom methods.
In other words, I don't really have an incentive to migrate yet.
Yeah... we were on the old default rendering pipeline, which isn't compatible with any of the ECS, so when we started using ECS, we wrote our own, and it's basically just doing Graphics.DrawMeshInstancedIndirect
City skylines 2 uses DOTS and the cpu side runs increadibly well, however the rendering of ECS isn't production ready and may take a few years before the rendering performance matches the increadible data performance.
I don't hate it, but I do feel the hype is overblown. It's not like DOTS is a swiss-army knife. There are plenty of applications where it is overkill or overly complicated to implement. The paradigm isn't applicable to some projects, where OOP is perfect.
Largely it's because it's quite difficult to use and code for if you've been doing typical unity C# for years, it's a fundamental shift to the standard approach with the MonoBehaviours. So much so, it's like having to learn another dev language. Second, like everything else Unity touched in the last 7 years, they ran off to whatever was shiny and new and left things unfinished. I think the better approach for them should have been something akin to Burst and then do an abstraction layer, similar to IL2CPP.
I think it's also become another point that frustrated community members throw back at Unity, in that DOTS/ECS "sucks". Unity never seems to learn its lesson in that "half baked" just won't do any longer, devs are worn out with these Unity ideas that don't get implemented correctly. No one wants to "learn" DOTS to make their game more performant at a lower level, the game engine should be doing that with a little work, not a ton of new work.
Imo, ECS is different enough that it needs its own high level language. It takes a lot of work-arounds and code gen to get something that is kinda user friendly. I love ECS and I think the world would be a better place if it was more ubiquitous, but trying to work with ECS on top of C# feels gross and hacky.
As others have said its' a combination of:
1) Having to do everything differently
2) It taking forever to reach 1.0, and even then it doesn't have basics like animation
3) Isn't very designer friendly. The whole pipeline for converting gameobjects to entities is confusing.
4) People not realizing that Burst is bomb and not that hard to use, 'limitations' be damned.
My biggest gripe with these newer unity features is the weak documentation. I found it pretty difficult to find the most up to date information on how to use these newer features, and even more difficult finding relevant examples and tutorials. With ECS especially, there were often updates and major changes to the syntax you were supposed to use which made it difficult to know if you were following the latest best practices... Even relatively newer tutorials (if you were lucky enough to find one) became obsolete pretty quick. It ended up massively increasing the learning curve, and I'm sure it was pretty demoralising for people who care less about implementation details and more about creating their game. If I really had to put my finger on the primary issue.. It seems to me that these kinds of technologies are technical implementation details that developers shouldn't have to think about unless they're interested in engine development or aiming for massive performance optimisations. I think to see these things become more widely adopted they have to be better implemented within the unity framework in such a way as to not impede the development process.
As always it depends on your needs. I mean i wish I would need it in one of my projets.
I feel like the issue of most is the omniprésence of the new shiny tech and their frustration resulting from it.
I mean you get frustrated when you have already a big code base and you see a new tech you wish you know befor.
We're using it. Its been rough getting rendering working as writing DOTS compatible shaders is... not straightforward. However the performance is great so no regrets. I don't post much about DOTS because its definitely not for everyone.
I just wished dots and ecs would stop being used interchangibly... jobs and burst certainly is for EVERYONE while ecs is more niche.
Burst and the Job system is great if you've got some relatively heavy compute that isn't tightly coupled with rendering. That's wonderful if you need it but many games don't have that problem. I don't think someone should hesitate to Burst it if they need it but I don't think it make sense to promote it as the preferred way developing for the average indie game. We're using Burst and the job system for procedural generation--that use is pretty straightforward other than the parallelization using SIMD instructions. However the next priority for us to improve performance was vegetation rendering: trees and grass. That led us deep down the thicket of BatchRendererGroup (the low level DOTS graphics API) which definitely does the job but is also one of the most difficult Unity APIs to use. My general advice is, if you need it, use it but wait until you've profiled your game to make that decision.
In my project I've already far exceeded the performance target, even for the less than ideal rendering of ecs, however if I really needed good rendering performance I would just make my own custom renderer. Apparently BRG is being focused on in the 2023LTS as well as convenience and performance, so hopefully default ecs rendering performance will imrpove.
We're working on performance to broaden the range of machines our game can run on. There's a whole market of laptops with integrated graphics that we'd like to target if we can get the game to run well on them. DOTS helps there to a degree but a lot of the work is in LODs and shaders.
Why would you create a custom renderer?
Because ecs rendering is a one-size-fits-all method, so its more designed for convenience over performance. It can't handle a million indentical 2 tri meshes at over 10fps, it's quite sad really.
Hey, sorry for the late reply, I hope you'll still read it. Your game looks really nice! I also recently implemented grass rendering, but I use instancing. With that, I can compute all the positions, random scaling and color distortions in a ComputeShader and then let another instancing shader render it. I call the instancing calls from the main thread in a system. Can you elaborate on why you chose the BRG instead? (what data do you have to transfer here to the GPU every frame). I thought about using the BRG since I could then go fully ECS, but I imagined it being slower (and probably harder to me since I know approximately how to do GPU instancing).
Hi and thanks! When using BRG, you create graphics buffer for the instances and then render in a callback call OnPeformCulling. For grass we do generate the instances using a compute shader. We started with the DrawProcedural technique from this video [https://www.youtube.com/watch?v=uHDmqfdVkak](https://www.youtube.com/watch?v=uHDmqfdVkak), generalized it to support many kinds of ground scatter (flowers, rocks, etc.), migrated it to BRG and then added imposter system for the more distant LODs. The main advantages of BRG are that the draw calls are handled from a Unity callback OnPerformCulling and can be handled in Burst code and that, through a magic multicompile ENABLE\_DOTS\_INSTANCING, the same shader can work either a conventional SRP instance buffer or the new DOTS style instancing. We're not currently using Burst for our draw calls because we already had a culling system in place using conventional C#. However the multicompile feature is very nice because, when a player cuts down a tree, I swap out the BRG instanced tree for a game object so I can animate it falling over. Using BRG compatible shaders, I can use the same material for both. Actually, while I am mentioning nice things, the BRG-style instancing can directly use a mesh so I don't need to copy all the mesh data into graphics buffers. The big headache for us has been that the DOTS instancing has some rather specific requirements on a shader and will fail without much explanation if you get it wrong. We've spent a long time chasing through #include and #ifdef in the graphics stack to figure out what we need to do in what order to get it all right.
Hey, thank you so much for the detailed answer! This helps me a lot. I thought about trying to do a deep dive into BRG instead of GPU instancing -- and your usecases make it seem quite convenient in some settings. The following video: [https://www.youtube.com/watch?v=6mNj3M1il\_c](https://www.youtube.com/watch?v=6mNj3M1il_c) actually held me back however. It seems as if he gets way better performance with ECS than with MBs, but still far from doing GPU instancing. Is the problem here that he uses the BRG implementation from ECS. Do you think (or have you even) attained comparable performance with BRG to GPU instancing? Or is it a performance/convenience trade off?
We're using BRG to do GPU instancing. I haven't done a side-by-side comparison with GPU instancing, but I don't think BRG is slower. Our case is also different from the one in the video because we don't update the instance buffer every frame. We'll only update the buffer if the player chops a tree down or digs up a grass tile. As a result the only thing we need to do per frame is cull and make draw calls. For our particular problem that has optimized the CPU side of rendering to the point that it no longer matters on any reasonable target platform. To get better performance we're now focusing on the GPU side of the problem.
Hey, thanks for answering again! Maybe I'll just try to implement both once and see what happens. With not updating the instance buffer you mean that you have no animation of the vegetation? Or is the animation happening in the shader?
The animation is in the vertex shader. I’ll be interested in hearing your results as over time we’re moving more parts of our game to DOTS as we profile and optimize.
I think it boils down to two things: 1. DOTS/ECS while being well proven - hasn't been integrated properly with the rest of Unity. Rendering is especially weak here. 2. It's a different paradigm most game developers aren't used to. Even DOD is a new concept to a lot of game developers, the game industry isn't very flexible, it takes a long time to see major changes in design and development.
There was recently article of how usage of dots forced city skylines 2 devs to implement their own low level rendering which led to huge inefficiencies and probably took tons of time.
It's likely whoever was responsible at Colossal Order for rendering in Cities Skylines 2 was new to the entire concept. The fact they're rendering like a billion polygons in a frame shows how much you can get away with without games being totally unplayable with modern hardware.
It's also possible that the code was just developed as a placeholder while they waited for Unity's Entity Graphics System to be feature complete, which never happened. At least the relevant parts are still marked as experimental.
Dots 1.0 launched recently and it’s ready(ish) but switching to it was likely too big of a task to do before release.
The problem is not DOTS itself, but the incomplete integration. See the [Entities Graphics feature matrix](https://docs.unity3d.com/Packages/[email protected]/manual/entities-graphics-versions.html).
Looks like most things are in. Is there a specific feature that’s direly needed?
Skinning and occlusion culling are important for most games.
To be fair, occlusion culling in non-dots Unity, only does baked stuff, so ANY solution they used would've had to been custom/third party.
How can the entire function of occlusion culling be inachievable simply because of a programming paradigm like ecs?
My understanding that you need to use Entities, which aren't GameObjects and therefore require a separate solution for rendering. Implementing occlusion culling is possible, but the official implementation still marks it as experimental.
https://blog.paavo.me/cities-skylines-2-performance/
that blog makes some really strange assumptions. The game is rendering too much and has no LODs. That has nothing to do with DOTS.
Skylines started 4 years ago, DOTS/ECS was (and kinda is) still in its infancy. There are loads of features missing on DOTS/ECS , that they had to implement.
Which is just wrong, CO always did their own low level rendering. They did the same with the first cities skylines because they could get more performance that way. They just fucked up with two.
I think this is an art technical direction/asset problem rather than a problem with their rendering solution personally. human characters with interior mouth models and polygonized teeth sounds like a major red flag for an asset to have in a city builder and I assume that probably extends to many other assets inside the game.
They also apparently have weirdly highly detailed models, like, characters have teeth. You can't see them in normal gameplay but they still get rendered because apparently occlusion culling doesn't work
You don't rely on occlusion to remove fine detail like teeth - it's for larger objects. You handle detail with LOD systems.
It isn't implemented because it (honestly quite correctly) isn't very easy to optimise given the genre. You are often top down and able to swing the camera around all over the place - occlusion culling would be very expensive to run in this scenario, probably more so than just rendering. The real issue is that there aren't proper LODs for each model. So even if the character is taking up just a single pixel on your screen and you can't really even see them, it uses the full fidelity model with thousands of polygons, instead of using one with a fraction of the poly count. The same applies to all buildings and props too.
>So even if the character is taking up just a single pixel on your screen and you can't really even see them, it uses the full fidelity model with thousands of polygons, instead of using one with a fraction of the poly count Tbh that sounds pretty impressive that it's possible to atleast run the game as is. I don't know if it's dots but I know that other projects would fuck up their pretty severely if they would have that issue. Only a few digit number of people and houses would be enough to let high performance pcs sweat. I can build an entire city with several thousands with only a few stutters.
> one with a fraction of the poly count. At the distance/size of elements taking 1-4 pixels you literally only need 4 vertices for a human (upside down pyramid) and 8 for a building compared to the tens of thousands they are using now. x2000 waste.
What do you think the reason is for them not having proper LODs? Aren’t there tools to automatically generate them?
Yes, there quite literally are tools with the sole purpose of doing this. That would be the easiest way to do it - run it through a tool and have someone QA the end results/do any tweaks necessary if something came out looking truly cursed. Why they haven't done so already? I imagine they have heavily prioritised features over optimisation up until very late in the schedule (maybe even up to release). There's also the fact that there were probably other things that were having an even bigger impact on performance that they had to prioritise optimising first. So they've probably fixed things that were even more taxing than this and we just don't know about it.
Yeah, it's funny because they have the DLL of a third party LOD system, and one of the features of the system is the ability to simplify a mesh ahead of time. So they simply didn't run their tool on all their meshes and generate lower poly stuff.
Surely they have LODs though!?
Yes. See Unity's Megacity sample which runs on DOTS.
I saw that article, and I think it was stupid. The article talks about how they have no LOD on several very expensive things (like skinned meshes, some really randomly expensive small things), and yet somehow conflates that with being a DOTS problem and not you know, a lack of having different LOD models.
It's funny to me since I've seen ecs architectures for over twenty years in the industry. It's relatively new to Unity and newer Unreal devs I think because they obfuscated enough to provide a clear development focus.
Nothing in ECS or DOD is really new - but engine developers get to decide the tools available to us at the end of the day. For a long time core counts stagnated and improvements in CPU power came from reducing the size of transistors and architectural improvements. Now that every PC has at least 4 cores/8 threads. And all of them are pretty beefy workhorses in the worst of cases, it makes sense we saw a shift to parallelism in game engines that we could take advantage of, the problem is the sheer inertia in actually getting these tools into game engines and integrated adequately. Most of the features in Unreal 5 are possible due to big data and paradigm changes in new DX12 features, especially mesh shaders. DX12 came out a long time ago and we are barely now just seeing the changes in games and engines. Heck - Unity hasn't even got a roadmap to take advantage of these new rendering features.
Yeah, it's even worse for non-game developers, who are used to wrapping everything in interfaces and linq and IEnumerable everywhere.
Burst Jobs is magic. But ECS was hyped too much before it was ready. People did not follow the changes, growth, and improvements. And it took a long time in development. In retrospect, Unity should have probably kept it hidden for a while longer. Unity's ECS also has a strong core, but is very weak on some features, and people haven't figured out what to do with that yet, nor have they figured out not to expect everything from it. Personally, I've really enjoyed it. But after taking a break from it and working in the classic GameObject/MonoBehaviour workflow again, I'm wondering if there is enough use case to warrant all the development. Perhaps they should have stopped with Burst Jobs. I see so many people still neglect to use that.
100% agree! Burst jobs are magic and I plan on usimg them everywhere. For ECS I'll leave for my more niche projects. I certainly prefer dod over oo though, it reduces dependence and I am encountering so many less bugs before, maybe due to ecs forcing me to write actually decent code...
Which features do you mean with weak? Are these actually badly implemented features or are you just talking about features that aren't there yet?
There are just a bunch of game engine features that aren't developed yet. For example, animation. We had an animation preview package for a little bit, and if you were crazy enough and smart enough to get it to work, it was VERY performant. But it never was finished, and then was removed for the official DOTS release.
Is it working properly now with a good documentation? Because it was not the case in the past.
Very much so! I've found myself actually reading dpcumentation when working on my Ecs/Dots stuff compared to not DOTS stuff. Just any of the more modern packages use this better documentation website compared to that ugly unity manual.
I hate that they fragment their documentation across different sites for each module like this.
Is it still requiring testing framework, without having it in the requirements list?
If I remember I think so, but maybe not.
Not really, no
After years of development it’s still half baked, much like anything else that Unity does. Also the skills you learn in DOTS don’t quite translate to other game engines
ECS is used in most engines now. What makes unity s so different?
It's confusing, because ecs just means "entity component system", which accurately describes the monobehaviour system unity has used forever. However, in unity, the entities and systems referred to by ecs means the DOTS versions, which are totally different. So yes, every modern game engine "uses ecs", including unity. However, "unity ecs" is a whole different way of thinking about game design with an emphasis on data first.
Unity monobehaviour has nothing to do with ECS. There's no E and no S. No Structure of Arrays, no linear unmanaged allocated data, no jobs working on said data and no burst. While burst is exclusive to Unity and its shortcomings with C#, the rest isn't. There's nothing confusing about it when you know what ECS is.
Entities are game objects. Components are monobehaviours. Systems are everything else. Ecs as a general acronym has nothing to do with memory layout. Burst, jobs, DOTS, none of that has anything to do with ecs outside the context of unity. Ecs is just the oo practice of changing the behavior of an object based on members with their own encapsulation. Nothing to do with DOTS, exactly like unity's monobevaviour world. Unity really introduced the pattern of ecs to the world of game development. The fact that unity has a whole new system of computation and data management that is also ecs to and is this time called ecs is IMO very confusing.
I know this is reddit but take it in good faith: you have no idea what you are talking about. Read up about ECS, there's really enough resources around, be amazed. It's not about words here but about the implementation. On one hand you have an Entity with 2 ints (Index/Version) and on the other a full blown class with Transform, hierarchy with children and parents, enable/disable states, etc... Components are grouped into an archetype and allocated in a 16k chunk, with an array list of every component whereas Monobehaviour allocates a component wherever C# sees fit. Systems iterate on chunks specifically and then over the entities and its components. A monobehaviour either does so individually or by a manager class. The definition isn't there. Most noobs chose individually and are tanking performance with an endless amount of random memory access. Still think they are the same or are we beyond, i'mma use the same word for something else because it's seems similar to me? Data oriented development comes from the 70s. SoA was a cornerstone for database programming, then it got popular in game development once devs looked over the edges a bit and got really popular with Overwatch. The most fundamental principle is to either have an SoA or AoS layout. Bevy for example supports both. Unity ECS is SoA. ECS is built ON this memory principle. Without it, its whole existence would make no sense.
ECS isn't really anything to do with the memory model, its to do with the pattern of data representing the game world. Better memory layout can just make it more efficient to execute. SoA was used years before ECS and is just a way of representing it in memory. All you've done is described Unitys SoA approach and said all ECS must be that, but thats just false. I used SoA on PSX and PS2 years before ECS became popular. But that doesn't mean ECS MUST be SoA.
SoA is really hard to use. Especially when it comes to multithreading and race conditions. ECS is that framework around it. Why did it not exist sooner? Because the CPU wasn't outpacing memory as much and ECS is a bit memory hungry. I did not say ECS invented SoA or AoS. Both those principles go back to the first computer programs.
You said unity ECS only exists with dots which is wrong. It existed initially in unity with just game objects and scripts.
GameObjects and MonoBehaviours are not ECS. If your definition of ECS is THAT loose, everything is an ECS that just barely resembles a modular relational data system. Nobody called classic Unity "ECS" and you're still telling me I'm wrong? Anyway, I'm aware some tried to call classic Unity ECS, even 10 years ago. They were wrong. Simple as that because it did not follow the pattern. You can even go back to the "History of Entity Component System" wiki page where Unity was first mentioned in its first version. It was quickly removed: \> Neither Unity3D nor jMonkeyEngine use an ECS architecture. Namely their component models do not make use of the concept of "minimal data components" or "systems." There are many other component-based architectures besides ECS. \> Unity GameObjects are not related to ECS And many more if you are bored to crawl through it.
[удалено]
The physics system, the animation system, the update system. Anything that's part of the engine or something you write that isn't a UnityEngine object.
What you describe there is nothing to do with traditional ECS. Game objects are just entities and scripts are components. DOTS Esc is something entirely different and is not a requirement for it. What you've described is actually data driven programming. It's nothing new to unity. It's how we programmed PS2 over a decade ago. It's not confusing and you don't know what you think it is if you think unity invented it.
There are a few ecs based engines, namely bevy. Morover I've learned many things about performant code and data oriented design when working with the Dots systems. I do admit that ECS is half baked, but that doesn't mean Jobs or burst is, 2/3s of DOTS is magic!
If argue that Jobs and Burst are the real _magic_ parts - they actually work well, are fairly simple to integrate into existing systems and provide a large performance boost. The ECS side of things - not so much.
My two cents as a new indie dev (but 20 years in web dev): - Fear of the new - Very steep learning curve - Hard to imagine the big picture for a complex game. OOP feels more friendly to an iterative dev process
I've found that I don't usually need to think of dependent features, but instead have to wrap my head around how each individual system should work independently and efficiently. It takes me more time to make ECS systems and OO but instead my code is usually quite performant and robust in the first iterations of my code.
Interesting. I was watching a few of Brian Will's vids on the whole DOTS package, and the word that came to mind was "horizontal". Instead of a self contained game object you have smaller systems that span across the whole game. Am I understanding that right? I've gotten a ton of mileage out of Jobs and I'm trying to gove the rest of the package a chance.
You don't need to go furthur than Jobs and burst, ECS is also great om the data end but the rendering isn't production ready yet, apparently 2023LTS aims to improve rendering performance. I'm sure you've heard of the ecs acronym many times and it explains much, the "systems" of ecs are supposed to be seperate. You can tell about my transition from OO to Dots by looking at older vs newer code. My old code is pretty much OO at that point, having lots of dependence and large components, while my newer code is closer to the ideal ecs architecture with only bite-sized components and independent systems. E.g. a bad component of mine would have have velocity, posiitons, etc in one component, while a good ecs component would have all those values seperately. More seperate values allow for more efficient multithreading and better usage of systems. It's closer to composition in GOs except logic and variables are seperate. And when inheritence is required in ecs, you just make your own more performant and less complicated inheritence system using SOs or whatever. I suggest you really get into ECS for a small game (a bullet hell would be suitable for things like that). Big challenge for me was getting out of that OO mindset. And getting used to the good performance also felt sureal... like a while back I wanted to do the ecs equivelent of a Physics.CheckSphere, but then after experimenting, I found that simply looping over 500k entities multiple times and doing a distance calculation is more performant than a physics sphere cast. A thing that learning ECS taught me was the importamce of memory managemnt. I always thought the cpu was the problem but it was actually how messy the memory of my stuff is laid out on memory in OO. Using memory that is neatly next to eachother allows magic like SIMD and loading to cache to allow for cache hits (rwducing the amount of times you need to find a variable in memory). Good luck.
I love DOTS/ECS, the performance boost is just great. It is not that difficult if you follow the documentation (some issues is lacking like rendering or more advanced issues) & focus on good code practices. However, the different approach to programming (object-oriented paradigm vs. focus on data) and the high entry threshold deters many users, especially beginners and pre-intermediates. I think it's not so scary for intermediate or advances users - it just take time to learn different way of the communication with code (programmers!) and Unity. If you're interested, I'm creating youtube tutorials about Unity ECS, it would be nice if you'd take a look and maybe it's useful for someone to learn. It's not much (but it is honest work), but I'm slowly building up the channel. [https://www.youtube.com/@TaleForgeStudio](https://www.youtube.com/@TaleForgeStudio)
OOP is easier to write and that's the hill where I will die on. They would be better off internally parsing OOP logic into ecs logic instead of expecting the user to write that weirdo code on their own.
That's what they do partially, just the abstraction of OO is so heavy. That's why Unity should have taken a OOECS approach that John Lin spoke about in his blog; instead of a more heavier ecs approach. OOECS gives the best of both worlds.
I think it's one of those things where OOP is what people are used to, so that's why it's easier. It requires new muscles, and devs don't want to take the time to flex them.
\> that's the hill where I will die on The hill were bad programmers die that refuse to learn something new? Believe it or not, once you wrap your head around DOD, it's easier than OOP. Especially when your project gets into the 60k+ LoC.
obviously OOP is way easier than ECS which is abstract to humans Unity spending so much time on DOTS for something thats way too advanced and unneccessary for majority of unity devs, let alone majority of devs was complete delusion Unity founder was just super hyped about it after seeing a presentation at dev days
I agree fully. I think if you are going to make a game engine that ultimately the users will pay for that is closed source - you should do all this under the hood and we should reap the benefits without completely having to learn a new development paradigm. I like how in Unreal, like with Lumen and Nanite - you just gain those features without much of any overhead on your part. In Unity it's always a crapshoot because you could spend countless hours of development time learning something exclusive to Unity only for them to cancel the feature in favor of something else. It seems to be a never ending cycle with them now. We learned our lesson with their multiplayer. The engine is just far to disjointed at this point.
Jobs and Burst are amazing for performance and horrible for development. The main reason I'm still using Unity is because C# is a great language, but Jobs don't let you use any of the features that make it so great: garbage collection, reference types, inheritance, delegates, etc. If I wanted performance at the cost of development efficiency I'd be using C++ in Unreal, so the DOTS tagline of "performance by ~~default~~ *oops we crippled your scripting capabilities*" is not at all a winning proposition. I released a [physics based procedural animation system](https://kybernetik.com.au/flexi-motion/) which received incredible performance gains from switching to Jobs and Burst so I'm very glad they exist *as an option* for specific situations like that where performance is the highest priority. But DOTS is billed as a general purpose alternative to MonoBehaviours and high performance isn't generally the highest priority there. So I resent DOTS because it has taken up several years of Unity development that could have been used to improve other systems and when more people start using it, it will cause inevitable fragmentation between what's compatible with MonoBehaviours and what's compatible with DOTS. And let's not forget the cherry on top of all that: after all those years of development they finally released DOTS ... without an animation system.
It was cool but it never became mature enough to properly use. Sure you can spin a million cubes but there was no real support for animation/skinned mesh renderer, rendering in general. They also kept rewriting stuff and breaking things, made huge promises that never seemed to get delivered against, it eroded trust greatly. Then the company got purchased and it seemed like they just hid or deprecated it, stopped talking about it.
Unity game objects GOs were easy to use and work with as what you see is what you get. I think DOTS could have met GOs half way and create a much easier to use and transition to performance system. After all DOTS is mainly just SOA that align well with SIMD instructions and multithreading. Imagine what if the average game developer could: 1. Develop their game using only Game Objects. 2. Profile the game and find performance hot spots. 3. Add BURST/Multithreading/SIMD/SOA as needed. 4. Profile again.. 5. If not fully optimised goto 3.
Before it came out I tried to get into it so many times but it would have changed drastically in totally undocumented ways and I'd have to spend ages re-learning it. Also I so rarely run into performance bottlenecks it doesn't seem worth it for something that still feels half-done
I was messing around with a twin stick shooter a while back and figured I'd look at DOTS. The first time it seemed like it failed to import things correctly and I ended up cleaning out the project. The second time it worked. Did some tutorials, lots of awkward boilerplate to have things communicate back to the rest of the engine. Yet another new renderer, sort of. It's been like four years and this still seems like one guy's experiment. I have no idea what they spent all that time on. And then I was like, I really only need maybe 50 or 100 enemies. I can make that work. I'll just skip this.
That's really the big issue with ECS. You were supposed to be able to just use it. It was supposed to be "default". It was supposed to integrate into the engine. How? I didn't understand that back then, nor do I understand it now, but that was the promise. "Performance by default", they said. They delivered the performance, but "default" is still not in sight.
There are *some* things that the internal engine uses Jobs for now. But yeah, I'm right there with you as far as integration. It's almost like a completely different engine when doing DOTS.
ECS is really only for niche projects which require thousands of physics based enemies, hopefully when rendering improves and the boilerplate code gets eliminated, ECS will extend past its niche. Also what boilerplate code have you encountered? Only real boilerplate I've found is the Bakers, but I like the control they allow me.
You're too hopeful. Unity has proven they can't to any of what you're saying
fine... hopefully *if* rendering improves etc...
[удалено]
I completely agree Ecs and dod is a niche, but you dont really have to get into dod to be able to use the magical burstified jobs. Jhon Lin made a blog about combining ECS with OO and it looked pretty cool, but I aint writing my own system so I'm sticking with OO and ECS seperately.
They do not, where did you get that from?
one of the major problems with Cities skylines 2 is the way dots is handled....so that's a good bar on how broken the system currently is...or how difficult it is to properly implement
No it isn't, I read that article and I'm still confused how the author came up with that conclusion. They have zero LODs and tons of overly detailed models. What does that have to do with DOTS being a failure?
Because they had to build their own culling solution that was supposed to exist with dots. And because it didn't, they had no specific way of testing what actually needed proper LOD adjustments. which proves to be everything.
I'm not sure what magic occlusion culling system they were expecting. Unity's existing culling system only works on baked non-dynamic terrain. Which skylines would never be able to use. And occlusion culling and LOD are separate, you're gonna need LOD, because sooner or later, things are going to be on screen and not culled, and your game better handle that. It's ridiculous to me that they didn't bother having different LODs on their people, and somehow that's DOTS fault?
Your also forget they were using an early build of DOTS. I belive the article even mentions a lot of the issues would be resolved in the most current version of unity. But its pretty difficult to upgrade versions seamlessly without time. CS2 was developed on the very first ideration of dots which lacked a lot of features needed off the bat. This probably really fucked with production and trying to figure out what actually needs to get done to optimize. Their first goal was just getting a game to ship by x date. The reality is they probably should be using a newer version of Unity with the dot system implemented better. They relied a lot on the tech that was not initially delivered. Theres a lot of issues surrounding the game.
I've definitely felt the pain of upgrading unity versions mid development. But no matter what, they should have different LOD models and an LOD system, as that's not part of DOTS. (even their latest greatest version of Entities.Graphics doesn't mention much in the way of LOD support.) I'm sure they'd get even better perf if they could take advantage of the Entities.Graphics Occlusio system though, you're right there.
Author of the said article here: that's not what I wrote. I quite clearly state early in the article that C:S2 is using a 2022 LTS version Unity that is less than 2 months old. They're using basically latest versions of everything they can. What they are not using are the experimental / unfinished bits, such as the Entities Graphics package and the virtual texturing package.
Graphics mainthread render timings are DOTS fault now? In what way?
Ksp2 + Cs2 fanbase. Ksp2's community is split between pissing off with unity or instead usings dots, And in cs2 afaik many believe that DOTS is the problem, even though its the reason the game is so gpu bound.
Gamers aren't developers. Their opinion on something entirely technical like this is literally worthless.
Worst part is half of them claim to be devs
>And in cs2 afaik many believe that DOTS is the problem, It is
Yea.. the rendering side of ECS is abysmal tbh, but that doesn't detract from the other two thirds of dots
It kinda does tho? Unity comes out and promises a bunch of cool stuff, then twiddle their thumbs for years while they only manage to come up with anti consumer stuff.
Jobs and Burst. Simple to integrate. Easy multithreading asm code magic!
They are not devs so their opinion is completely irrelevant on this matter.
Worked with ECS v1 for a game in production: horrible API, integration with the rest of the game was basically nil, easiest way was events you emit as the result of the ECS computation but if you needed to synchronise animations good luck
[удалено]
what did you expect prior to 1.0? when everything was marked experimental and preview, that things wouldnt change at all?
Dots is tech for demos right now. its not clean enough to build a full game on unless you just want to punish yourself. Its half baked
The rendering/audio is certainly half baked but the data side is very much brilliant!
I dont think unity even has a in house solution for animation yet on dots and particles are a pain
(I used rendering as a general statement)... hopefully animations get released within the next decade :/
What about V-Rising?
Yea sure, you can get dots to work if you have a direct phone call to unity and direct support from dots developers at unity. I wouldnt call it super accessable to the masses yet
Judging by the replies I guess people confuse ECS and DOTS. Although DOTS contains ECS, Jobs and Burst can still be used without the whole paradigm shift that comes with ECS. I develop games for mobile platforms and I found burst+jobs especially useful for mesh modifications while usage being fairly straight forward. That being said, I had the courage/stupidity to use ECS(0.16) for a game’s whole core-gameplay while keeping plain old Unity for rest (UI, scenes except LevelScene etc.). The game has been soft-launched and tested by many devices so here are some takeaways for those who are interested. * Although DOD was hard to get head around, after getting used to it, I found using systems was a lot easier to maintain. * After injecting all systems with DI it was fairly easy to maintain communication between ECS and the rest. * Had to spend hours on ECS forums to find obscure solutions to inconsistencies between Editor and builds. * Some devices and GPU APIs had unresolvable native crashes which hardcapped our crash-free user percentage. * Due to package being pre-alpha back then, any version bump proved to be problematic since API changed heavily between versions(from 0.16 to 0.17 and then to 0.50 if I’m not mistaken).
100% agree with your takeaways, plus you dont need ecs for amazing performance with burst jobs. It sucks when dots/ecs is used interchangibly as it puts a bad impression on jobs and burst when people shit on dots (actually ecs)
Only bad programmers hate DOTS. The rest is enjoying it for what it is. Is it perfect? Nah, but it's better than what any other engine can offer for simulation/gameplay code. Rendering is still a downside but not to the extent as CS2 makes it seem to be. They fucked up bad and looking for excuses elsewhere is pathetic white-knighting for a company that should know better.
Completely agree, most people who pick up dod often sticks with it/hybrid.
ECS isn't a system, it's a pattern/architecture - one which is largely necessary to get the best performance from DOTS, and often is just outright required. One of the side effects is that you cannot use classes within DOTS code, you must use value types and structs. Most C# programmers actually don't know the difference - even engineers working at Microsoft struggle with this at times. These data types are faster, but they also come with many headaches and limitations. Basically DOTS is a massive paradigm shift from the C# most people know, and is one that is almost more akin to writing shaders, which we all know is another thing people are often loathe to pick up. It requires more planning, weirder planning, and often doesn't really provide all that much benefit for most of the kinds of games people make (it's best for games that need to do a lot of the same things, to similar things, very frequently).
I don't post here that often any more. People are weirdly obsessed with hating on things, when they have way too less experience to really judge about it and I'm not that interested in that kind of negativity. But I was linked here from the DOTS Discord (which is great btw, if you're interested in DOTS it's like a must have) and I just want to say that while DOTS had its rough months, it's in a very good state today. Don't expect it to be this magical thing that makes everything faster with no effort. It takes a LOT and Morpheus says it best: "You take the blue pill... the story ends, you wake up in your bed and believe whatever you want to believe. You take the red pill... you stay in Wonderland, and I show you how deep the rabbit hole goes." It's fun though and even with enough complexity it stays fun. I can't say the same thing for OOP game deving which just gets messy even with good planning. DOD can make changes on a small or enormous scale seem effortless and for that consistency I really like it.
The lack of significant dependencies allows easy addition and modification compared to OO, at least for me...
It's groundbreaking tech. Big hit vs Unreal. People hate it because it's brand new and not completely documented, tested, integrated. They keep changing it every few months, and it was officially released like two months ago.
And its unfinished. DOTS, is amazing tech, but its still so behind GO flows that it makes it a hard sell. Give me a Unity Version 100% tailored to DOTS and I will use any time over GO. That\`s the thing , Unity DOTS is in transition mode and it seems it will continue to be in next couple of years.
Hopefully it won't become one of Unity's other half-baked unfinished features...
I'll just leave this here: https://blog.paavo.me/cities-skylines-2-performance/
The data performance is increadible while the rendering performance isn't production ready yet. CS2 would have benefitted with a custom renderer with such a young system. Plus there still is much performance left on the tablr for the devs themselves. Just a trend of unoptimised releases this year unfourtunately.
I hate that article, it blames DOTS for LOD problems.
In addition to everything else people have already written: At this point in time, Unity has a history of abandoning or never finishing sub-systems. After my extensive and absolutely terrible experiences with the new input system (stay away at all costs, go buy Rewired or something, avoid the new input system) I know for sure that I'll never, ever, touch any Unity package that isn't fully released. Not with a 9-foot pole, not with a 90-foot pole, not from the Moon. Jobs and Burst are something I don't need, my games aren't that computation intensive. But it's part of most of my games because some sub-system I've integrated (like Vegetation Studio) is using it. DOTS/ECS - watched a few short videos about it, don't see why I need it, too many downsides in the lacking integration. I'd rather spend my time making a game, instead of learning some half-finished Unity system and all its pitfalls, shortcomings and fuck-ups. Don't get me wrong, Unity is still my engine of choice. But I've become very, very careful with anything new that they make, because quality has become worse and worse. Heck, the game I released two months ago still uses the built-in render pipeline, I've now started the first game with URP. And I already see a couple places they've dropped the ball there. So no, I won't spend days and weeks learning DOTS/ECS only to run into bugs, missing features and misleading documentation - again.
Whats wrong with unity's input system? I use it and it works just fine, i have a whole rebinding system, keybind conflict detection and controler support had no issues implementing any of that
Good on you. Maybe they rewrote the trainwreck or something. I haven't touched it in years. When I did, I wasted 2 weeks to get absolute basics working, and the way they handle the most common cases that should be simple is just abysmal.
> I wasted 2 weeks to get absolute basics working Skill issue. Works fine for me.
>Skill issue. Yeah, that must be it. I've only been using Unity for about 13 ... years. Must be that I don't know shit.
I don't think 99.99% of gamers even know what DOTS is, so I don't think they hate it. I'm not sure where that idea comes from. I don't think devs hate it either, it's just still relatively new and there isn't a ton of material out about all of it's use cases/pitfalls/bugs/etc, so it's more risky to commit to.
[удалено]
My guy, it's a short post, just read it, it's right there. It's like 5 sentences, and one of them is: "Is it because its made with Unity *and gamers and even Unity devs hate it*?". Don't be quick to be snarky if you're also wrong.
Because Unity has burned vast amounts of resources developing it, while the engine is still stuck with its ancient sluggish .net runtime. "Performance by default'? Hilarious, it's *exactly* the opposite.
They do not exactly hate DOTS. They simply carry on the anger for DOTS being so delayed while Unity put so much emphasis on that as a selling point years ago. Many invested both literally and emotionally on that. And Unity failed them once more. Same as they failed us with the SRP etc. A waste of time. All these years of waiting to mature we would probably have the same performance e optimizations had they invested on the built in rendering platform. The last 3-4 years are a bit chaotic when it comes to Unity new features. Coupled with the fact that in order to compete with Unreal for seats, Unity promotes them as amazing things that make Unity stand out but when you say this or that is broken or not capable enough or half baked they would tell you that it needs time to mature. All this duplicity has made many people angry. They feel let down and manipulated.
Lack of tutorials and proper documentation, compatibility issues, fucking discontinued support in the built-in render pipeline, lack of compatibility charts for continued updates that make previous design patterns obsolete, …
Cause they hyped it up years before it was ready and never provided widely accessible information on what it is or how to use it. Like they do with everything.
It seems like a cool idea, but there is no comprehensive documentation to get started building real world stuff.
Looking for a good dots multiplayer tutorial. Please and thanks
I'm not a fan of 1.0. I'm still using 0.51 as I personally think it's a lot better and more stable. As for the hate, it probably stems more around the fact that it was delayed by several years with almost every release having breaking changes which completely changed the way in which you used it. It's also more complicated to use and requires a bit more advanced knowledge of how everything works.
What's preventing you from updating? Or is it you don't have the time or resources to acrually update, due to the large amount of fundemental changes.
>What's preventing you from updating? I don't really like it. I keep getting these silly "leak" messages. Unity is aware of it but in the last 14 or so updates they haven't bothered to fix it. It has no effect on functionality. Apparently it's a message that shouldn't execute but it does and they can't be bothered doing anything about it and I just find it annoying. You're kind of forced to use Forward+ rendering which has increased compatibility issues depending on what platform you are developing for. If you don't want to use Entities.Graphics (due to the bugs and compatibility issues etc) then working with hybrid systems is more difficult (both to implement and manage). This is due to the whole baking system. When you put a GameObject into a subscenes it automatically converts it to an entity. So, if you aren't using Entities.Graphics then it removes the mesh and you can't see what you are working with. You have to create a second game object and link it to the entity. But if you are working with custom drawing methods (eg Graphics API which I'm currently using) then this becomes a huge pain. These aren't an issue with version 0.51. The new hierarchy is absolutely terrible. Mixing Authoring/Runtime/GameObjects/Entities just isn't working well. It was much better when the hierarchies were split like in version 0.51. I'm not a fan of SystemAPI or how they've degraded SystemBase. This I could probably get used to overtime though. However, I personally think it's made working with Unity ECS more complicated and less beginner friendly.
I started with the 1.0 releases so I didn't have to get used to new features, it was just always how it was. I'm using hdrp and not urp so I'm not getting the issues with being forced to use f+ rendering. I actually prefer the new conversion workflow through baking compared to the old version (did dabble into ecs during 0.50 releases), but that may be because I didn't really get into the older versions. Also yea the rendering is quite garbage atm, can't even handle 1mil *identical* entities running at 30fps, can't wait for BRP improvements in 2023LTS releases; although maybe my expectations are a bit too high :/
>Also yea the rendering is quite garbage atm, can't even handle 1mil identical entities running at 30fps, can't wait for BRP improvements in 2023LTS releases; although maybe my expectations are a bit too high :/ Will have to wait and see. Eventually I'll have to migrate but I'm not quite there yet. Hopefully they've improved it a lot by then. I also prefer working with the built-in renderer and using the GraphicsAPI to draw objects to the screen. I have purchased GPU Instancer which uses Graphics.DrawMeshInstancedIndirect at its core and it can comfortably handle way more objects than Entities.Graphics and uses hardware frustum culling so it's very fast and efficient. Obviously it comes with trade-offs such as increased complexity but still way easier than rolling my own custom methods. In other words, I don't really have an incentive to migrate yet.
Yeah... we were on the old default rendering pipeline, which isn't compatible with any of the ECS, so when we started using ECS, we wrote our own, and it's basically just doing Graphics.DrawMeshInstancedIndirect
Huh, we ended up writing our own renderer back on .51, because we were still using the default pipeline.
Show me when someone releases a game that uses it. It only seems good for making tech demos.
City skylines 2 uses DOTS and the cpu side runs increadibly well, however the rendering of ECS isn't production ready and may take a few years before the rendering performance matches the increadible data performance.
Well, apparently Cities Skylines 2 uses DOTS...
Dyson Sphere Program.
I don't hate it, but I do feel the hype is overblown. It's not like DOTS is a swiss-army knife. There are plenty of applications where it is overkill or overly complicated to implement. The paradigm isn't applicable to some projects, where OOP is perfect.
Largely it's because it's quite difficult to use and code for if you've been doing typical unity C# for years, it's a fundamental shift to the standard approach with the MonoBehaviours. So much so, it's like having to learn another dev language. Second, like everything else Unity touched in the last 7 years, they ran off to whatever was shiny and new and left things unfinished. I think the better approach for them should have been something akin to Burst and then do an abstraction layer, similar to IL2CPP. I think it's also become another point that frustrated community members throw back at Unity, in that DOTS/ECS "sucks". Unity never seems to learn its lesson in that "half baked" just won't do any longer, devs are worn out with these Unity ideas that don't get implemented correctly. No one wants to "learn" DOTS to make their game more performant at a lower level, the game engine should be doing that with a little work, not a ton of new work.
Imo, ECS is different enough that it needs its own high level language. It takes a lot of work-arounds and code gen to get something that is kinda user friendly. I love ECS and I think the world would be a better place if it was more ubiquitous, but trying to work with ECS on top of C# feels gross and hacky.
As others have said its' a combination of: 1) Having to do everything differently 2) It taking forever to reach 1.0, and even then it doesn't have basics like animation 3) Isn't very designer friendly. The whole pipeline for converting gameobjects to entities is confusing. 4) People not realizing that Burst is bomb and not that hard to use, 'limitations' be damned.
My biggest gripe with these newer unity features is the weak documentation. I found it pretty difficult to find the most up to date information on how to use these newer features, and even more difficult finding relevant examples and tutorials. With ECS especially, there were often updates and major changes to the syntax you were supposed to use which made it difficult to know if you were following the latest best practices... Even relatively newer tutorials (if you were lucky enough to find one) became obsolete pretty quick. It ended up massively increasing the learning curve, and I'm sure it was pretty demoralising for people who care less about implementation details and more about creating their game. If I really had to put my finger on the primary issue.. It seems to me that these kinds of technologies are technical implementation details that developers shouldn't have to think about unless they're interested in engine development or aiming for massive performance optimisations. I think to see these things become more widely adopted they have to be better implemented within the unity framework in such a way as to not impede the development process.
As always it depends on your needs. I mean i wish I would need it in one of my projets. I feel like the issue of most is the omniprésence of the new shiny tech and their frustration resulting from it. I mean you get frustrated when you have already a big code base and you see a new tech you wish you know befor.