I’m attempting to port Sebastian Lague’s platformer controller to ECS. Unfortunately, whenever I attempt to enter play mode with the collision detection component system in play, the editor hangs and has to be shut down from the task manager. After some work, I isolated the cause of this to RaycastHit2D–it hangs the editor when I try to assign it (be it to Physics2D.Raycast(…) or to “new RaycastHit2D()”). Whenever I skip over the raycast calls, the editor works fine.
So I can tell this clearly isn’t supposed to happen. Knowing that ECS is not complete, I’m totally fine working with MonoBehaviour for the time being–besides, it’s either that or write a script to convert TilemapCollider2D and the like into MeshColliders at runtime so I can replace all my Physics2D calls with regular Physics calls. Nonetheless, it’s pretty annoying to have a project perfectly suited for refactoring into ECS that can’t be refactored into ECS due to a flaw in the systems involved. Had to happen to someone, I guess.
So having said all that: how high is Unity’s priority for 2D support in ECS? It seems like 3D is getting all the love for the time being, and I for one am okay with this (Unity seems to be primarily designed for 3D games, after all), but it’d be nice to know if 2D physics in ECS will be a matter of months or a matter of years.
EDIT: it occurs to me, the question I really meant to ask is closer to: where do I go, if anywhere, to report ECS bugs? Because it seems that I maybe was a bit hasty in assuming that Physics2D bugs should be saved for when work start on Physics2D+ECS.
There’s already section in unity roadmap “2D Physics - Low Level API” which seems to be a good fit for ECS but with no release version: Platform roadmaps | Unity
I’m too struggled with Unity’s 2D single-world physics tied to MonoBehaviours and as a midpoint I’ve used open source VolatilePhysics as a basis. Which btw, is lightweight and a good starting point to learn how to make your own 2D Physics. https://github.com/ashoulson/VolatilePhysics
Also there’s already 3D physics in pure ECS made by @PhilSA forum member:
Before people get their hopes up, it’s worth noting that ECS 3D physics project is nowhere near complete. It basically has position integrator + broadphase + collision impulses for spheres. It would need angular motion for the integrator, queries (raycasts, sweeps) and at least convex colliders (with appropriate collision resolving) for it to be actually usable in games.
I’m not familiar with Sebastian Lague’s platformer so might be missing the point but I’m using Physics2D.RaycastNonAlloc (which uses RaycastHit2D) against a TilemapCollider2D in my ComponentSystem without error. It’s just within standard chunk iteration though, not in a job.
AFAIK, there’s no physics support at all for 2d or 3d in ecs. I think there’s job support for 3d raycasting via RayCastCommand but I haven’t used it myself.
For anyone still interested, I was wrong about what my problem was. RaycastHit2D works fine from ECS–as long as you don’t accidentally allocate thirteen million of them by using math.asint(math.round(...)) to substitute for Mathf.RoundToInt() rather than (int)math.round(...). My thinking that the former was equivalent to the latter might indicate a design fail on the part of Unity (depending on what criteria you judge by, of course), but as with a lot of preview-package-related things, I figure the problem (if any) will become a lot less severe when there’s proper documentation available.
But I digress. It would be very nice to have Entity-compatible Collider2Ds, Rigidbodies, etc…eventually. Personally, I’m content using hybrid for now.
That’s a bit of a complex question to answer. I actually ripped out most of the movement code and replaced it with my own well before I ever thought of trying ECS, and I can’t recall if I ever tested my code after doing the port. The part of the Sebastian Lague platformer that I needed, the collision components, worked perfectly.
If you’d like, I can post the components I ported, or a new port with slightly improved readability and maybe some jobified raycasting, assuming that works. (Sebastian’s code, you may have noticed, is a confusing mess once you try to read or modify it, and really needs to be split up into quite a few more discrete methods.)
Nah, you’ve got it. I’m working with chunk iteration too, and ever since I found and fixed my real problem (see above), I haven’t had any trouble either.
On the note of Physics2D.RaycastNonAlloc: how does it work with arrays longer than 1 element? I’ve never tried it with such, due to my lack of understanding regarding the result…
The length of the array doesn’t change anything other than allowing you to detect more collisions.
Useful for example if you have an explosion that could hit multiple targets.
Also, depending on whether RayCastNonAlloc sorts results (I think it does for 2d but not for 3d?), the first hit in the array may not be the one closest to you so you need to detect them all and work it out.
Ah, okay. Thought the bug reporter tool might be a good step to take, but wasn’t sure at the time whether it was the desired place for ECS-related bugs. (Although, in hindsight, why wouldn’t it be…)
Knowing that ECS is not complete, I’m totally fine working with MonoBehaviour for the time being–besides, it’s either that or write a script to convert TilemapCollider2D and the like into MeshColliders at runtime so I can replace all my Physics2D calls with regular Physics calls. Nonetheless, it’s pretty annoying to have a project perfectly suited for refactoring into ECS that can’t be refactored into ECS due to a flaw in the systems involved. Had to happen to someone, I guess.