// num of samples is 512
for (int i = 0; i < numOfSamples; i++)
{
GameObject musicCubeInstance = Instantiate(musicCubePrefab);
musicCubeInstance.transform.position = this.transform.position;
musicCubeInstance.transform.parent = this.gameObject.transform;
musicCubeInstance.name = "SampleMusicCube_" + i;
this.transform.eulerAngles = new Vector3(0, -0.703f * i, 0); // 360/512 = 0.703
musicCubeInstance.transform.position = Vector3.forward * 300;
_allTheCubes *= musicCubeInstance;*
} So I really can’t get why are we modifying the rotation of the gameobject itself (this.gameobject) via euler angles. Shouldn’t the rotation of the children cube’s be modified in this case? And when I tried doing exactly that, the result was not as intended. Can anyone please help me understand this? I’ve also attached the full script if you would like to go through it. (using System.Collections;using System.Collections.Generic;using UnityEngine; - Pastebin.com) P.S : I’ve been making games in Unity since quite some time, but most of the times, these basic stuff like transforms, rotations, vectors go over my head completely. I would really appreciate it if you could suggest some resources for me to go through, thanks
TLDR : Yes, modifying the parent’s rotation affects the child rotation AND position.
**
The purpose of making one game object the child of another is to be able to keep them together as a cohesive unit. If you have some object, a car for example, that is made up of multiple smaller gameobjects you want to be able to move and rotate the whole car at once without having to rotate and place each of the smaller pieces.
**
Now if you imagine yourself as a gameobject, with you body being the parent object and your hands being child objects, and you begin to spin in a circle with your arms horizontal you will notice that while you, the parent, are ONLY changing your rotation, your hands are changing BOTH position and rotation. Your hands are keeping the same relative position and rotation with respect to your body, but the absolute position and rotation with respect to the world is changing.
**
So to explain how this script is assembling the circle of cubes. It is using this script as the object that represents the center of the circle, and in the first iteration of the loop it places a cube out a 300 units away from the center object and makes that cube a child of the center object. The next iteration it rotates the center object, and since the first cube is a child the cube will rotate and change its position along the radius of the circle. Then it will put a new cube out in the same position that the first cube was spawned and make it a child. Now you have 2 cubes, one which has already been moved via the parent rotation and one that is still in the spawn position. Now the next iteration, the parent object is rotated again, moving the first 2 cubes and making room for the next cube to spawn and so on.
Anyway the reason why you don’t turn the child object seems more like design decision than something you must do… If you remember that child transforms will use the parent transforms as their reference coordinate system then you can just turn the whole parent + child transform construct around while adding more children. Existing children will move with the rotation and retain the geometry. Any new child will have the local rotation of zero (if they originally had) so it will be slightly different from the previous one. When you push that child transform out to certain distance in its forward direction you get it placed in the circle surrounding the parent transform. Also it will now face away from the center. If you use negative distance then it will face the center (of course visually this does not matter in symmetrical objects)
