Rotating a rigidbody is faster than changing the euler angle?

I have two different methods for rotating my characters, where direction is a float from 0-359:

Code (CSharp):

1. rigidbody2D.rotation = direction;
2. transform.localEulerAngles = new Vector3(0f, 0f, direction);

When I use the method on the first line with 1500 characters all rotating I get speeds of around 700fps.
When I use the method on the second with 1500 characters all rotating I get speeds of around 60fps.
I tested this with multiple computers (three to be exact) all with vastly different hardware and had similar results.
Any thoughts on why this is?

 

Yes.

Updating the transform requires an immediate update of every aspect of the GameObject's physics. Everything gets recalculated regardless of what it is... which impacts the entire scene. This is the same reason Unity suggests not to move 'static colliders'. There are optimizations built into the physics system based on the assumption that objects won't move... you're impacting those optimizations by setting the transform (may it be position or rotation or whatever), causing it to need to reupdate itself.

Where as setting the rotation on the rigidbody itself allows the physics system to react in a controlled manner. The Rigidbody knows about the optimizations, it knows how to update the system appropriately, and at the right time, in a more efficient manner.

Basically 'Transform' is not optimized with the physics system in mind, because it's not tightly coupled with they physics system. Where as Rigidbody IS tightly couple with the physics system, so it's more aware of how to update itself in a more efficient manner.

 

So I ask this because I have a parent object with a box collider and a rigidbody, and a child object called sprite. I want the parent object to NOT rotate but for the sprite object to rotate. Is there any way to rotate it with this more optimized rotation? The sprite object has nothing in it but a sprite and other objects that are used in the animation.

Simply adding a rigidbody to the sprite would mean I am doubling the amount of rigidbodies, and I have quite a few of these objects in a scene at any given time (not 1500 like my stress test above, but still a fair amount).

 

I think if the sprite doesn't have a rigidbody attached to it, setting it's rotation directly using
SpriteObject.transform.localEulerAngles = new Vector( 0, 0 , direction)

shouldn't be expensive.

 

It is sadly, similar to my test above it results in around 70fps on average. Well below the 700+ I got with the other method.

 

wow, weird.. hopefully someone from Unity can shed some light on this..

 

So I had a breakthrough! I thought long and hard about the difference between these two rotations. I had a realization: The difference between a physics rotation and a regular rotation is that a physics rotation always takes place in a FixedUpdate, which is called less frequently! I tried placing the second line in FixedUpdate and I got around 720fps, even faster than the physics rotation! I haven't tested it on multiple computers yet but I will update after I do so.

 

nice!! That makes sense. I guess we should be careful about how much code we put in Update()

 

Also, it depends on where you are getting your FPS value from! The only true way to know the impact is to either profile or use a time measure.

 

I am using an fps counter from the unity wiki.
http://wiki.unity3d.com/index.php?title=FramesPerSecond

 

Okay, so it might not be accurate as it's measuring the FTP based on how often the Update itself is called, which is sync'd to VSync and can sometimes be limited by other factors, the best test is to profile and see what runs more efficient or use a DateTime.ticks on either side to measure the speed and do all 1500 in the same Update / FixedUpdate so you get a good average. (the stats window can give a reasonable idea but it's also going to be measuring everything else going on)

 

I wish I could profile, if you would like to pitch in to get me Unity 5 feel free