koobas.hobune.stream
Transform vs Gameobject
I'm wondering what are some examples or use cases in which Transform would be better to use instead of GameObject or even when a Vector is better than a Transform. I have heard some people say I sometimes use GameObject when only Transform is necessary.
For Example : If I want to spawn my object in a location with a specific rotation would I cache my transform and rotation a a vector and a quaternion, a transform or a gameobject?
Apologies if sounds vague or generic.
Hopefully you understand the fundamental difference between GameObject and a Component like Transform. In most cases it's better to use a Transform reference or even a reference to another component. That's simply because the GameObject is just a container for components. It offers only little functionalities like getting / setting the layer or destroying the whole gameobject since you need a reference to the OameObject in this case.
The Transform component offers: the position, rotation, scale of the object in the scene, it's position in the hierarchy (parent). If i need a general purpose field where i can assign some kind of gameobject i always use Transform. Since every GameObject must have a Transform it's almost always the better choice. Also you can almost do the same things with a Transform you can with a GameObject. GetComponent and the "shortcut properties" are the same for GameObjects and Components.
I don't fully understand your example. Vector3 and Quaternion are valuetypes while GameObject and Transform are reference types. So you can't really compare those things since they behave very differently. I think a better description of your use-case would help ;)
A Transform contains aa Vector3 (Position) a Quaternion (Rotation) and another Vector 3 (Scale)
If I had a position I could store it in
Two Vector 3s and a Quaternion A Transform A Game Object
Which would be the most efficient
I'm not sure if it's much different from what I said earlier but that's as clear as I can explain it.
To "store" a position in a Transform you need a Transform component instance somewhere on a gameobject.
If you for example want a spawn point in your map / world for your player, the way that uses the smallest amount of memory would be storing two Vector3s (one position the other eulerAngles) of your desirec spawnpoint. However this is very inconvenient since you would have to type in those numbers manually. For things like spawnpoints you simply create an empty GameObject. This can be moved and rotated in the editor the way you want (WYSIWYG).
If you want to store the initial position of your player (to reset it to the start for example) you probably would use a simple Vector3 variable in your script since you just "take a snapshot" of it's current position at Start.
ps: "If I had a position" isn't really a concrete use case or is it? Think more about your goals. What you want to do in the end. Don't get lost in implementation details.
@Exalia: A Transform contains references to those 3 things, not their values. So if you store an object's Transform on Start, you can still continue to get updated values from that Transform variable every frame. It's more efficient than a GameObject reference.
Thanks Invertex that's the kind of information I was looking for :)
GameObjects and Transforms are very closely linked in Unity: every GameObject has a Transform component, and you can't have a Transform without a GameObject.
This means that, in most cases, a reference to either will work, and which variable type you pick should depend on how you're going to be manipulating it in scripting. For example:
If you're mostly going to be performing transformations on the referenced variable through code, a Transform reference makes sense because you just have to call myTransformVar.position instead of myGameObjectVar.transform.position .
If you're mostly going to be doing things like cloning or instantiating other objects from your variable, or setting its value by using a FindWithTag function, GameObject probably makes more sense. The Instantiate function requires a GameObject reference, and doing something like...
myTransformVar = FindGameObjectWithTag("myTag").transform;...will throw an error if Unity is immediately trying to get the transform of a GameObject it can't actually find (because that tag hasn't been created or assigned).
BUT the good news is that if you have a reference to one of these (Transform or GameObject), you can quickly get a reference to other at any time in your script! Every Transform's associated GameObject can be accessed with
myTransformVar.gameObject
and every GameObject's transform can be accessed with
myGameObjectVar.transform
If I'm going to be using both a lot, I'll sometimes create a GameObject variable and a Transform variable and store references to both in my script for quick code access.
What I don't quite get is why Instantiate wants a transform for the parent (not a GameObject). Is there any good reason for that that I am missing?
Because the Transform has all the information that is needed by the Instantiate method. GameObject does not, the Transform component on the GameObject does.
This helps avoid forcing a GetComponent call internally. (in more recent years they have cached this call to improve efficiency though)
This is a proper performance design principle. Instead of forcing this GetComponent call on the user, the user chooses, as the user might already have a reference to Transform. If the method required GameObject instead, then the user would not be free to do that caching themselves.
Aha okay, so when Instantiate got a game object, it would need to GetComponent<> its transform for positioning the instance, and that's costly (although cached meanwhile). Is that what you mean?
Anyways, when Instantiate better uses a Transform, this would also explain why accessing children is also done by the transform and not by the game object.
It's just a bit counter-intuitive to have a component of a game object be the starting point for such operations like finding children and building an instance.
Yes. It isn't that counterintuitive, it's just avoiding doing operations under the hood that would be unnecessary if one just provided the right type. It's like saying it's unintuitive that you have to access the Renderer component of GameObject to gets it materials. The method could take in a GameObject and work, but good program$$anonymous$$g design principles imply asking for the data that is needed and nothing more.
This is not really about efficiency but just the way how the hierarchy works structurally. GameObjects do not have any children or a parent. Only the Transform component has. A GameObject is just a container with almost no functionality whatsoever. I'm now wondering, since you necro-posted on this question if you have actually read any of the answers? I don't want to repeat everything that has already been explained above. Fact is a GameObject does not have a "parent". The Transform component does have a parent and it's a reference to another Transform since the Transform components actually build the hierarchy, not the gameobjects.
Next time, please post your own question and do not post an Answer to a 7 years old question that is already answered. Answers should answer the question and not ask new questions.
Thanks for clearing this up guys. And sorry for necro-posting. Anyways, to make this complete, I found this here about parenting helped me understand even better: https://docs.unity3d.com/2021.1/Documentation/Manual/class-Transform.html
