Resolved Rotating without stretching

I'm quickly knocking up a model in Unity Editor while I learn the tooling.
It's basically a "battleship" that's an elongated cube with a scale of 40, 20, 200.

I also have a turret (cylinder) which is a child of it. When I rotate the turret (Y axis) it massively stretches on the Z axis. Apparently this is a quirk of unity since 5.x:
https://www.unity3dtips.com/how-to-fix-objects-stretching-when-rotated/

But how do you fix it? I removed my turret, then made it a child of a 1,1,1 sphere. That rotated fine. But the second I put that sphere onto the main ship, as a child, the scale immediately plunges to decimal places (which makes sense as it's tiny compared to the parent transform), and rotation is broken again.
Is there a fix/workaround? I can fix it by making the "ship" actually just be a 1,1,1 sphere and then the hull is one child and the turrets another, but is there a better way?
Thanks!

 

Use an empty parent object with scale of 1,1,1 as the parent of everything: the "battleship" cube, the turrets, everything. Don't make the turrets the child of the battleship model.

Name your empty parent "Battleship". Now you can freely scale and rotate anything without affecting the other models in the battleship. To rotate the ship itself, rotate the parent. To rotate the turrets individually, just rotate the turrets.

 

Thanks; that's pretty much what I ended up doing, I was just wondering if there was a better/"right" way as that seems hacky.

 

It's not hacky, it's the right way.

 

... Interestingly enough this solution has introduced a different problem.

Now when I rotate my "ship" (the parent which is itself now an empty gameobject, the different parts rotate at different speeds. You can see it here:



They're all rotating correctly, but for some reason the turret set of objects is rotating slower than the Hull set of objects so they detach during the slerp.

I'm using the standard Quaternion.Slerp way to do it:

Code (CSharp):

1.     void RotateTowardsXZ(Transform in_transform,Vector3 target_pos, float rotation_speed)
2.     {
3.         var dir = GetDirection(in_transform.position, target_pos);
4.         dir.y = 0;
5.         var rotation = Quaternion.LookRotation(dir);
6.      
7.         in_transform.rotation = Quaternion.Slerp(in_transform.rotation, rotation, Time.deltaTime * rotation_speed);
8.     }

If I move the turrets back to being children of the Hull it rotates fine and they don't disassociate.
Even if I slow down the rotation speed it still happens.

What's going on? Surely all children should rotate at the same speed automagically?
I've googled but not found anything that suggests this is a common mistake.

 

It would be helpful to see your object hierarchy. What's the composition of the turrets?

Also in your script - "in_transform" is the parent?

 

I can move the `turrets` item around (i.e. take the individual turrets out and have them as children) but it makes no difference unless I put it under Hull.

> Also in your script - "in_transform" is the parent?
Yup, it's the "Ship" `transform`.

If I actually move the target around in the right way (behind the ship), I can end up with the Turrets rotating in one direction and the hull in the other direction (like scissors)!

Edit: Happens with Quaternion.Lerp as well as .Slerp.

 

That hierarchy looks fine to me.

Two things:

• Check the scales on your whole object hierarchy. basically only the Hull and the "Actual Turret" objects should have anything set for their scale except 1, 1, 1.
• I wouldn't even worry about your script right now. Use the controls in the editor to get it so that when you rotate the "Ship" parent object, everything rotates properly. Then once that's working, start looking at the script again. If it works in the editor but not from your script, you might have some stray code running somewhere else that is messing with your rotation.

You don't happen to have a script setting the turret rotation yet do you?

 

Figured it out. I'd left a copy of the script component on the Hull when I did the rejiggling to solve the initial problem so it was being ran twice for the Hull.
Thanks for the help!