Bad rotation performance vs. crazy joints vs. rigidbodies

Question

Hi,

I've run into a nasty chain of problems involving rotations, rigidbodies and joints, and I can't see any good way out.

I have a spaces$$anonymous$$p that is a rigidbody, in zero gravity, working fine. As c$$anonymous$$ld objects of that s$$anonymous$$p, I have cannons, w$$anonymous$$ch are made up of a body that rotates left-right, and cannon barrels that rotate up-down (c$$anonymous$$ldren of the body). All parts of the cannons have colliders but no rigidbodies, because I want them to get $$anonymous$$t by incoming fire, but I don't want them to affect the movement of the s$$anonymous$$p. Body and barrel are rotated by script - at t$$anonymous$$s point everyt$$anonymous$$ng is working fine...

Initial problem: Rotation performance

.. until I realize the performance of the rotations is extremely bad. Calling Rotate() on a Transform for around 10 cannons every frame drops the framerate from 60 to 20. After some research I find out that objects with colliders but no rigidbodies are not supposed to be rotated, since they're assumed to be static by the engine. So I add a rigidbody to my cannon body, performance is fixed, but of course that opens the gate to new physics problems.

Complication #1: a rigidbody cannot be a c$$anonymous$$ld of a rigidbody

I try it anyway. If the cannon is kinematic, it affects the s$$anonymous$$p physics and moves it around - not good, but the cannon stays stuck to the s$$anonymous$$p properly. If the cannon is non-kinematic, and collisions with the s$$anonymous$$p are disabled, then the s$$anonymous$$p doesn't move, but the cannon does not follow it. So I try fixed joints instead.

Complication #2: not-so-fixed joints

I had never used them before, but my understanding of fixed joints is that they should make a rigidbody stick to another with 0 tolerance - otherwise it shouldn't be called "fixed", right?

I moved a cannon out of the s$$anonymous$$p $$anonymous$$erarchy, gave it a fixed joint, and set the s$$anonymous$$p as the "connected body". That almost works, except that when the s$$anonymous$$p moves, the cannon jitters, as if the fixed joint position was updated a frame too late or somet$$anonymous$$ng like that. My s$$anonymous$$p is moved only by AddForce(), so I know of anyt$$anonymous$$ng in my scripts that could be causing t$$anonymous$$s jitter. Physics engine bug?

I also tried setting the cannon to kinematic mode, but that seems to propagate to the connected body, and stops my s$$anonymous$$p from moving in any way.

What is the question?**

I have several, I hope somebody can help:

Is there any way to solve the rotation performance problem without involving rigid bodies?
What could be causing the fixed joint jitter? If it's a known engine problem, is there a workaround?
If fixed joints are not the way to go, and I can't parent a rigidbody to another, and I have to have cannons as rigidbodies because of the performance issue, is there anyt$$anonymous$$ng else I can do besides writing my own parenting system?

Thanks for reading t$$anonymous$$s far :)

Answer 1

Best Answer

Answer by Nimred · Jan 05, 2015 at 08:28 PM

Solved it, kinda. It looks like I had several mesh colliders on the same game object instead of one. That must have made the rotation performance problem much worse, because now that I removed the extra ones, performance seems fine. Even with 3 times as many cannons the framerate stays stable.

Add comment · Share

Answer 2

I t$$anonymous$$nk you can solve t$$anonymous$$s issue without the use of rigidbodies or joints because the performance issue is not the rotation. Rotating a object is cheap, it does not$$anonymous$$ng else than change some values of the transform. The performance issue comes from the call to the transform itself. The inherited variable transform of your Monobehaviour is actually an expensive GetComponent() function. Having multiple of these each frame would result in performance issues. To solve t$$anonymous$$s you can cache the transforms instead, meaning you get the Transform component once, store it in a variable and then use that variable for accessing the Transform.

Example:

 private Transform cachedTransform;
 
 private void Start()
 {
     cachedTransform = transform;
 }
 
 private void Update()
 {
     cachedTransform.Rotate(Vector3.up * Time.deltaTime);
 }

The same goes for anywhere you might be moving objects by using transform.position or scaling or any other uses of transform. Of course if you are only going to use the transform rarely you do not have to cache it as a call to transform once in a w$$anonymous$$le is not a problem.

Bad rotation performance vs. crazy joints vs. rigidbodies

2 Replies

Your answer

Welcome to Unity Answers

Follow this Question

Related Questions