If there is no baking in a normal scene, then what about built-in authoring components that map into several IComponentDatas like Rigidbody? Do we need to add all components manually?
1 Like
Hm, okay I’ll try with a more specific question.
I have an authoring comp that adds CompA, CompB, BufferA and creates an additional entity with CompC.
I add this to a subscene GO, it’s baked, all fine.
Now I (want to) add the same comp to a GO in a scene. What happens?
From what you described, nothing will happen but my expectation is that it’s acting just the same as within a subscene GO.
1 Like
Since the Baking mechanism won’t run on normal scenes, nothing will happen.
How would some physics methods work in a (what I presume is) a PhysX world and an ECS world?
If I do a Physics.Raycast(..) in my MonoBehaviour, will this MonoBehaviour be able to hit all the colliders in the world, pure GameObject and pure ECS?
Or vise versa, If I do… whatever a raycast is in ECS, will it hit my normal game objects?
I asked this on discord yesterday
me: Now that you brought it up, how is physics working in 2.0?
(Do we still have 2 separate simulations that can’t interact or have they been unified like many other solutions)
response: I’m not sure I can share details on that right now sadly
and
me: one of you devs did hint a couple of months ago that physx might be on the way out and it’d be unfied physics solution, was just curious if there was anymore news
response: No, but we’re continuing work on the abstract interface (first item that Ashley is sharing in the roadmap in this post: Physics development status and next milestones - May 2024 - #3 by ashley_unity) that is a prerequisite.
So doesn’t really answer your question, but best I got out of Unity for now.
1 Like
I’m pretty hyped about GO → Entity interop support and specially the unified transform, great stuff!
On the other hand, it’s a bit demotivating that 2D has been mostly ignored in ECS land. Are there plans to at least ship a native sprite renderer for ECS as we’ve seen for 3D? Will this perhaps be handled by the unified renderer?
It feels so wasteful to use and deal with ECS if you’ll end up with a GO per entity anyway. I’m fine with having light 2ds, particle systems and even animations require a companion GO but sprites seem like such a low hanging fruit to tackle.
1 Like
You just treat sprites nosy like 3D objects, just on the 2D plane.
Regarding rendering, we had over past few years multiple solutions showcasing, how you can utilise DOTS to render in 2D.
In the end, sprite is mostly an animation and executing shader.
If you wanna to do really basic stuff, sure you could simply draw quads or texture a cube on one side only and call it 2D, but that doesn’t adress other features within unity that expect Sprites or Texture2Ds. For example you can’t use Mechanim based sprite animation if you’re drawing 3D objects, not without some un-intuitive workarounds.
You also lose basically the whole URP 2D suite of tools and features, like tilemaps, lit/unlit sprites, 2D lights, 2D colliders (although you might be able to use this with a bit of fiddling), 2D shadow casters, etc. Your existing shader graphs also have to be rewritten, your Z axis now means something and will impact sprite scale, you probably will need a different solution for Y sorting sprites, the list goes on. It’s not fair to simply assume that by drawing in 3D you’ll be able to use DOTS normally, you’ll need several new systems and workarounds.
If you’re within the context of a renderer yea sure Sprites are just quads, within the context of unity theres a lot more involved.
The existing solutions for 2D with ECS all revolve around having a companion GameObject that syncs its transform with an entities transform, Unity currently doesn’t have a native solution 2D within ECS. The performance of Entities.Graphics using this method is in fact worse than plain old GameObjects, in a scene with 10k GameObjects with sprite renderers and no logic, my PC achieved 84fps. When I authored the object using Entities.Graphics and spawned 10k entities, it achived 74fps. Sure, if there is a lot of logic involved in the objects ECS will regain the lead, but in 3D land the ECS renderer for meshes is even faster than what GameObjects can ever hope to achieve, MUCH faster.
By using Entities.Graphics, you also will also end with with more game objects than without using it, since it allocates an exclusive GO for the sprite renderer and does its best to prevent you from accessing it, so if you need tilemaps, particle systems, light 2ds, etc now you need 2 GameObjects per entity. On top of that, you’ll need to implement the transform syncing yourself, as Entities.Graphics is not made to be re-usable within a project.
In summary it’s all a mess for 2D if you want to include ECS in your project for anything visual.
1 Like
Untill official support, check NSprites
3 Likes
I suppose they want to depend on “ECS for All” to support what they won’t support natively in ECS and that include 2D. Also with the CoreCLR upgrade, managed land will be faster by default. (However, I’m not really sure if IL2CPP can be faster too.) So maybe 10k GO with SpriteRenderer will be nothing? Also have you run this test case with Unity 6 URP? Since “SRP Batcher 2D sprites support have been added in Unity 2023.1”, it may help the perf somehow?
That’s what I would like to believe, tho the absolute lack of communication on this worries me. The most eggregious thing is Unity staff (probably just following orders, no hate on the staff) refuses to comment on anything 2D. I’ve asked on the forums, on Discord (and there I know that one staff member that regularly talks about ECS saw it, as he sent a message and deleted it soon after on my thread) and Twitter, couldn’t get anything back.
It’s this gray area that pissed me off, will ECS4All solve this? Is unified renderer a pre-requisite for supporting the current 2D feature set in other areas of the engine? We just don’t know, and I cannot understand why this is being kept from us. If you have no plans to support 2D use cases, just let us know. If you do have plans, let us know aswell, what’s the problem with that?
My guess is that the official instance from unity for 2D will be “Use hybrid GameObjects”, specially with the unified transform coming soon. Sure, this helps to integrate ECS, the tooling will make it even better too, I love all of that, but we’ll still miss out on the performance and will have to deal with whatever other quirks will be introduced.
It was ran with SRP batcher on, Render Graph enabled and on Unity 6000.0.21f, I just re-ran after checking these settings again and got the same results. Entities part was ran with the sub-scene closed.
1 Like
Just throwing my vote in here as well to have 2D be treated equally to 3D regarding ECS
4 Likes
I completely agree that 2d really needs some love in this transition, it should not be underestimated how many people start off making 2d games in unity with gamejams and whatnot. And one of the best parts of unity imo is that their 2d pipeline and 3d pipeline are similar enough that all of the concepts generally map over into 3d if you want to move. So it is an immensely useful smaller step into the engine to have the 2d apis mirror what is being done for 3d. Additionally being able to render 2d sprites in 3d space without a bunch of extra boilerplate with code dealing with 3d is a significantly useful thing as well. All of this only works because of how seamless everything is with the old model.
We should be able to do the same with ECS and DOTS.
I can see how if you only look at this from a performance needs point of view 2d could be ignored but it cannot only just be about that, and also you should not dictate what the performance needs of applications are. I know I’ve certainly ran into performance issues with 2d recently infact
4 Likes
The problem is that Unity is known as go to for 2D. If they acknowledge their latest tech isn’t going to support 2D, then they could lose that title. You have to read between the lines (or lack of lines) to understand their reasoning. From a business perspective, it makes sense to be silent and hang on to that title for a little longer.
The technical reason I think 2D won’t be part of ECS any time soon is because in most cases, it doesn’t need all the performance gains that ECS brings. A hybrid 2D approach is sufficient for 99% of cases, and the 1% that could actually use it will figure out how to do it themselves.
Doesn’t make sense to me. Either way you cut it, unless they have a plan in place for 2D, they’ll get backlash. If they communicate with users and explain their reasoning and plans, the backlash decreases. Also, titles only win over hobbyists not professional studios.
See mdsittons reply above for a perfect counterpoint on the 2D performance reasoning. It’s not just FPS that goes into supporting features.
I’m afraid we won’t know what unitys reasons are for the silence and at this point speculating is meaningless. Unless some big social media person gets pissed off and this turns into a save face thing we won’t be hearing about 2D road maps I’m afraid.
I was hopeful that unity, after the runtime fee fiasco, would improve communication with their users. Maybe that’s not the case, it’s a shame.
The main benefit of ECS in 2D isn’t that you get more performance, it’s that you can get the same performance for less power usage which would be a big win for 2D games targeting mobile devices. And who’s to say someone doesn’t want to make a 2D game that runs at 120fps? Phones have 120hz displays these days.
There’s no downside bringing in ECS for all (see what I did there?) aspects of the engine, and that includes 2D
6 Likes
I’m a big fan of DOTS but my main games are 2D builder-management games (think Prison Architect). I made my own 2D rendering framework using a combination of DOTS and Compute Shaders. We could render millions of sprites without a problem. But still, I want an official 2D support.
2 Likes