koobas.hobune.stream
Performance Question on Kinematic Rigidbodies
Hello everyone, I've been doing some on device testing (in my case an iPhone 4) using the free Unity profiler and default Unity physics settings, and noticed that in a particular scene physx is taking around 40-60ms to render about 30-40 objects that are kinematic rigidbodies controlled through scripts (use no real physics).
More details: -The scene in question is a "frogger" type setup, where rocks move along a straight path and bob up and down (all according to script), and when a player stands on them, they begin to sink.
Each rock has a mesh collider and a mesh trigger.
The primary script methods used to move these rocks are Vector3.Slerp, Vector3.MoveTowards, and Vector3.Distance.
I have been reading around and apparently for the number of objects on screen, this is a very significant amount of time spend on physx. So, I was wondering what the best to way go about cleaning this up is? Changing physics settings? Different object setup? Different script methods? Any help is appreciated.
I should also mention that at this point, for convenience these rocks are instantiated and destroyed (not recycled) and the garbage collector tops out at around 5.
Just a point of detail - PhysX doesn't do rendering. It's solely for physics calculations. Rendering is done separately. But, as has been said, it's $$anonymous$$eshColliders that are causing the problem - they are very expensive. It's best, where at all possible, to approximate them by one or more primitive colliders.
Mesh colliders are very expensive for performance. So, this where I would start. Try to approximate the rock shape with another collider, e.g. capsule.
Also, you should really use some pooling method to recycle the rocks, because the GC kicking in at any point in the game, could make the game freeze for a couple of seconds or so.
Fair enough, I made some adjustments earlier today:
-Removing the mesh trigger and using on Collision ins$$anonymous$$d of ontrigger saved about 50% performance vs the old setup
-Changed fixed timestamp from 0.02 to 0.04 and that also saved about 50% performance vs the old setup
So really, just those 2 changed together probably would be enough, but I'll work on pooling next.
By the way, does the GC cause freezes even if the profiler is showing $$anonymous$$imal GC times?
The GC will cause freezes even when the profiler shows $$anonymous$$imal GC times. Because the GC is ran whenever it feels like it needs to, and when it does, you will see the framerate drop.
I can't give a black/white yes/no answer to your GC question. I can only tell you my opinion. I think that the GC times shown in the profiler should be used just as an indication. The GC is a dynamic process, as its frequency depends on the size of the heap, which gets adjusted all the time. So, I believe that a low indication for GC in the profiler, cannot guarantee to me that under some different conditions in the same game, the GC won't freeze the game for a couple of seconds.
Of course, the target devices is a very important issue. Since you are targeting iOS, you have very few target devices to consider and test. But if you target Android, which has over 11,000 different devices, would you trust that the low figure for GC that the profiler gives, would not -momentarily- freeze the game in a low/medium end Android device?
So, as a matter of good practice, I use object pooling all the time,especially in games where objects get created and destroyed with high frequency.
