4 ms·

I can't imagine them to just continue DOTS like normal after going silent for so long. If they don't axe it, then they may choose to do something drastically di

I can't imagine them to just continue DOTS like normal after going silent for so long. If they don't axe it, then they may choose to do something drastically different than before, like automatic ECS conversion under the hood. ECS is really good for things that scale. Architecturally, it has both pros and cons to OOP. After working with ECS for a few years, I came to the conclusion that OOP is still the best for behavioral richness. The current state of DOTS is just sad as it's affecting a lot of developments such as Tiny, unity.physics, dots audio, dots animation, etc... Burst and Jobs are probably the best things that came out of Unity's initial push for DOTS.

adanto6840 5y ago
I never understood why they didn't take this approach -- converting under-the-hood "automatically" to their ECS paradigm. The existing data-structures were/are already very similar to their ECS counterparts (though with substantially less boilerplate code); the main "issue" in trying to do an 'automatic conversion', at least that I could foresee, was related to references & non-blittable types. Even then, it seems like you could automatically convert all the data that is a blittable type, and then let the rest work "the old way" (read: sub-optimally, at least insofar as memory access goes -- and ideally/likely with some developer feedback via profiler improvements to demonstrate where [and by roughly how much] any non-blittable type access was actually costing you in performance). Just my 2c. I do concur with the above poster, though -- their ECS/DOTS has been basically ignored. At this point there's so, so, so much of the Unity ecosystem that just flat out fails to work beyond some very, very, very small scale that it's just mind-blowing. Want to use their physics, or nav-mesh agents, or even their sprite-rendering systems? Once you get 500-1k of any of those objects into a scene (ie, sprites!!), you've already blown way past your CPU/framerate budget. It's mind-boggling; especially when you can, for example with sprite rendering, run your own mesh with a bunch of quads and absolutely obliterate the performance you get from SpriteRenderers. Very frustrating & somewhat mind boggling TBH. I'd personally guess the vast majority of indie devs that use Unity are simply using it as a [mesh] rendering pipeline & practicing a "roll our own" approach for almost everything else.
- ratww 5y ago
  > I never understood why they didn't take this approach -- converting under-the-hood "automatically" to their ECS paradigm I completely agree. I've done compile-time code transformation/generation in C# using Reflection in the past, and while it's not really trivial, it's entirely feasible. I knew some people who did this independently because of things like INotifyPropertyChanged in WPF. They're already doing things that are way more advanced than that with the usage of the [BurstCompile] attribute. If anything, they could just restrict the usage of fields that don't work with it. > At this point there's so, so, so much of the Unity ecosystem that just flat out fails to work beyond some very, very, very small scale that it's just mind-blowing. Someone in here said that everything in Unity is either unmaintained or unfinished. I share this sentiment. :(

adanto6840 5y ago

I never understood why they didn't take this approach -- converting under-the-hood "automatically" to their ECS paradigm. The existing data-structures were/are already very similar to their ECS counterparts (though with substantially less boilerplate code); the main "issue" in trying to do an 'automatic conversion', at least that I could foresee, was related to references & non-blittable types. Even then, it seems like you could automatically convert all the data that is a blittable type, and then let the rest work "the old way" (read: sub-optimally, at least insofar as memory access goes -- and ideally/likely with some developer feedback via profiler improvements to demonstrate where [and by roughly how much] any non-blittable type access was actually costing you in performance). Just my 2c. I do concur with the above poster, though -- their ECS/DOTS has been basically ignored. At this point there's so, so, so much of the Unity ecosystem that just flat out fails to work beyond some very, very, very small scale that it's just mind-blowing. Want to use their physics, or nav-mesh agents, or even their sprite-rendering systems? Once you get 500-1k of any of those objects into a scene (ie, sprites!!), you've already blown way past your CPU/framerate budget. It's mind-boggling; especially when you can, for example with sprite rendering, run your own mesh with a bunch of quads and absolutely obliterate the performance you get from SpriteRenderers. Very frustrating & somewhat mind boggling TBH. I'd personally guess the vast majority of indie devs that use Unity are simply using it as a [mesh] rendering pipeline & practicing a "roll our own" approach for almost everything else.

ratww 5y ago
> I never understood why they didn't take this approach -- converting under-the-hood "automatically" to their ECS paradigm I completely agree. I've done compile-time code transformation/generation in C# using Reflection in the past, and while it's not really trivial, it's entirely feasible. I knew some people who did this independently because of things like INotifyPropertyChanged in WPF. They're already doing things that are way more advanced than that with the usage of the [BurstCompile] attribute. If anything, they could just restrict the usage of fields that don't work with it. > At this point there's so, so, so much of the Unity ecosystem that just flat out fails to work beyond some very, very, very small scale that it's just mind-blowing. Someone in here said that everything in Unity is either unmaintained or unfinished. I share this sentiment. :(