0
\$\begingroup\$

Simple question, I hope.

I've built a variety of prefabs for an isometric shooter game (hazards, enemies, health indicator bars, popup texts, shots, explosions). All of these prefabs were constructed with default rotations appropriate for the gameplay.

My problem is that Instantiate() will overwrite the default rotation of the prefab with whatever is specified as the rotation parameter. So I'm left with hard-coded rotations in my Instantiate() calls to get things oriented correctly in the X-Z plane. (0,180,0) and (90,0,0) are common ones. I'd much prefer to Instantiate prefab gameObjects consistently with "no change to their default rotation," but I'm not sure how to accomplish this.

Thanks for the help, Mike.

\$\endgroup\$
3
  • \$\begingroup\$ Doesn't the prefab itself have a transform you can access once you load it but before you actually instantiate it? You should be able to pass the rotation in that transform into Instantiate. \$\endgroup\$ Apr 26, 2014 at 23:33
  • \$\begingroup\$ GameObject instance = (GameObject) Instantiate(myPrefab, myPrefab.transform.position, myPrefab.transform.rotation) ? \$\endgroup\$
    – pek
    Apr 27, 2014 at 13:50
  • \$\begingroup\$ João & pek, thanks. This solves the problem perfectly. \$\endgroup\$
    – MikeA
    Apr 28, 2014 at 5:59

1 Answer 1

0
\$\begingroup\$

The easiest way to achieve this, is to nest GameObjects you use as prefab. For example, if you want your prefab to be rotated (90,180,0), then put it in additional, empty GameObject. This GameObject will be not rotated after Instantiate (it will have (0,0,0) rotation), but inside of it you will have your old prefab, rotated as you wish it to be rotated.

So, this is how your current stucture looks:
YourCurrentPrefab (90,180,0), which after Instantiation would have lost rotation: YourCurrentPrefab (0,0,0)

Instead, you should came up with structure like this:
YourNewPrefabRoot (empty GO) (0,0,0) - YourWholeOldPrefabAsAChild (90,180,0),
which after Instantiation will actually remain the same, because the root already has a default rotation, and all your content is facing correct global direction anyway.

This workaround will require some work, to add additional empty root for each of your existing prefabs, however you can write a script to make this work for you. If you want to do so, take a look at PrefabUtility class, which has some helpful functions when it comes to work on prefabs.

\$\endgroup\$
3
  • \$\begingroup\$ Thanks. I just thought of this as an option when I woke up this morning, since I'd used a similar hierarchy with my health bar prefabs so I could always scale a (1,1,1) root, regardless of the dimensions for the rendered part of the bar. It will add a little clutter to the hierarchies - but it should be better than propagating hard-coded rotations through my scripts. \$\endgroup\$
    – MikeA
    Apr 25, 2014 at 14:51
  • \$\begingroup\$ Hmm, if the empty root object contains a RigidBody that will later be moved around with rigidbody.velocity = transform.forward and the like, won't that cause the rigidbody object to separate from the empty parent in gamespace at runtime? Maybe there aren't any side effects to that. But what about a collider script that destroys the object? Since the collider will be in the rigidbody, will the parent also be destroyed or will it stick around and use up scene memory? I can code up some tests to figure this out, but if you already know from experience, I'd love to know how you deal with it. \$\endgroup\$
    – MikeA
    Apr 25, 2014 at 15:09
  • \$\begingroup\$ Hmm that starts to be more tricky. Maybe, to not switch everything, you should instead write a short component, which will remember rotation set in the editor, then set it after Instantiate and delete itself after that? That would workaround problems that you've just mentioned. \$\endgroup\$
    – kreys
    Apr 29, 2014 at 8:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .