ECS projectiles with standard unity colliders?

I'd love to amp up the number of projectiles at any time in my game, but this would hit performance. I'm wondering if there is any possible way to convert all of my projectiles into ECS while still interacting with my normal colliders.

Or, if there is anything at all I can pull from DOTS for performance. For example, can burst be used in any way for a standard unity physics built game?

 

Performance-wise, ECS won't help much if you have to stick with the standard unity colliders. Your best bet would be to use good pooling strategies. If using 2D, you can also try enabling multithreading under the Physics2D settings.

I'm currently using DOTS with the default 2D Physics (Box2D). So I use pooling for that. And I use Burst wherever I can for pure math stuff like procedural mesh, Line of Sight, counters, etc...

 

I see.

I suppose we could change all of the projectiles to ecs and check each frame if the projectiles vector is inside of an obstacle bounding box and fake the impact that way. Split up obstacles into segments as to only iterate a few objects each frame. I wonder if this would be efficient and what kind of problems would arise...

 

You could just duplicate the Physx colliders that projectiles can hit in Unity.Physics. That's what we do although funny enough our projectile system is the one feature that doesn't make use of it. But that's just because our projectile system is a complex beast created when jobs first came out.

Or just use the Physx job based raycasting. That and object pooling is what our current projectile system does.

 

Do you mean add an ecs collider on top of my unity collider? As such that the unity collider takes care of world based collisions and the ecs collider handles the projectiles?

 

Yes. Unity.Physics has some quirks around handling the dependencies and such, things not well documented, so be prepared for a bit of a learning curve. But it's a great tool and is blazingly fast. What we do is create dynamic bodies, but then disable the system that moves them via velocity and we just update the Translation component ourselves. Basically replicates what rigidbody.MovePosition does in Physx.

Less useful for this case IMO if you don't also have other uses for it. We had quite a few so it was worth the learning curve and normal pitfalls of early adoption.

 

Great. One final question. I have a whole bunch of particle systems for my projectiles. If I make these entities am I going to have problems using these particle systems?

 

Ya particle systems are still main thread access. Unity.Physics doesn't solve all problems here, which is why if projectiles is the only use it might not be worth it. I still like it just to avoid the batch api's of the Physx job based raycasting, like that's worth it to me having already gone through the general learning curve.

We use IJobParallelForTransform directly to move projectile transforms. If the projectile has a particle effect we just attach it as a child. Our particle systems are also pooled. Making it a child vs having an additional IJobParallelForTransform is kind of a wash performance wise. So I went with the simpler approach.

Another issue with Physx job raycasting is you can only reference the collider hit on the main thread, and that's the only identifier there is.

A complete projectile system factoring in particles and maybe different projectile models and all, ends up being fairly complex by the time you account for all details.