Why do we have to use transform to set Parent

Since transform is component of gameobject why cant we use
gameobject.setParent(anotherobject.gameObject);
And we have to use
transform.setparent(anotherobject.transform)

Can someone explain the logic It reallt confused me a lot

 

You answered your own question: Because the GameObject does not know anything about parenting. That's the Transform's job.

 

And it still sucks that we cannot have hierarchy without Transform.

 

Parenting influences local position, rotation arount the parent and scale.
Imagine you make a sphere a child of a cube and offset the spheres position. Now you rotate the cube. The sphere keeps its position relative to the cube but changes its position in world space. So from my point of view its pretty logical to place parent/child functionality inside the Transform and not the GameObject. The GameObject is just a container for components and Transform is a component for position rotation and scale.

Why that? Would you elaborate the reasons for your "anger"? Since you can't have a GameObject without Transform where is the issue? What would you do differently if it would be possible? What is your usecase what you can't do now?

 

So correct me if Im wrong. Transforms are doing all the parenting not gameobjects Right?

 

Yes, the Transform component is responsible for defining the position, rotation, scale and hierarchical structure of a gameobject in the scene. A GameObject is literally just a container for components. The only thing a gameobject defines is the active state, the layer, the name and the tag.

 

Organization of scene and prefab hierarchy without overhead.
It's nothing new actually, comments about this are since the beginning of unity existence.

 

And you can't do this with transform responsible for parenting as it is now? Albeit I see you usecase and have used parenting for that purpose too, I don't see the problem when transform manages the parenting. I see it more that you are "abusing" the parenting functionality for something it is not really intended for. If UT made it so the GameObject is responsible for parenting as you desire, what would be different for you? And how should the position/roatation/scale stuff be handled then? If any UT should provide proper scene organization tools which do not depend on parenting. But making GameObjects responsible for parenting is no good option IMO.

 

I mean, one could always write an extension to do this if it's really that bothersome:

Code (CSharp):

1. public static class GameObjectExtensions {
2.    public static void SetParent(this GameObject gameObject, GameObject parent, bool worldPositionStays = false) {
3.       gameObject.transform.SetParent(parent.transform, worldPositionStays);
4.    }
5. }

Code (CSharp):

1. public class SomeClass {
2.    GameObject g1;
3.    GameObject g2;
4.  
5.    void SomeMethod() {
6.       g1.SetParent(g2);
7.       g1.SetParent(g2, true);
8.    }
9. }

 

I would not have transforms calculations. Also faster prefab creation, without additional unneeded transforms.
Pos rot scale - could be inherited from lowest parent transform or unavailable for this object (deepens on convention).

 

At this point the fact that every GameObject has a Transform is so deeply ingrained into Unity that the only way you'll be able to escape it is to switch to ECS/DOTS or a different game engine entirely.

Also, if you have a GameObject that doesn't need a Transform, perhaps reconsider the idea of using a GameObject at all. It might be appropriate to create a plain old C# object in that case, depending on the use case.

 

How would you like to do this functionality instead? Because I'm sure many people won't "give it away"?

Imagine I have a vehicle with rotating wheels, headlights, models for driver, particle systems for wheel dust and fumes, a sound source, many colliders, meshes etc. all on different child gameObjects. How should I move this whole thing without the parenting as it is now? Should I move every part independently from each other? Does that make sense to you?

Edit:
Let me elaborate on the example with the car:
Every of those parts of the car needs a position relativce to something else. And when I move the car I just want to move the top level gameObject and these things keep theior relative positition. The point is, that it would be a very tedious step to add a Tranform component on all those child gameObjects manually. It is tedious, error prone and pretty much useless.
So the "benefits" you list here do in no way outweigh the "issues" it would introduce.
But hey, Christimas is around the corner. Maybe Santa Claus has an open ear for you .
End Edit

There are some cases where a GameObject does NOT need a transform. But none of this cases is hindered by a Transform component. And I'm pretty sure the "unecessary" calculations won't be your performance bottleneck. So I'm still not sure what you are requesting here and why the way it is now "sucks" according to you. If UT would change it as you want it it would also invalidate the code of millions of users and their workflow. I guess if UT would do this most of those people would complain "this change sucks". And when UT points the finger on you and says "he wanted it" are you prepared for the S***storm?

Also I highly doubt that making the GameObject responsible for parenting brings any performance benefit at all. Since then you have to do a check if a Transform component exists in EVERY frame and you have an additional random memory access for gameObject.parent.Transfrom. When the Transform handles pos rot scale the GameObject part can be left out completely. And you also have a good new source of bugs when Transform is optional in a hierarchy. How would you handle when a Transform component is removed in the "middle" of a hierarchy? Can this break gracefully at all or does it only cause frustration? So from my POV the parenting functionality is good as it is. Maybe not perfect but I don't see how your suggestion improves anything. And the "issues" you have don't seem relevant to me at all. Sorry. So maybe your

is a bit exaggerated?

In ECS an Entity CAN have a translation component, or not. So there you have full controll. But every "relevant" entity which shall end up beeing rendered needs a whole bunch of components as far as I'm aware. Since most things in a game represent something the player must see or interact with, most things also need a transform. I think we should develop for the common way which is used most of the time, not for a rarely used special case. Or not?

 

I agree with you I'm just humoring OP.

 

I know. My response was not meant to you since you got the point already. I used it as an example to explain how important a transform is. I should have been more clear about that. Sorry.
And koirat who requests the "feature" of a transformless hierarchy is NOT the OP. He just jumped the train .

 

I have not requested anything. I just said that it's a pity we got transform calculations on objects that not need them and it could be done better.

Missing transform could be resolved by inheriting lowest parent transform.
During the object creation in editor Transforms might be added but they will have for example checkbox "Inherit".

Performance problem depends on hierarchy depth and number of objects.
As I remember in game "Shadow Tactics" one of the creator said that it was a performance problem so they had to compress their prefabs hierarchy.