koobas.hobune.stream
Does modifying a parent gameobject's rotation affect the child gameobject's position?
Hi, I'm really sorry if the question above sounds stupid.
I'm having some problem understanding a code section that involves making a circle of game objects in the scene.
So, I was following this audio visualisation tutorial, and I am having some difficulty understanding this :
// 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[i] = 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. (https://pastebin.com/1r3hbYMV)
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.
Wow, thank you, it is clear to me now. Your body and the arms example was perfect. I now understand how the parent's transform affects the children better now, thanks again :)
Also, could you suggest some resources where I can work on getting better at this stuff?
Hmm I'm not really sure what resources are out there. Unity has a good intro to Vector math, but this will only get you part of the way there. You are always welcome to direct questions to me personally at bdoobie01@gmail.com, I can usually answer most basic questions. Other than that I recommend just opening a blank unity project and coding up some rotations and translations and looking at the result. For example, as a challenge, try to create some code where you have a child object that orbits around a parent object, even as you move the parent object. Then try to do the same thing without having the other object as a child.
Imho the setting of the cube position could be done in more generic way. Now it works ok only if parent has zero world position..
if you convert this line
musicCubeInstance.transform.position = Vector3.forward * 300;
with this
musicCubeInstance.transform.position = musicCubeInstance.transform.forward * 300 + musicCubeInstance.transform.position;
then everything works nicely and is more generic..
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)
I agree that the original code should be more generic but your given code is not correct. The correct change would be
musicCubeInstance.transform.position = Vector3.forward * 300 + this.transform.position;
hmm.. i tested and with my line of code it works, but with the suggested one the rotations don't align towards the center..
$$anonymous$$ay I know, what does adding this.transform.position to the prefab's gameobject do? This went over my head, sorry :(
Basically your original code assumes that the parent game object is at the world origin (position 0, 0, 0). If you wanted to create your circle of cubes at another position in the world, then your code wouldn't work because of this line
musicCubeInstance.transform.position = Vector3.forward * 300;
This line sets the position of the cube to (0, 0, 300) (because Vector3.forward = (0, 0, 1)). This position does not take into account the position of the parent game object, which you want to be at the center of the circle. You can fix this by adding the position the parent object. Now the cube will spawn 300 units forward of your center object, ensuring that it is in the center of your circle no matter what.
I just realized why the musicCubeInstance.transform.position = Vector3.forward * 300 + this.transform.position; was not aligning cubes towards the center (the cubes, other than the first one, were slightly facing away from the center, due to the small angle changes the difference is so small that its not very noticeable, but it's there). The code you wrote is correct (and $$anonymous$$e was not) but need to move the line: this.transform.eulerAngles = new Vector3(0, -0.703f * i, 0); as the first line of code inside the for-loop.
Reason for error: The first turning is 0 = no turn at all that also equals the prefab cubes initial rotation. When next cube is set as child then the parent and child rotations are still both zero (same as first one, because only 0-turn has happened). However when the center is really turned (in the second iteration) then the Vector3.forward (in the this.transform context) is pointing to the new angle and the second cube gets placed to to the right place, but facing slightly wrong direction (same as the first one but not towards the center). After that the error stays the same for the rest of the cubes (one angle step behind the intended direction). $$anonymous$$y line of code did put directions right (without the line move) but made the two first cubes overlap.
Thank you, I do now understand how the child was being affected by the parent's rotation. Also, what does adding the prefab's instance's original position with the forward position do? I kinda don't understand :/
Its not the prefab instances original position. musicCubeInstance.transform.position is actually same as this.transform.position at that time because they were set as same after the prefab was instantiated and that position is not yet updated.. so there is no difference in this case...
