Hi I have a lot of dynamic objects (100-200 objects) that move as different ways. They have box or circle collider. I use CircleOverlap function to check collision. I can not activate only visible objects(in frustum) because I do not want that they start to move after rendering them Code (CSharp): public class MoveBehaviour:Monobehaviour{ [SerializeField] float speed; IEnumerator MoveCoroutine(){ float time=0; while(true){ time+=Time.fixedDeltaTime*speed; // movement method(lerp ,...) yield return new WaitForFixedUpdate(); } } } I watched the profiler. It takes huge time. Is it better to not use coroutine with WaitForFixedUpdate? Is it better to define only one coroutine manager and call all move functions(that implement IMovable interface) for all objects in a for loop?
Best would probably be to actually do your code in FixedUpdate, and not use a coroutine at all. At least that will help preserve your sanity. As for the performance issue though, well, if you're moving 200 objects around on every FixedUpdate, and especially if that moving requires some computation, then yeah, that'll be where most of your CPU cycles go. I don't think you can do anything about that, unless you can somehow contrive to update them less often.
With that many objects, it would be more efficient to run a single update to move them all rather than each one doing it individually. I'd probably use a manager that all the objects registered themselves with, that would do movement for all of them in its FixedUpdate.
So I use events or make an interface IMovable and call(invoke) all of them in one place but sometimes I need delay while they move. Suppose an object moves one loop(or pingpong) and before it starts a new loop, it must wait for some seconds. So I need coroutine to simulate the delay Code (CSharp): public void Move(){ // Start coroutine } IEnumerator MoveCoroutine(){ while(true){ // Move using lerp,... if(loopFinished){ // wait for some seconds } } } thank you
You never need a coroutine. Coroutines are just a convenience. You can always restructure your code to do its work in Update or FixedUpdate instead; it just means that you'll have to watch the clock yourself and decide when to do whatever you do. But I really doubt any of this has much bearing on the performance problem you're seeing.
Moving 200 objects, in and of itself, should not be a performance issue. Moving objects just isn't that taxing. What is taxing may be moving objects with rigidbodies, particularly kinematic ones. Would it be possible to make this system work without rigidbodies? If not, how about using the rigidbodies to your advantage? For example, setting rigidbody.velocity to match the way you'd like your objects to move would be drastically faster than setting the position of each one in sequence.
yes but it does not cause readability and maintainability. I have different delay for moving objects. Yes I can do it in update or fixedUpdate but based on discussion below, we said to use only one fixedUpdate. Can we use only one FixedUpdate for all moving objects with different delays?! They do not have any rigidbodies only box and circle colliders
Yes. Transform[] transformArray Float[] delayArray Loop through this in a single update and update all the individual objects I have close to no experience in particle systems and don’t know what your 200 objects do, but it might be something to look at