koobas.hobune.stream
Profiler Physics.Simulate spikes
Hi guys, Im having a big issue with the game Im developing, hope you guys can help me understand these profiler values and how to avoid them.
First Im going to give you some Background about the game, it is a 3D Endless Runner for IOs devices , in wich the world is continuously spawning the obstacles and rewards the player can obtain, every spawned thing comes to the player. Everything the player can take or hit have a collider( only primitives )+rigidbody (Kinematic) and some obstacles have more than one collider. We are using a spawn pool that teleports the objects far away from the player and disable some scripts,renders and colliders, letting active only animated objects.
However this obstacles some times have complex hierarchies and when we move them back to the spawn point a large physics.simulate spike shows up in the profiler? Can´t figure it out, and haven´t found anything about these internal method. The profiler is reporting a high number of rigidbodies active, but low contact points and the proyect collision matrix is already fixed to just check collisions betweeen the correct layers.
Here is an image of the profiler:
If more information is needed to understand the problem info could be provided. Hope you guys can help me understand the problem or set me in the right direction.
$$anonymous$$ind of, at the end we decide to rebuild the way the world was builded because moving really complex hierarchies was the problem, as I mentioned in the comments from before, all the objects have colliders with rigidbodies and move them all together (sometimes more than 200 gameobjects) wasn´t and option because it is really heavy for the processor, so we change the world and we dont move a lot of things now, just the player and some other stuff. To resume at the end moving a lot of objects in a deep and complex hierarchy can hit the performance, at least that happened in our project. Hope this helps you alittle bit.
I'm not exactly sure if this is the right answer, but from my experience, this is due to Mesh Re-Computation.
Assuming your obstacles are using a Mesh that you made in a 3D modeling program and imported in, every time the object comes back on screen, the Physics engine is re-computating a complicated mesh. The only solution that I have come across that works to alleviate this problem is using compound colliders ( several primitive colliders ) instead of the imported mesh for collision purposes.
I thought of that too, but right now I'm using only primitive colliders (box and spheres only) even on those meshes that have multiple colliders, if that is not the problem what else might it be? I have read across some threads that moving complex hierarquies is bad for Unity, but havent found proof of that. Aside from that i dont know what else could it be. ='(
Thanks anyway, I'll double check about colliders, just in case.
Does your OnCollisionEnter / OnTriggerEnter code blocks have some pretty long / unoptimized code? Are your objects with compound colliders moving without rigidbodies? some other things to think about...
Nope, actually the only one checking OnTriggerEnter events is the player which at the spawn moment is away from the spawn point ( but still visible ) and every collider in the scene have a rigidbody marked as kinematic and with all constrains turned on, that is because all the movement is done via scripting. Any other thing that you guys can think of?
I've noticed that every time there is a spike there is also a increase/decrease of the active Rigidbodies, does moving a lot of Kinematic Rigidbodies is bad for Unity? sleeping/awaking lots of Rigidbodies eats the CPU ?
