koobas.hobune.stream
Colliders vs Transform Position for performance
I have been working on a music based game where things move across the screen at a speed relating to the music. The player controls an avatar that always remains at 0 on transform.position.x The music blocks travel towards the player from positive x.
At the moment I have a collider on both the player and the blocks. When the blocks collider enters the players collider, I use OnTriggerEnter to check weather or not the player hit the block. (The player can move in the z axis so if not lined up properly with the block, they can miss it. Sometimes, after a certain amount of time has passed, the blocks get a bit out of sync. I think this may have something to do with the amount of things in my scene. It got me wondering if using colliders is the best way to go about this.
Since the check always happens on weather or not the player was at 0 on the x axis when the block hits 0 on the x axis, would it be cheaper and better for performance to just use an (if block.transform.position.x <=0) then do stuff rather than a collider doing the check? There are usually about 50 blocks at once in the stage.
Is checking update every frame for an objects position better than a collider checking every frame for a collision?
If you're not trying to mimic physics of any kind, like gravity or objects with specific shapes pushing or blocking each other or reacting to collision forces, you may not need colliders/triggers.
There's a mindset that Unity kind of suggests with its Hierarchy view, that there needs to be objects and they need to behave in a self-contained manner, and probably physically.
If you think about your game and you think it's abstract (and simple?) enough to represent with simple changing variables and equations, then you may be able to just implement the logic with those simple variables. No colliders and rigidbodies. Just abstract objects with changing x and z, and a player position with a z.
Your scene GameObjects can then be just purely for visualization. Just a bunch of renderers with positions.
(Regarding your blocks becoming out of sync. What do you mean by that? Out of sync with what? The music? What would that have to do with the number of objects? Are you using Update or FixedUpdate? Do you know how timesteps work?)
Yes, you are right in that having the blocks use rigidbodies and colliders is a bit overkill for what actually needs to be done. It was easier in the prototyping stage to set it up this way but now we will switch to using transform checks in update.
As for the out of sync part, this is down to my own fault and just realising why. When the blocks collide with the player, because of the width on the colliders, this would happen at about 0.2 on the x axis as opposed to at 0, meaning that each time new music was added to the stage, it would go out of ti$$anonymous$$g by 0.2 seconds each time. So after about 5 times, it would be out by a second or so. $$anonymous$$oving the colliders position has fixed the ti$$anonymous$$gs now, but we will still move to getting the physics stuff out.
Just a few colliders shouldn't make that much of an impact on the performance. It sounds as if you do not destroy the past blocks after they left the screen. If you implement this I think your performance will increase very much!
But to answer your question more directly, yes transform position checks are faster if properly optimized since you only need to check 2 axes. But consider using 2D colliders if they are not yet used.
The colliders do destroy themselves when they go past -20 on the x-axis to help with performance.
The thing you should destroy is not colliders, you should destroy gameobjects that has colliders. Also take a look at pooling systems. They help performance a lot.
And I didn't think about the fact that colliders would need to check for 3 axis as opposed to just one. I will make the changes in a new build and see how well it improves. Cheers
You should not destroy all of the items but more likely recycle them.
Using a pool, you should be able to create and then activate/deactivate. Then no more Instantiate that is quite slow.
You can find a pool example there:https://unitygem.wordpress.com/object-pooling-v2/
If I'm visualizing your scenario correctly, creating a generic List for the blocks that you are generating will imply that you just need to check whether the block that is on top of the list (nearest to the avatar by order of creation) has collided.
That should result in just one check regardless of the number of blocks in your scene.
The above optimization trick will work only if your blocks in the scene have equal speed.
You can now use both physical colliders (recommended because its easier to debug and shape things visually) or a simple transform position comparison.
For physical colliders, your boxes should come without colliders. Then simply add a collider component to the box on top of the list.
When a box collides, remove it from the list (or add it back to a pool after removing its collider) .
Tip: As Pharan mentioned, for this application, you will need a thorough understanding how timing works in physics in relation to frame updates. These ensure that things don't go out of sync even if you jump multiple frames due to performance. Here are the docs on that: http://docs.unity3d.com/Manual/TimeFrameManagement.html
At the moment, the blocks are stored in an array that has the ti$$anonymous$$g in seconds that they need to hit the player at. The movement is governed in an update that calculates the speed of travel at which they need to go. It definitely makes sense to only be checking for the one collider as opposed to every one doing the checks. During gameplay, the speed of the blocks will change so not sure if your trick will work, but I will try to implement it when I get a chance. Instantiating everything at the start and pooling also looks like something to try out.
Cheers
